从RSA角度出发解析JWT原理

在今天的数字化世界中，安全地传递信息变得越来越重要。JSON Web Token（JWT）作为一种流行的开放标准，为简化服务器与客户端之间的安全交流提供了一种高效的方式。本文旨在深入解析JWT的工作原理，并通过示例演示如何使用JWT进行安全通信。我们将从JWT的基本组成部分讲起，探讨公密钥加密的原理，解释为什么JWT是安全的，以及如何验证JWT的有效性。

一、JWT介绍

1. JWT组成部分

JWT由三个部分组成，它们分别是头部（Header）、载荷（Payload）、和签名（Signature）。通过将这三部分用点（.）连接起来，形成了一个完整的JWT字符串。例如：xxxxx.yyyyy.zzzzz。

2. 头部（Header）

头部通常由两部分组成：令牌类型（typ）和签名算法（alg）。例如：

{
  "kid": "33bd1cad-62a6-4415-89a6-c2c816f3d3b1",
  "alg": "RS256"
}

• kid (Key ID)：密钥标识符，用于指明验证JWT签名时使用的密钥。在含有多个密钥的系统中，这可以帮助接收者选择正确的密钥进行验证。这里的值33bd1cad-62a6-4415-89a6-c2c816f3d3b1是一个UUID，唯一标识了用于签名的密钥。
• alg (Algorithm)：指明用于签名的算法，这里是RS256，表示使用RSA签名算法和SHA-256散列算法。这种算法属于公钥/私钥算法，意味着使用私钥进行签名，而用公钥进行验证。

3. 载荷（Payload）

载荷包含了所要传递的信息，这些信息以声明（claims）的形式存在。声明可以是用户的身份标识，也可以是其他任何必要的信息。载荷示例：

{
  "sub": "XcWebApp",
  "aud": "XcWebApp",
  "nbf": 1707373072,
  "iss": "http://localhost:63070/auth",
  "exp": 1707380272,
  "iat": 1707373072,
  "jti": "62e885c5-6b3f-49a2-aa10-b2e872a52b33"
}

• sub (Subject)：主题，标识了这个JWT的主体，通常是指用户的唯一标识。这里XcWebApp可能是一个应用或用户标识。
• aud (Audience)：受众，标识了这个JWT的预期接收者。这里同样是XcWebApp，意味着这个JWT是为XcWebApp这个应用或服务生成的。
• nbf (Not Before)：生效时间，这个时间之前，JWT不应被接受处理。这里的时间是Unix时间戳格式，表示JWT生效的具体时间。
• iss (Issuer)：发行者，标识了这个JWT的发行方。这里是http://localhost:63070/auth，表明JWT由本地的某个认证服务器发行。
• exp (Expiration Time)：过期时间，这个时间之后，JWT不再有效。同样是Unix时间戳格式，表示JWT过期的具体时间。
• iat (Issued At)：发行时间，JWT创建的时间。这提供了JWT的时间信息，也是Unix时间戳格式。
• jti (JWT ID)：JWT的唯一标识符，用于防止JWT被重放（即两次使用同一个JWT）。这里的值是一个UUID，确保了JWT的唯一性。

4. 签名（Signature）

签名是对头部和载荷的加密保护，确保它们在传输过程中未被篡改。根据头部中指定的算法（例如HS256），使用私钥对头部和载荷进行签名。

二、深入理解JWT签名验证

1. 签名生成

1. 哈希处理：首先对JWT的头部和载荷部分（经过Base64编码并用.连接的字符串）进行哈希处理，生成一个哈希值。这个步骤是为了确保数据的完整性，即使是微小的改动也会导致哈希值有很大的不同。
2. 私钥加密哈希值：然后使用发行者的私钥对这个哈希值进行加密，生成的结果就是JWT的签名部分。这个加密的哈希值（签名）附加在JWT的后面。

2. 签名验证

1. 哈希处理：接收方收到JWT后，会独立地对其头部和载荷部分进行同样的哈希处理，生成一个哈希值。
2. 公钥解密签名：接收方使用发行者的公钥对签名（加密的哈希值）进行解密，得到另一个哈希值。
3. 哈希值比较：比较这两个哈希值。如果它们相同，就证明了JWT在传输过程中未被篡改，因为只有相应的私钥能够生成一个对应的、能够通过公钥解密并得到原始哈希值的签名。

3. 为什么JWT是安全的

由于破解RSA算法的难度极高，没有私钥就无法生成有效的签名，因此无法伪造签名。这就是为什么使用公钥进行签名验证是安全的原因。

三、如何验证JWT是否有效

对于一个JWT，我们可以使用Base64解码，获取前两部分信息，可以进行token是否过期等验证，具体取决于前两部分具体内容，这是可以人为设置的。
对于签名部分，可以用公钥去验证其有效性（即是否被纂改）。

四、 Why JWT？

为什么是JWT？
首先是不可伪造的安全性，其次，因为你会发现，只要有公钥就可以验证JWT这种token，这也就意味着对于微服务来说，任意微服务都有能力自行验证JWT，而不需要额外的验证模块。这种自校验没有用到网络通信，性能十分好。同时，JWT有时间限制，一定程度上也提高了最坏情况的安全性。