JWT令牌与微服务

1. 什么是JWT

JWT（JSON Web Token）是一种开放标准(RFC 7519)，它定义了一种紧凑且自包含的方式，用于作为JSON对象在各方之间安全地传输信息。JWT通常用于身份验证和信息交换。
以下是JWT的一些关键特性：
紧凑：JWT可以被发送在URL、POST参数或HTTP头部中，并且由于其体积小，因此非常适合移动场景。
自包含：负载中包含了用户的身份信息，因此可以在不同系统间传递而无需查询数据库。
签名：JWT可以通过使用HMAC算法或者RSA的公私钥对进行签名，确保令牌的内容没有被篡改。
一个典型的JWT由三部分组成，它们之间用.分隔：
Header（头部）
Payload（载荷）
Signature（签名）

2. JWT 在微服务应用中的举例图

2.1. 请求令牌

客户端通过HTTPS向Apigee/IAM平台发送POST请求，请求URL为https://mycompanyname-dev.apigee.net/v1/oauth2/token。
请求体包含client_id、client_secret和grant_type参数。也就是用户名，密码，令牌类型

{
"client_id": "9ed7be85-a185-test-b37g-3-service1",
"client_secret": "clientsecretTY78",
"grant_type": "client_credentials"
}

2.2. 身份验证服务器返回令牌

 

2.2.1. 生成token流程

• 提取参数：从请求体中提取client_id、client_secret和grant_type等参数。确保这些参数的格式正确且不为空。
• 验证client_id和client_secret：检查client_id是否存在于配置或数据库中。使用client_id和client_secret进行身份验证，确保它们匹配。并使用client_id找到服务端对应的servicesecret用于生成签名。
• 根据grant_type选择相应的授权流程：
  authorization_code：需要额外的授权码（Authorization Code）。
  client_credentials：直接使用客户端凭据生成令牌。
  password：需要用户名和密码。
  refresh_token：使用刷新令牌请求新的访问令牌。
  implicit：适用于单页应用（SPA），不需要回调。
• 创建JWT：
  生成一个JSON Web Token (JWT)，包含必要的声明（Claims）。
  常见的声明包括：
  iss（Issuer）：发行者信息。
  sub（Subject）：主题信息，通常是用户ID。
  aud（Audience）：接收者信息。
  exp（Expiration Time）：过期时间。
  iat（Issued At）：签发时间。
  jti（JWT ID）：唯一标识符。
  其他自定义声明，如角色、权限等。
  对JWT进行签名，可以使用对称加密（如HMAC）或非对称加密（如RSA、ECDSA）。
• 构建响应：
  包含访问令牌（Access Token）、刷新令牌（Refresh Token，如果适用）、过期时间等信息。

      {"access_token": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0LWlwaWF0aWF0ijoxNzM0M0NzcwNTI3LCJleHAiOjE3MzQ3NzA4Mjd9.svHAdBOmuYHaRkRXHMfEUJlwSrSd8qIK7utLbkDxps6-8","token_type": "Bearer","expires_in": 3600,"refresh_token": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0LWlwaWF0aWF0ijoxNzM0M0NzcwNTI3LCJleHAiOjE3MzQ3NzA4Mjd9.svHAdBOmuYHaRkRXHMfEUJlwSrSd8qIK7utLbkDxps6-8"}

2.2.2 Token组成部分

Token由三部分组成，每部分由"."分割
如举例中的eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0LWlwaWF0aWF0ijoxNzM0M0NzcwNTI3LCJleHAiOjE3MzQ3NzA4Mjd9.svHAdBOmuYHaRkRXHMfEUJlwSrSd8qIK7utLbkDxps6-8

1. 第一部分为Header（头部）信息的base64
2. 第二部分为负载Payload（载荷）信息的base64
   JWT的负载部分的键值对具有以下重要作用(可选)：
   - 传递用户信息：包含用户的基本信息和元数据。
   - 定义权限和角色：用于授权和访问控制。
   - 设置有效期：确保令牌的安全性和时效性。
   - 提供唯一标识符：防止重放攻击。
   - 支持分布式验证：提高系统的可扩展性和可用性。
   - 增强审计和调试能力：便于追踪和分析令牌的使用情况。
3. 第三部分为Signature（签名）签名部分用于验证令牌的完整性和来源。签名是通过将头部和负载连接起来，并使用指定的签名算法和一个密钥生成的。这里的秘钥可以是客户端请求进来的秘钥，也可以是服务端保存的对应clientId的服务端秘钥。具体使用那种方式取决于具体架构实现方式。
   

