jwt : Json Web Token

1.jwt和OAuth的区别：

OAuth2是一种授权框架 ，JWT是一种认证协议
OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app)，而JWT是用在前后端分离, 需要简单的对后台API进行保护时使用。

2.jwt的使用场景

  • Authorization (授权) ：一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。
  • Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式

3.jwt的结构

jwt由三部分组成，他们之间用圆点(.)连接。这三部分分别是：
  • Header
  • Payload
  • Signature
    所以，一个jwt的组成看起来是这个样子的：
xxxxx.yyyyy.zzzzz

接下来，具体看一下每一部分：

  • Header header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。
    例如：
{
    'alg': "HS256",
    'typ': "JWT"
}

然后，用Base64对这个JSON编码就得到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',
    "admin":true
}

对payload进行Base64编码就得到JWT的第二部分
注意，不要在JWT的payload或header中放置敏感信息，除非它们是加密的。

  • Signature

为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的那个，然对它们签名即可。
例如：
HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

4.jwt是如何工作的

在认证的时候，当用户用他们的凭证成功登录以后，一个JSON Web Token将会被返回。此后，token就是用户凭证了，你必须非常小心以防止出现安全问题。一般而言，你保存令牌的时候不应该超过你所需要它的时间。
无论何时用户想要访问受保护的路由或者资源的时候，用户代理（通常是浏览器）都应该带上JWT，典型的，通常放在Authorization header中，用Bearer schema。header应该看起来是这样的：

Authorization: Bearer

服务器上的受保护的路由将会检查Authorization header中的JWT是否有效，如果有效，则用户可以访问受保护的资源。如果JWT包含足够多的必需的数据，那么就可以减少对某些操作的数据库查询的需要，尽管可能并不总是如此。
如果token是在授权头（Authorization header）中发送的，那么跨源资源共享(CORS)将不会成为问题，因为它不使用cookie。

jwt token redis token区别_客户端


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

5.jwt的缺点

  1. 安全性
    由于jwt的payload是使用base64编码，没有加密，因此jwt中不能存储敏感数据。而session是存储再服务端的，相对来说更安全
  2. 性能
    jwt太长，由于是无状态的使用jwt，所有的数据都被放到jwt中，如果还要进行一些数据交换，那载荷会更大，经过编码之后的jwt太长，cookie中一般放不下。而sessionId使用的是一个字符串，因此使用jwt的http请求开销比session开销大的多。
  3. 一次性
    无状态是jwt的特点，但也导致了这个问题，jwt是一次性的。想修改里面的内容，就必须签发一个新的jwt。
    （1）无法废弃通过上面jwt的验证机制可以看出来，一旦签发一个jwt，在到期之前就会始终有效，无法中途废弃。例如你在payload中存储了一些信息，当信息需要更新时，则重新签发一个jwt，但是由于旧的jwt还没过期，拿着这个旧的jwt依旧可以登录，那登录后服务端从jwt中拿到的信息就是过时的。为了解决这个问题，我们就需要在服务端部署额外的逻辑，例如设置一个黑名单，一旦签发了新的jwt，那么旧的就加入黑名单（比如存到redis里面），避免被再次使用。
    （2）续签如果你使用jwt做会话管理，传统的cookie续签方案一般都是框架自带的，session有效期30分钟，30分钟内如果有访问，有效期被刷新至30分钟。一样的道理，要改变jwt的有效时间，就要签发新的jwt。最简单的一种方式是每次请求刷新jwt，即每个http请求都返回一个新的jwt。这个方法不仅暴力不优雅，而且每次请求都要做jwt的加密解密，会带来性能问题。另一种方法是在redis中单独为每个jwt设置过期时间，每次访问时刷新jwt的过期时间。

适合使用jwt的场景：

  • 有效期短
  • 只希望被使用一次