认识 JWT

JSON Web Token（JWT）是什么

JSON Web Token (JWT)是一个开放标准RFC 7519，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。

更通俗的讲：为了在你的 app（web或者移动端）中辨识或授权用户，在 header 或者页面（或者 API）的 url 中放置一个基于标准的 token，它表明了这个用户已经登录并且被允许获取到他想要的内容。

JSON Web Tokens 使用场景

认证授权(Authentication)

这是使用 JWT 的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的 JWT 的一个特性，因为它的开销很小，并且可以轻松地跨域使用。

信息交换(Exchange)

对于安全的在各方之间传输信息而言，JSON Web Tokens 无疑是一种很好的方式。因为 JWTs 可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。因此对于这种场景，你的信息是可以透明公开的，但是又不希望信息被篡改的场合，这种场景使用 JWT 是比较合适的。

JWT 的原理(JWT Logic)

长什么样子(What Like)

JSON Web Token 由三部分组成，它们之间用圆点(.)连接。头部和负载是对应的 JSON 通过 Base64 编码来的，因此解码后就能看到原信息。这就是为什么不推荐把私密信息放在 JWT 中的原因。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.                                       // 头部
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ. // 载荷
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c                                 // 签名

头部(Header)

header 典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。

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

载荷(Payload)

JWT 的第二部分是 payload，它包含声明（要求）。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。

Registered claims : 这里有一组预定义的声明，它们不是强制的，但是推荐。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。
Public claims : 可以随意定义。
Private claims : 用于在同意使用它们的各方之间共享信息，并且不是注册的或公开的声明。

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

签名(Signature)

其实就是对 header 和 payload 进行签名，签名公式如下：

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

签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的 token，它还可以验证 JWT 的发送方是否为它所称的发送方。

看一个我们实际项目中的 Token

eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbmlzdHJhdG9yIiwic2NvcGVzIjpbXSwidXNlcklkIjoiOGE0OThkZGQ2OWIzNTY3YzAxNjliMzcwMGY1ZDAwMDAiLCJpc3MiOiJpbHV2YXRhci5haSIsImlhdCI6MTU1ODM0NDQyNSwiZXhwIjoxNTU4MzUxNjI1fQ.JUy0yhjM8c7IR3lkJVGeYNJQ9HaqysrxeuzA1x-TfS3h7-qUnfyBOCVokccbcA-MF8O9Dh9JfG16y0wtvV2cPw

解码内容如下：

# header
{
  "alg": "HS512"
}
# payload
{
  "sub": "administrator",
  "scopes": [],
  "userId": "8a498ddd69b3567c0169b3700f5d0000",
  "iss": "iluvatar.ai",
  "iat": 1558344425,
  "exp": 1558351625
}

内容很简单，header 中说明了签名算法是 SHA256，类似于 MD5 哈希算法。

sub (subject) 可理解为对象，这里就是我们的用户名。
scopes 可理解为权限限制的范围，也就是可以把用户权限放里面。结合我们的使用场景，对权限的要求的实时性，每次从数据库查询。
userId 为自定义的字段，用户主键
iss token 的发行商
iat token 的发行时间。可以用于判断 JWT 的发行时间长。
exp (expiration time) 到期时间戳（已过期的令牌会被拒绝）。注意：如规范中所定义，以秒为单位。
jti (JWT ID) 编号
nbf (Not Before)生效时间

工作逻辑(Logic)

在认证的时候，当用户用他们的凭证成功登录以后，一个 JSON Web Token 将会被返回。此后，token 就是用户凭证了，你必须非常小心以防止出现安全问题。一般而言，你保存令牌的时候不应该超过你所需要它的时间。之前研究 keycloak JWT Token 的有效时间只有5分钟。我们当前系统设计为1小时。

无论何时用户想要访问受保护的路由或者资源的时候，用户代理（通常是浏览器）都应该带上 JWT，典型的，通常放在 Authorization header中，用Bearer schema。

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJrZXkiOiJ2YWwiLCJpYXQiOjE0MjI2MDU0NDV9.eUiabuiKv-8PYk2AkGY4Fb5KMZeorYBLw261JPQD5lM

