token验证_基于Token的身份验证

一 基于Token的身份验证JWT

初次了解JWT，很基础，高手勿喷。基于Token的身份验证用来替代传统的cookie+session身份验证方法中的session。JWT就是一个字符串，经过加密处理与校验处理的字符串，形式为："A.B.C"，

A由JWT头部信息header加密得到

B由JWT用到的身份验证信息json数据加密得到

C由A和B加密得到，是校验部分

二 怎样生成A

例如Header格式为：

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

它就是一个json串，两个字段是必须的，不能多也不能少。alg字段指定了生成C的算法，默认值是HS256，将header用base64加密，得到A，通常，JWT库中，可以把A部分固定写死，用户最多指定一个alg的取值

三 怎样生成B

根据JWT claim set[用base64]加密得到的。claim set是一个json数据，是表明用户身份的数据，可自行指定字段很灵活，也有固定字段表示特定含义（但不一定要包含特定字段，只是推荐）。

这里偷懒，直接用php中的代码来表示claim set了，重在说明字段含义:

$token = array( 
  "iss" => "http://example.org", #非必须。issuer 请求实体，可以是发起请求的用户的信息，也可是jwt的签发者。 
  "iat" => 1356999524, #非必须。issued at。 token创建时间，unix时间戳格式 
  "exp" => "1548333419", #非必须。expire 指定token的生命周期，unix时间戳格式 
  "aud" => "http://example.com", #非必须，接收该JWT的一方
  "sub" => "jrocket@example.com", #非必须。该JWT所面向的用户 
  "nbf" => 1357000000, # 非必须，not before。如果当前时间在nbf里的时间之前，则Token不被接受；一般都会留一些余地，比如几分钟
  "jti" => '222we', # 非必须。JWT ID。针对当前token的唯一标识 
  "GivenName" => "Jonny", # 自定义字段 
  "Surname" => "Rocket", # 自定义字段 
  "Email" => "jrocket@example.com", # 自定义字段 
  "Role" => ["Manager", "Project Administrator"] # 自定义字段 
);

JWT遵循RFC7519，里面提到claim set的json数据中，自定义字段的key是一个string，value是一个json数据。因此随意编写吧，很灵活。

个人初学，认为一个最基本最简单最常用的claim set为：

$token=array(     
  "user_id" => 123456, #用户id，表明用户 
  "iat" => 1356999524, #token发布时间 
  "exp" => 1556999524, #token过期时间 
);

将claim set加密后得到B，学名payload

四 怎样计算C

将A.B使用HS256加密（其实是用header中指定的算法），当然加密过程中还需要密钥（自行指定的一个字符串）。

加密得到C，学名signature，其实就是一个字符串。作用类似于CRC校验，保证加密没有问题。

好了，现在A.B.C就是生成的token了。

五 怎样使用Token

可以放到HTTP请求的请求头中，通常是Authorization字段。

也有人说放到cookie。不过移动端app用cookie似乎不方便。

六 Token应用流程

① 初次登录：用户初次登录，输入用户名密码

② 密码验证：服务器从数据库取出用户名和密码进行验证

③ 生成JWT：服务器端验证通过，根据从数据库返回的信息，以及预设规则，生成JWT

④ 返还JWT：服务器的HTTP RESPONSE中将JWT返还

⑤ 带JWT的请求：以后客户端发起请求，HTTP REQUEST HEADER中的Authorizatio字段都要有值，为JWT

七 Token的优点

① 相比于session，它无需保存在服务器，不占用服务器内存开销。

② 无状态、可拓展性强：比如有3台机器（A、B、C）组成服务器集群，若session存在机器A上，session只能保存在其中一台服务器，此时你便不能访问机器B、C，因为B、C上没有存放该Session，而使用token就能够验证用户请求合法性，并且我再加几台机器也没事，所以可拓展性好就是这个意思。

③ 由（2）知，这样做可就支持了跨域访问。

八 Token在服务与客户端的交互流程

① 客户端通过用户名和密码登录

② 服务器验证用户名和密码，若通过，生成token返回给客户端。

③ 客户端收到token后以后每次请求的时候都带上这个token，相当于一个令牌，表示我有权限访问了

④ 服务器接收（通常在拦截器中实现）到该token，然后验证该token的合法性（为什么能验证下面说）。若该token合法，则通过请求，若token不合法或者过期，返回请求失败。

九 关于Token的思考

服务如何判断这个token是否合法？

由上面token的生成可知，token中的签名是由Header和有效载荷通过Base64编码生成再通过加密算法HS256和密钥最终生成签名，这个签名位于JWT的尾部，在服务器端同样对返回过来的JWT的前部分再进行一次签名生成，然后比较这次生成的签名与请求的JWT中的签名是否一致，若一致说明token合法。由于生成签名的密钥是服务器才知道的，所以别人难以伪造。

token中能放敏感信息吗？

不能，因为有效载荷是经过Base64编码生成的，并不是加密。所以不能存放敏感信息。