OAuth2.0 在分布式微服务下的统一认证授权

信徒_

于 2024-09-24 19:57:24 发布

阅读量691

点赞数 25

文章标签：分布式微服务架构

本文链接：https://blog.csdn.net/qq_41893505/article/details/142472034

版权

1. 微服务的认证方案

统一在网关层面（SpringCloud Gateway）认证鉴权，微服务只负责自身业务，代码耦合性低，方便后续的扩展。
把认证服务器独立出来，和网关解耦。

架构：
在这里插入图片描述
涉及角色

客户端：需要访问微服务资源。
网关：负责转发、认证、鉴权。
OAuth2.0授权服务：负责认证授权颁发令牌。
微服务集合：提供资源的一系列服务。

流程

客户端发出请求给网关获取令牌。
网关收到请求，直接转发给授权服务。
授权服务验证用户名、密码等一系列身份，通过则颁发令牌给客户端。
客户端携带令牌请求资源，请求直接到了网关层。
网关对令牌进行校验（验签、过期时间校验…）、鉴权（对当前令牌携带的权限）和访问资源所需的权限进行比对，如果权限有交集则通过校验，直接转发给微服务。
微服务进行逻辑处理。

例：springcloud检查令牌是否存在

@Configuration
public class GatewayConfig {

    @Bean
    public RouteLocator customRoutes(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("my_service", r -> r.path("/my-service/**")
                .filters(f -> f.filter((exchange, chain) -> {
                    // 检查令牌是否存在
                    String token = exchange.getRequest().getHeaders().getFirst("Authorization");
                    if (token == null || !token.startsWith("Bearer ")) {
                        return Mono.error(new RuntimeException("Unauthorized")); // 或返回401状态
                    }
                    return chain.filter(exchange);
                }))
                .uri("http://localhost:8081")) // 转发请求到后端服务
            .build();
    }
}

2. redis存储token的意义

OAuth 2.0 的基本工作原理是让客户端在每次请求时通过 HTTP 请求头中携带 token，来证明其身份和授权，这里无论token是否存储在redis中，都是一样的，借助于redis的作用在于：

Token 验证加速：可以避免每次都调用授权服务器来验证 token 的有效性。通过 Redis 这样的缓存系统，微服务或网关可以快速查找token 的有效性，提升系统性能。
集中管理 Token：通过 Redis，可以方便地实现 token 的管理，如支持 Token 的失效、吊销或黑名单等功能。

3. 保证JWT不被泄露和滥用

JWT（JSON Web Token）本身并不能完全保证不被泄露和滥用，但可以通过一些最佳实践来增强其安全性：

1. 使用 HTTPS

确保所有传输 JWT 的请求都通过 HTTPS 进行，以防止中间人攻击（MITM）和窃听。

2. 有效期设置

设置合理的有效期，access token 应该短期有效（如几分钟），而 refresh token 可以稍长。这样可以降低被滥用的风险。

4. 令牌签名

使用强加密算法（如 RS256）对 JWT 进行签名，以确保其完整性和真实性，防止篡改。

5. 权限控制

通过 scopes 限制 JWT 的权限，确保 token 只能访问必要的资源。

6. 黑名单机制

实现令牌撤销机制，允许在用户注销或怀疑令牌被盗用时，将其加入黑名单。

4. 授权第三方QQ和微信的登录

在Spring Cloud分布式微服务系统中，结合OAuth2.0认证中心和Spring Cloud Gateway作为鉴权中心来授权第三方QQ和微信登录，通常可以按照以下步骤进行：

1. 用户请求登录：

用户在客户端应用中选择使用QQ或微信登录，客户端向Spring Cloud Gateway发送请求。

2. 重定向到第三方认证：

Gateway将请求转发到OAuth2.0认证中心，认证中心生成一个重定向URL，包含客户端ID、重定向URI等信息，返回给客户端。

3. 用户在第三方平台登录：

客户端将用户重定向到QQ或微信的登录页面，用户完成登录并授权。

4. 接收授权码：

第三方平台将用户重定向回OAuth2.0认证中心，携带授权码和状态参数。

5. 请求访问令牌：

OAuth2.0认证中心使用授权码向QQ或微信的Token Endpoint请求访问令牌，验证成功后获取用户信息。

6. 用户信息处理：

认证中心检查用户是否已存在于CRM系统中，若不存在则创建新用户，若存在则更新用户信息（用户名和头像等）。

7. 生成内部令牌：

认证中心生成自己的JWT或其他类型的访问令牌，返回给Spring Cloud Gateway。

8. 返回给客户端：

Gateway接收到内部令牌后，将其返回给客户端应用，用户即可使用该令牌访问CRM系统的其他微服务。

9. 鉴权过程：

当用户访问CRM的其他API时，Gateway会验证该令牌的有效性，并进行相应的权限控制。

通过这种方式，OAuth2.0认证中心和Spring Cloud Gateway有效协同，实现了对第三方QQ和微信登录的授权管理。

5. 客户端问题

如果在Spring Cloud搭建的CRM系统中没有其他系统授权的登录业务，那么认证中心主要负责内部用户的身份验证和权限管理。在这种情况下，客户端的问题就不需要特别考虑，因为所有用户都会直接通过CRM系统进行身份验证，不涉及第三方认证或授权。因此，认证中心可以专注于处理用户的注册、登录、权限控制等内部功能。