JWT 教程

简介

官方简介：

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

翻译结果：

JSON Web 令牌 （JWT） 是一种开放标准 （RFC 7519），它定义了一种紧凑且独立的方式，用于在各方之间以 JSON 对象的形式安全地传输信息。此信息可以验证和信任，因为它是经过数字签名的。JWT 可以使用密钥（使用 HMAC 算法）或使用 RSA 或 ECDSA 的公钥/私钥对进行签名。

尽管 JWT 可以加密以提供各方之间的保密性，但我们将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌则向其他方隐藏这些声明。当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方才是签名的一方。

官网地址: https://jwt.io/

传统的 session 认证

http 协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据 http 协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为 cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于 session 认证。

但是这种基于 session 的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于 session 认证应用的问题就会暴露出来.

基于 session 认证所显露的问题

Session: 每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言 session 都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。

扩展性: 用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

CSRF: 因为是基于 cookie 来进行用户识别的, cookie 如果被截获，用户就会很容易受到跨站请求伪造的攻击。

基于 token 的鉴权机制

基于 token 的鉴权机制类似于 http 协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于 token 认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

流程上是这样的：

• 用户使用用户名密码来请求服务器
• 服务器进行验证用户的信息
• 服务器通过验证发送给用户一个 token
• 客户端存储 token，并在每次请求时附送上这个 token 值
• 服务端验证 token 值，并返回数据

注意: 这个 token 必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持 CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了 Access-Control-Allow-Origin: *。

概念

• Header 头信息
• Payload 装载的信息/元数据/元信息
• Signature 签名

结构大致为如下：xxxxx.yyyyy.zzzzz

Header 头信息

通常由两部分组成: Token 的类型(即 JWT)和所使用的签名算法(如 HMAC SHA256 或 RSA)。

{
  "alg": "HS256",
  "typ": "JWT"
}

然后，此 JSON 被 Base64Url 编码以形成 JWT 的第一部分。

Payload 装载的信息/元数据/元信息

令牌的第二部分是有效负载，其中包含声明。声明是有关实体（通常是用户）和其他数据的语句。 有三种类型的声明：已注册、公共和私人声明。

• 已注册声明：这些是一组预定义的声明，这些声明不是必需的，但建议使用，以提供一组有用的、可互操作的声明。其中一些是：iss（发行人），exp（到期时间），sub（主题），aud（受众）等。

  • iss: jwt 签发者
  • sub: jwt 所面向的用户
  • aud: 接收 jwt 的一方
  • exp: jwt 的过期时间，这个过期时间必须要大于签发时间
  • nbf: 定义在什么时间之前，该 jwt 都是不可用的.
  • iat: jwt 的签发时间
  • jti: jwt 的唯一身份标识，主要用来作为一次性 token,从而回避重放攻击

  请注意，声明名称只有三个字符长，因为 JWT 应该是紧凑的。

• 公共声明：这些可以由使用 JWT 的人随意定义。但为了避免冲突，它们应该在 IANA JSON Web 令牌注册表中定义，或者定义为包含抗冲突命名空间的 URI。

• 专用声明：这些是创建的自定义声明，用于在同意使用它们的各方之间共享信息，既不是注册声明也不是公共声明。

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Base64Url 编码以形成 JSON Web 令牌的第二部分。

请注意，对于签名令牌，此信息虽然受到篡改保护，但任何人都可以读取。不要将机密信息放在 JWT 的有效负载或标头元素中，除非它已加密。

签名

要创建签名部分，您必须获取编码的标头、编码的有效负载、机密、标头中指定的算法并对其进行签名。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

签名用于验证消息在此过程中未被更改，并且在使用私钥签名的令牌的情况下，它还可以验证 JWT 的发件人是否是它所说的人。

secret 不公开，保存在服务器端的，jwt 的签发生成也是在服务器端的，secret 就是用来进行 jwt 的签发和验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个 secret, 那就意味着客户端是可以自我签发 jwt 了

如何构建 JWT token

推荐采用 jjwt 工具包生成。

<dependency>
    <groupId>com.auth0</groupId>
     <artifactId>java-jwt</artifactId>
     <version>$version</version>
 </dependency>

工作原理

在身份验证中，当用户使用其凭据成功登录时，将返回 JSON Web 令牌。由于令牌是凭据，因此必须非常小心以防止安全问题。通常，令牌的保留时间不应超过所需时间。

每当用户想要访问受保护的路由或资源时，用户代理都应发送 JWT，通常在使用持有者架构的授权标头中发送。标头的内容应如下所示：

Authorization: Bearer <token>

下图显示了如何获取和使用 JWT 访问 API 或资源：

1. 应用程序或客户端向授权服务器请求授权。
2. 授予授权后，授权服务器将向应用程序返回访问令牌。
3. 应用程序使用访问令牌访问受保护的资源(如 API)。