单点登录实现

常用框架的认证方案及问题

• 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）作为通用方案，因为：
  • 企业不愿将用户数据放到第三方平台；
  • 数据合规要求高，私有部署成为主流选择；
  • 自定义逻辑难、费用高。