服务器上的受保护的路由将会检查 Authorization header 中的 JWT 是否有效，如果有效，则用户可以访问受保护的资源。如果 JWT 包含足够多的必需的数据，那么就可以减少对某些操作的数据库查询的需要，尽管可能并不总是如此。

如果 token 是在授权头（Authorization header）中发送的，那么跨源资源共享(CORS)将不会成为问题，因为它不使用 cookie。下面这张图显示了如何获取JWT以及使用它来访问 APIs 或者资源：

2019520202948-jwt

应用（或者客户端）想授权服务器请求授权。例如，如果用授权码流程的话，就是/oauth/authorize
当授权被许可以后，授权服务器返回一个 access token 给应用
应用使用 access token 访问受保护的资源（比如：API）

基于Token的身份认证与基于服务器的身份认证(Trandition And Token Authentication)

基于服务器的身份认证(Trandition Authentication)

用户向服务器发送用户名和密码。
服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
服务器向用户返回一个 session_id，写入用户的 Cookie。
用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

缺点

这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。
每次用户认证通过以后，服务器需要创建一条记录保存用户信息，通常是在内存中，随着认证通过的用户越来越多，服务器的在这里的开销就会越来越大。
用户很容易受到 CSRF 攻击。

基于 JWT Token 的身份认证(JWT Token Authentation)

相同点是，它们都是存储用户信息；然而，Session 是在服务器端的，而 JWT 是在客户端的。Session 方式存储用户信息的最大问题在于要占用大量服务器内存，增加服务器的开销。而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。Session 的状态是存储在服务器端，客户端只有 session id；而 Token 的状态是存储在客户端。

主要流程如下：

用户携带用户名和密码请求访问
服务器校验用户凭据
应用提供一个 token 给客户端
客户端存储 token，并且在随后的每一次请求中都带着它
服务器校验 token 并返回数据

2019521101948-jwt-sequence-diagram-2

优点

无状态和可扩展性：Tokens 存储在客户端。完全无状态，可扩展。我们的负载均衡器可以将用户传递到任意服务器，因为在任何地方都没有状态或会话信息。
安全：Token 不是 Cookie。（The token, not a cookie.）每次请求的时候 Token 都会被发送。而且，由于没有 Cookie 被发送，还有助于防止 CSRF 攻击。即使在你的实现中将 token 存储到客户端的 Cookie 中，这个 Cookie 也只是一种存储机制，而非身份认证机制。没有基于会话的信息可以操作，因为我们没有会话!

还有一点，token 在一段时间以后会过期，这个时候用户需要重新登录。这有助于我们保持安全。还有一个概念叫 token 撤销，它允许我们根据相同的授权许可使特定的 token 甚至一组 token 无效。

特点

JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
JWT 不加密的情况下，不能将秘密数据写入 JWT。
JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑，一般使用黑名单机制，将逻辑上废除的 Token 存储到数据库或内存中。
JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

JWT与 OAuth2 的区别

OAuth2 是一种授权框架，JWT 是一种认证协议（安全标准）
OAuth2 提供了一套详细的授权机制（指导）。用户或应用可以通过公开的或私有的设置，授权第三方应用访问特定资源。
JWT 应用场景主要是无状态的分布式 API
OAuth2 包含四种授权方式，可以结合传统的有状态的场景使用，也能结合 JWT 在无状态的场景使用

参考链接(Refer)

http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
https://github.com/dwyl/learn-json-web-tokens/blob/master/README-zh_CN.md
https://mp.weixin.qq.com/s/E0cDiRZsPHVQDR72hktxsA
https://tools.ietf.org/html/rfc7519
https://www.jianshu.com/p/1870f456b334

本文由 zealzhangz 创作，采用知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: 2019/05/25 13:07

认识 JWT(JSON Web Token)