微服务实现单点登录业务流程

在一个使用 Spring Boot 和 分布式微服务架构 的项目中，网关（Gateway）作为一个独立的微服务，使用 OAuth2 和 OpenID Connect (OIDC) 来实现单点登录（SSO）。客户的登录业务流程可以描述为以下几个关键步骤。

1. 客户请求访问资源

• 客户端（比如浏览器或移动应用）发送请求访问某个受保护的资源，例如某个微服务的API。由于所有请求都需要经过网关（Gateway），该请求首先到达网关。

2. 网关检测用户的身份认证状态

• 网关检查该请求中是否包含有效的 JWT Token（JSON Web Token）。如果请求没有 Token 或 Token无效，网关将认为用户未认证。

3. 重定向到 OAuth2 认证服务器

• 网关将未认证的请求重定向到 OAuth2/OIDC 认证服务器（如 Keycloak、Okta、Auth0，或 Spring Authorization Server）。认证服务器是负责处理用户身份验证的组件。
• 客户端浏览器被重定向到认证服务器的登录页面。

4. 用户登录

• 认证服务器向用户展示登录页面，用户在这里输入用户名和密码进行身份验证。
• 如果认证服务器支持社交登录（如通过QQ、webchat等第三方），用户可以选择使用这些外部提供商进行登录。

5. 认证服务器验证用户身份

• 认证服务器验证用户的凭证（用户名、密码或第三方认证），如果成功，则生成一个 授权码（Authorization Code）并将其重定向回网关。重定向的 URL 通常包括 Authorization Code 以及其他信息。

6. 网关用授权码换取 Access Token 和 ID Token

• 网关收到授权码后，会向认证服务器发送请求，使用授权码换取 Access Token 和 ID Token。
• Access Token 是OAuth2 认证流程中用于访问受保护资源的令牌。
• ID Token 是 OpenID Connect中提供的用于标识用户身份的令牌，其中包含用户的详细信息（如用户 ID、邮箱等）。

7. 网关保存 Token 并将其传递给下游服务

• 网关将获得的 Access Token 保存，并在客户后续的请求中将其附加到请求头中，以便传递给下游微服务。
• 同时，网关可以使用TokenRelay 过滤器，将 Access Token 传递给所有需要认证的下游服务（如 API 微服务）。

8. 下游微服务验证 Access Token

• 下游微服务接收到来自网关的请求时，会通过 Spring Security 配置为 资源服务器（ResourceServer）。它们会验证从网关传递来的 Access Token 是否有效。
• 如果 Token验证成功，微服务将允许访问受保护的资源，并响应请求。

9. 返回受保护资源

• 下游微服务完成处理后，将结果返回给网关。网关再将响应传递回客户端，用户就可以访问到请求的资源。
• 后续的每个请求都会携带 Access Token，网关和微服务会基于该 Token 进行身份验证，确保用户在授权范围内。

10. 关键组件和流程详细说明

1. OAuth2 和 OIDC

• OAuth2 是授权框架，主要负责 Access Token 的颁发，用于访问受保护资源。
• OIDC 是 OAuth2 的扩展，提供用户身份信息（如用户 ID、邮箱、名字等）通过 ID Token。

2. 授权码模式（Authorization Code Flow）

• 这是 OAuth2 的一种授权方式，特别适合 Web 应用。
• 用户登录后，网关使用授权码从认证服务器换取 Access Token 和 ID Token。

3. JWT Token

目前在 JWT 中用到三种 Token：Access Token、ID Token、Refresh Token。

1. Access Token

• 作用：用于访问受保护的资源或API。
• 特点：
  • 通常包含用户的权限信息（如角色、权限等）。
  • 有效期通常较短（如几分钟到几小时）。
  • 在访问API时，客户端需要在请求头中携带该token。

2. ID Token

• 作用：用于身份验证，表明用户的身份信息。
• 特点：
  • 主要用于OpenID Connect协议。
  • 包含用户的基本信息（如用户ID、用户名、邮箱等），用于验证用户身份。
  • 通常在用户登录后由身份提供者（如OAuth2.0认证服务器）发放。

3. Refresh Token

• 作用：用于获取新的access token。
• 特点：
  • 有效期通常较长（可以是几天到几个月）。
  • 客户端在access token过期后，可以使用refresh token向认证服务器请求新的access token，而无需重新登录。
  • 通常不会在客户端的请求中直接使用，而是保存在安全的地方。

4. 最佳实践

• 身份验证使用ID Token：ID Token主要用于身份验证，在单点登录（SSO）场景下，用于表明用户的身份。由于ID Token用于验证用户身份，过期时间相对较短可以确保身份信息的及时性。这里指定过期时间为 15分钟。
• 权限认证使用Access Token：Access Token用于访问受保护的资源（如API），其有效期较短有助于减少Token被滥用的风险。即使Token泄露，短期内失效的Token也能降低潜在攻击的影响。这里指定过期时间为 30分钟。
• Refresh Token：通过Refresh Token获取新的Access Token和ID Token，确保身份和权限验证能够无缝续期。因此其有效期通常更长。较长的Refresh Token有效期能够减少用户频繁登录的需求，提高用户体验。这里指定其过期时间为14天。不过，过长的有效期可能增加安全风险，因此在系统中实现Refresh Token的撤销机制，例如当用户注销或密码更改时使其失效。

4. Token Relay 机制

• Spring Cloud Gateway 使用 TokenRelay 过滤器将 AccessToken从网关传递到下游微服务，确保每个微服务都能从请求头中提取和验证 Token。

总结

整个流程可以概括为：

1. 客户端请求到达网关。
2. 网关检测是否有有效的 Token。
3. 如果没有有效 Token，网关重定向用户到 OAuth2 认证服务器。
4. 用户在认证服务器登录，认证服务器返回授权码。
5. 网关用授权码换取 Access Token 和 ID Token。
6. 网关将 Access Token 转发给下游微服务。
7. 微服务验证 Access Token 后提供资源。

在这个过程中，OAuth2 负责授权，而 OpenID Connect (OIDC) 负责提供用户身份信息，确保整个系统中只有一次登录操作即可访问多个服务（即单点登录）。