基于.NetCore3.1系列 —— 认证方案之初步认识JWT

前言

现在越来越多的项目或多或少会用到JWT，为什么会出现使用JWT这样的场景的呢？

假设现在有一个APP，后台是分布式系统。APP的首页模块部署在上海机房的服务器上，子页面模块部署在深圳机房的服务器上。此时你从首页登录了该APP，然后跳转到子页面模块。session在两个机房之间不能同步，用户是否需要重新登录？

传统的方式（cookie+session）需要重新登录，用户体验不好。session共享（在多台物理机之间传输和复制session）方式对网络IO的压力大，延迟太长，用户体验也不好。

说到这大家可能会想到，用服务器的session_id存储到cookies中也能做到，为什么非要用token呢？网上有许多文章来比较token和session的优缺点，其实，开发web应用的话用哪种都行。但如果是开发api接口，前后端分离，最好使用token，为什么这么说呢，因为session+cookies是基于web的。但是针对 api接口，可能会考虑到移动端，app是没有cookies和session的。

Session方式存储用户信息的最大问题在于要占用大量服务器内存，增加服务器的开销。

而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端

原理

JSON Web Token（缩写 JWT）

JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，以后，用户与服务端通信的时候，都要发回这个 JSON 对象。

服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。

服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

组合

JWT 的三个部分依次是：Header（头部）、Payload（负载）、Signature（签名）

写成一行，就是下面的样子。

Header.Payload.Signature

一、Header

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

        {
          "alg": "HS256", //alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）
          "typ": "JWT"   //typ属性表示这个令牌（token）的类型（type）
        }

然后用Base64对这个JSON编码就得到JWT的第一部分

二、Payload

JWT的第二部分是payload，它包含声明（要求）。声明是关于实体(通常是用户)和其他数据的声明

JWT 规定了7个官方字段

• iss (issuer)：签发人
• exp (expiration time)：过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}
注意，不要在JWT的payload或header中放置敏感信息，除非它们是加密的

三、Signature

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

为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的那个，然对它们签名即可。按照下面的公式产生签名。

HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用”点”（.）分隔，就可以返回给用户。

开始

一、客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

Authorization: Bearer <token>

二、JWT 就放在 POST 请求的数据体里面，那么跨源资源共享(CORS)将不会成为问题，因为它不使用cookie

1.应用（或者客户端）想授权服务器请求授权。例如，如果用授权码流程的话，就是/oauth/authorize

2.当授权被许可以后，授权服务器返回一个access token给应用

3.应用使用access token访问受保护的资源（比如：API）

特点

1. JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。

2. JWT 不加密的情况下，不能将秘密数据写入 JWT。

3. JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。

4. JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

注意：

JWT 是 JSON 格式的被加密了的字符串

JWT 的核心是密钥，就是 JSON 数据。这是你关心的，并希望安全传递出去的数据。JWT 如何做到这一点，并使你信任它，就是加密签名。

被篡改之后

总结

参考官方文档：JSON Web Tokens