在JWT（JSON Web Token）中，使用对称加密算法（如HMAC）时，客户端和服务端可以共享同一个密钥。也可以通过不同的密钥管理策略来增强安全性(clientid,clientsecret,servicesecret)。以下是使用两个不同的密钥（或定期更换密钥）的好处：

 1. 增强安全性
密钥隔离：使用不同的密钥可以减少密钥泄露的风险。即使一个密钥被泄露，另一个密钥仍然可以保持安全。
密钥轮换：定期更换密钥可以进一步提高安全性。如果旧密钥被泄露，新密钥可以立即启用，确保系统安全。

 2. 分布式验证
独立验证：客户端和服务端可以独立验证JWT的有效性，而不需要每次都与中心服务器通信。这提高了系统的可扩展性和可用性。
减少网络延迟：客户端和服务端可以在本地验证JWT，减少了与中心服务器的通信延迟，提高了响应速度。

 3. 防止篡改
签名验证：使用对称加密算法时，签名只能由持有相同密钥的一方生成和验证。通过使用不同的密钥，可以确保只有授权方能够生成有效的签名。

 4. 灵活性
多服务验证：不同的服务可以共享相同的密钥来验证JWT，而不需要每个服务都持有多个密钥。这简化了多服务架构中的认证和授权流程。
跨域验证：不同领域的服务可以通过共享密钥来验证JWT，增强了跨域应用的安全性和灵活性。

 5. 性能提升
减少计算负担：客户端和服务端只需要进行签名验证，而不是签名生成，这通常比签名生成操作更高效。
并行处理：多个客户端和服务端可以并行验证JWT，提高了整体系统的性能。

 6. 可审计性
审计追踪：由于签名是由服务端生成的，所有签发的JWT都可以追溯到特定的服务端，便于审计和故障排查。

 示例场景
假设一个系统中有多个微服务，每个微服务都需要验证用户的JWT。在这种情况下，使用两个不同的密钥（或定期更换密钥）的好处如下：

1. 服务端生成JWT：
   - 服务端使用私钥生成JWT，并将其发送给客户端。
   - JWT包含用户信息、权限等声明，并通过私钥签名。

2. 客户端和服务端验证JWT：
   - 客户端接收到JWT后，可以使用公钥验证签名的有效性。
   - 微服务接收到带有JWT的请求后，也可以使用公钥验证签名的有效性。

 具体步骤

使用两个不同的密钥
1. 生成密钥对：
   - 服务端生成一对密钥（例如'key1'和'key2'）。
   - 'key1'用于当前JWT的签名，'key2'作为备用密钥。

2. 分发密钥：
   - 将'key1'分发给客户端和服务端，用于验证当前JWT。
   - 'key2'暂时不公开，仅保存在服务端。

3. 密钥轮换：
   - 在预定的时间点，服务端开始使用'key2'生成新的JWT。
   - 同时，将'key2'分发给客户端和服务端，用于验证新的JWT。
   - 'key1'继续用于验证旧的JWT，直到它们过期。

4. 密钥失效：
   - 旧密钥（'key1'）在所有相关的JWT过期后失效。
   - 新密钥（'key2'）成为唯一的验证密钥。

 总结
使用两个不同的密钥（或定期更换密钥）在对称加密中具有以下主要好处：
增强安全性：减少密钥泄露的风险，通过密钥轮换进一步提高安全性。
分布式验证：客户端和服务端可以独立验证JWT的有效性，减少网络延迟。
防止篡改：确保只有授权方能够生成有效的签名。
灵活性：简化多服务架构中的认证和授权流程。
性能提升：提高系统的整体性能和响应速度。
可审计性：便于审计和故障排查。

这种方式使得JWT在现代分布式系统中成为一种高效且安全的认证和授权机制。

 

 2.3. 获取Token后发送业务请求

当用户获取到Token后再Token 值前面加上Bear(加Bear是一种OAuth 2.0规范,防止误用，区分其它类型令牌)。 Bear ****
将Token和业务数据发送到请求服务Gateway。

2.4. Gateway验证Token转发请求到具体服务

当用户请求来到Gateway后，Gateway 

• 提取Token：从Authorization头中提取Token。
• 验证Token：
  解码Token，检查格式。
  验证签名。
  检查exp和nbf声明。
  验证iss和aud声明。
• 授权检查：检查用户是否有权访问/api/resource。
• 日志记录：记录请求信息。
• 路由和转发：将请求转发到后端服务service.example.com/api/resource，并在请求头中附加用户信息。
• 错误处理：如果验证失败，返回401 Unauthorized或403 Forbidden。

2.4. 业务服务器处理请求并返回 

业务服务器处理请求并返回用户终端，完成请求流程。 

更多细节可参考
JWT 与 OAuth 2.0，Apigee-CSDN博客