JWT--- json web token 服务端身份验证使用心得
一、为什么使用jwt
JSON Web Token（JWT）是目前最流行的跨域身份验证解决方案,
- 传统身份验证手段session：
通过在客户端cookie中存储session id ，
发起请求时携带cookie，
服务器根据cookie存储的session id 到临时文件夹中查找对应的session
读取session信息并对比数据，达到确认身份的目的
这种方式的问题是没有分布式架构，扩展不易，如果只使用一台服务器，该模式没有问题，如果使用多台服务器集群，则需要一个统一的session数据库来保存信息，这样负载均衡下，各个服务器才能实现数据共享，达到统一验证的效果；另一个问题是会产生较大的I/O 开销，加大服务器压力
二、jwt介绍
使用过程
用户登录后，服务端生成一个唯一字符串并返回，成为token （令牌）
用户后续操作携带都token,服务端获取token并进行身份验证，token不正确或者过期均拦截后续操作
结构介绍
分为三个部分，header,payload,sign 分别成为头部，有效载荷，签名
header:
{
"typ":"JWT",
"alg":"HS256"
}
一般包括两部分，typ名称，alg表示签名使用的算法，
- payload:
{
"iss":"发行人",
"exp":"到期时间",
"sub":"主题",
"aud":"用户",
"nbf":"在此之前不可用",
"iat":"发布时间",
"jti":"jwt id 用于标识该jwt",
"username":"admin",
"timestamp" :"时间戳"
}
有效载荷包含默认字段和自定义字段
- sign签名哈希:
$header_str = base64_encode($header);
$payload_str = base64_encode($payload);
$secret = "自定义密钥";
$sign = hash_hmac("HS256",$header_str.$payload_str,$secret)
签名哈希由头和有效荷载连接后,添加自定义的密钥后按照指定的加密方式生成l
- 最终token：
header 、 payload、sign 由 . 连接为一个字符串后 组成token
使用方法
客户端接收服务器返回的JWT，将其存储在Cookie或localStorage中。
此后，客户端将在与服务器交互中都会带JWT。如果将它存储在Cookie中，就可以自动发送，但是不会跨域，因此一般是将它放入HTTP请求的Header Authorization字段中。
Authorization: Bearer
当跨域时，也可以将JWT被放置于POST请求的数据主体中；
问题和趋势
JWT默认不加密，但可以加密。生成原始令牌后，可以使用改令牌再次对其进行加密。
当JWT未加密方法是，一些私密数据无法通过JWT传输。
JWT不仅可用于认证，还可用于信息交换。善用JWT有助于减少服务器请求数据库的次数。
JWT的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦JWT签发，在有效期内将会一直有效。
JWT本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。
为了减少盗用和窃取，JWT不建议使用HTTP协议来传输代码，而是使用加密的HTTPS协议进行传输。
