常用框架的認證方案及問題

• JeecgBoot 使用 CAS 協議（默認方案）
  • 問題：CAS 協議相對傳統，雖然穩定，但 不支持 OAuth2/OIDC 等現代協議，不適合多端接入和微服務架構，功能落后，生態兼容性差。
  • JeecgBoot 雖然也有 Spring Authorization Server 的版本，但目前實現方式類似 Pig，業務邏輯和認證耦合嚴重，不適合獨立部署。
• Pig 集成 Spring Authorization Server
  • 問題：將 Spring Authorization Server 和用戶認證、權限邏輯深度耦合在業務代碼中，擴展性差、代碼復雜難懂，不便于維護和二次開發。
  • 本質上是自己構建的一套認證服務，但沒有獨立部署，也沒有提供統一接入能力。
• Ruoyi Cloud 自定義 OAuth2 實現（基于 Redis 存儲）
  • 問題：實現輕量，但只是模擬了 OAuth2 的 token 存儲邏輯，不是完整標準協議實現，在多系統接入、第三方兼容等場景下存在巨大局限。
  • 不支持標準的 OAuth2/OIDC 工作流程，更像是單應用優化，不具備統一登錄平臺能力。

當前企業統一認證的普遍趨勢

• 現在每個稍具規模的公司，幾乎都會開發或部署自己的統一登錄服務，作為所有系統的認證入口。
• 這類統一認證平臺的目標是：集中賬號管理、支持單點登錄（SSO）、支持 OAuth2/OIDC、支持第三方系統接入、提供標準化認證能力和管理界面。
• 認證平臺往往作為獨立系統運行，與業務完全解耦，以標準協議方式向各系統提供認證服務。

微服務時代推薦的認證中心方案

• 微服務架構強調解耦和服務自治，認證中心必須單獨部署、具備標準接口（OAuth2/OIDC/SAML），不能與業務耦合。
• 在私有化部署場景下，推薦以下可自部署、標準化、現代化的認證中心方案：

1. Spring Authorization Server（獨立部署）

• 優點：Spring 官方維護，符合 OAuth2.1，適合 Spring 系生態。
• 缺點：需要自己做用戶管理 UI、接入配置，使用成本高、功能較原始。
• 評價：我們要的，是一個可獨立部署、標準協議、易于集成的認證服務，而不是一個協議 SDK。

2. Keycloak

• 優點：功能強大，支持 OAuth2/OIDC/SAML，LDAP/AD 接入豐富，界面管理友好。
• 缺點：系統復雜、重量級，UI 定制和插件開發成本高，官方支持周期短（版本頻繁 EOL）。
• 評價：適合 Java 生態，支持中文界面，方便集成多個已有系統，方便簡單修改登錄頁。

3. Authentik

• 優點：輕量現代，支持 OAuth2/OIDC/SAML，支持中文界面，前后端分離，更容易定制和擴展。
• 缺點：生態較新，部分功能成熟度不如 Keycloak，適合中小企業或初期構建認證平臺。
• 不評價，Python 語言實現。

4. Authelia

• 優點：主打反向代理保護、簡單高效，適合保護 Web 應用。
• 缺點：不支持 OAuth2/OIDC 接入方式，不適合 Java 系統或多端系統接入。
• 不評價，Go 語言實現。

其他

• 微服務架構中，認證服務應單獨部署、支持標準協議、與業務解耦。
• 不建議將 Spring Authorization Server 嵌入業務系統中開發認證邏輯，一旦系統間要實現 SSO 或第三方接入，會面臨嚴重的擴展和維護問題。
• 不建議使用托管身份服務（如 Auth0、Okta）作為通用方案，因為：
  • 企業不愿將用戶數據放到第三方平臺；
  • 數據合規要求高，私有部署成為主流選擇；
  • 自定義邏輯難、費用高。