认识 JWT(JSON Web Token)

/ 技术JWTAuthentication / 没有评论 / 332浏览

认识 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。

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

签名(Signature)

其实就是对 headerpayload 进行签名,签名公式如下:

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 哈希算法。

工作逻辑(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

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

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

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

缺点

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

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

主要流程如下:

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

2019521101948-jwt-sequence-diagram-2

优点

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

特点

JWT与 OAuth2 的区别

参考链接(Refer)