从认证谈一谈JWT

JWT全称JSON WEB TOKEN，基于token了不用想，八成都是和用户认证有关系。

传统认证方式是通过cookie基于session的，这个优缺点就不在列举了。我在我们项目里面使用JWT的最主要原因就是因为一个是跨域的问题，一个是分布式的问题。

先说大致的流程，用户在登录的时候，登录结果返回一个token值，以后的每次请求，都会在http的header中的Authorization中带上这个token值。后端在做统一拦截的时候会进行token校验；如果合法，正常返回；否则401。

这里面针对我自己的项目，最开始的想法是登录时候随机生成一个key返回给客户端，然后把key值存储在redis中，每次请求都去做校验。这个无疑是不好的，因为是基于redis的，万一redis挂了，或者以后再接入项目（还是要继续依赖这个redis），这个岂不是要gg…

token的格式为A.B.C，其中A和B都是base64格式的（即代表是公开的）。C是通过加密算法（A+B， secret）的方式生成的C。
所以从上一段介绍的来看，secret无疑是最重要的（因为ABC在传输的过程中谁都可以看到，但是secret是不能的）。

A字段代表HEADER（官方解释…）就是验证方式是jwt，加密算法是什么，格式具体如下：

let header = {
  "alg": "HS256",
  "typ": "JWT"
}

alg字段是加密算法，typ是jwt类型（其实这个可以写死的，不用每次校验都要做base64）

base64(header) = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"

所以A就是eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。

B字段是PayLoad（官方解释），就是数据实体，你可以存放一些不敏感的用户信息在这里（解释过是base64的所以相当于明文）格式具体如下：

let payLoad = {
  "sub": "123456789",
  "name": "John Doe",
  "iat": 1516239022
}

里面每个字段存储的是你需要的信息，如果要做过期校验的话，可以将时间戳放在这里

base64(payLoad) = "eyJzdWIiOiIxMjM0NTY3ODkiLCJuYW1lIjoiSm9obiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9";

所以B就是“eyJzdWIiOiIxMjM0NTY3ODkiLCJuYW1lIjoiSm9obiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9”

C字段是VERIFY SIGNATURE(官方解释叫)就是签名校验。如果没有这个的话我怎么区分你是不是伪造的token…
根据A中的alg加密算法以及存储在服务端的secret值得来。

let secret = "this is my secret"; // 一定不能把这个泄露出去，否则相当于你把门禁密码给公布于众了

所以C的值就是

// HS256(A.B, secret)
HS256('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkiLCJuYW1lIjoiSm9obiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9', secret) = 'RBBDj6xMnJrTOiaABp_PGnFRDeOcqeJvQse1mty3MR0'

所以C字段就是’RBBDj6xMnJrTOiaABp_PGnFRDeOcqeJvQse1mty3MR0’。
所以token就是‘eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkiLCJuYW1lIjoiSm9obiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.RBBDj6xMnJrTOiaABp_PGnFRDeOcqeJvQse1mty3MR0’

每次接到这个token如果不做时间校验的话，就把A.B和secret做运算看是否等于C（校验是否被篡改）。

以上就是大致的流程了。
个人疑问：
需要将token放到authorization头么？放到请求中的参数或者其他位置是否可行？
A字段存在的意义是什么…理论上是不是将用户的信息与secret做加密（可逆，服务端可解密）其实就可以？

半年没更博文…觉得自己堕落了….