基于Spring Boot Authorization Server的自研SSO及多应用交互问题咨询

1. A服务获取Access Token后与B服务通信的方式 #

• 发送请求时，将Access Token放在HTTP请求的Authorization请求头中，格式为：Bearer <你的Access Token内容>
• B服务接收到请求后，需完成以下验证步骤：
  1. 验证令牌签名有效性（若为JWT格式，用授权服务器的公钥验签）
  2. 检查令牌的exp（过期时间）字段是否未到期
  3. 确认令牌的aud（受众）字段包含B服务本身，确保令牌是颁发给B服务使用的
  4. 校验令牌的iss（签发者）字段为自研授权服务器，防止伪造令牌
• 验证通过后，解析令牌中的用户身份、权限等声明信息，再处理对应业务请求
• 建议使用JWT格式的Access Token，这样B服务可本地完成验证，无需每次调用授权服务器，提升系统性能

2. 用户登录B服务后获取A、C服务访问权限的方案 #

• 首先，用户登录B服务时必须通过自研授权服务器完成认证（比如采用OAuth2.0授权码模式）：B服务跳转至授权服务器，用户完成身份验证后，授权服务器返回授权码，B服务用授权码换取包含用户权限信息的ID Token和Access Token
• 授权服务器需维护用户-角色-应用权限关联数据库：记录用户对应的角色，以及每个角色允许访问哪些服务（A/C）的具体权限
• 当用户需要访问A或C服务时：
  1. 若用户已有针对A/C的有效Access Token，直接按照问题1的方式发起请求
  2. 若无对应令牌，B服务引导用户跳转至授权服务器，通过scope参数指定访问A/C所需的权限范围；由于用户已在授权服务器拥有活跃SSO会话，无需重新登录，授权服务器直接颁发对应A/C的Access Token
• 核心是授权服务器的权限管理模块，要能根据用户身份和目标应用，生成包含对应权限声明的令牌

3. 自研Authorization Server实现SSO的可行性 #

完全可以实现，只要遵循OAuth2.0和OpenID Connect（OIDC）的标准流程，无需依赖第三方工具。核心实现要点包括：

• 全局会话管理：授权服务器维护用户的全局认证会话，比如用HTTP Cookie存储会话ID，会话中记录用户认证状态、过期时间等信息
• 客户端配置：将A、B、C三个服务配置为授权服务器的OAuth2.0客户端，每个客户端分配唯一的client_id和client_secret，并约定授权回调地址
• SSO登录流程：
  1. 用户访问未登录的应用（如A），应用跳转至授权服务器的认证端点
  2. 授权服务器检查用户是否有活跃全局会话：若有，直接返回授权码给应用；若无，引导用户完成认证，创建全局会话后再返回授权码
  3. 应用用授权码换取ID Token和Access Token，完成本地登录
• SSO注销流程：用户在任意应用发起注销请求时，应用先销毁本地会话，再跳转至授权服务器的注销端点，授权服务器销毁全局会话，并通过回调接口通知其他已登录应用注销本地会话
• 令牌管理：自行实现JWT的非对称签名（授权服务器持私钥签名，客户端持公钥验签）、令牌过期刷新等功能

内容的提问来源于stack exchange，提问作者Bhushan Rohankar