初识JWT(java web token)

JWT(Json Web Token)是JSON风格轻量级的授权和身份认证规范,可实现无状态、分布式的Web应用授权。

个人理解
我认为它是分布式session的替代物,在没有jwt之前,我们可以用redis等缓存服务器来充当session存储服务器,用户根据cookic中的token到redis服务器取用户信息,这也是单点登录的一种设计方案。而JWT的出现,使成本更低,我们可以单独部署一台授权服务器,甚至把授权服务器和应用部署在同一台服务器,来验证用户信息并返回一个jwt,该jwt存储在用户端(可存储在cookic中)。当用户需要访问一个路径、资源时,在http请求的头部中添加Authorization:bearer ,token在登录认证后由服务器生成并返回,就可以访问该资源,这也使得跨域访问(到其他的服务器中获取资源)更方便,因为授权信息已经存在于http请求中了,而且该授权信息的数据量不大,也避免不同服务器不同cookic实现带来的阻碍。不同语言和平台,只要服务器端实现了jwt授权认证,用户的token就可以随时验证权限而后获取资源,同时也避免了为了验证用户信息而多次查询数据库。

JWT授权时序图

初识JWT(java web token)_第1张图片


一个JWT由3个json部分组成,通过base64Url编码后用.符号来分隔,最终的JWT形式:xxxxx.yyyyy.zzzzz
header(头部)
{
  "alg":"HS256",  // 加密算法
  "typ":"JWT"  // 类型
}

payload(类似Http的body),可以包含多个claim(claim的key通常是由3个字符组成的,值通常是用户信息和另外的元数据)
claim分为3种:
预备的:JWT预先实现的,比如(iss (issuer), exp (expiration time), sub (subject), aud (audience))等;
公有的:定义包含namespace的uri,或者定义一些已经在IANA注册的claim;
私有的:定义多个应用约定好要共享的数据。
payload的例子
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

signature(签名,服务器认准此签名进行授权)
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)
上面就是一个签名,HMACSHA256是我们在header中指定的加密算法,对base64UrlEncode(header)、
base64UrlEncode(payload)和secret进行加密。用来验证请求发送者的身份和确保JWT中途没有被窜改。

一个完整的JWT 

初识JWT(java web token)_第2张图片

与session的主要区别
JWT把用户信息加密后存放在http的header中,可以不使用cookic,更加通用,跟restful配置更顺手,可以跨平台跨语言,比较适合分布式应用。但是对于规模较小的应用,比如单服务器应用,还是用session比较好,不用特意在服务器中实现JWT授权。

JWT的缺点
1.token的有效性太过依赖生成token时设置的过期时间,用户一旦拿到token就可以随时访问服务器,服务器对token不可控,只能等它失效;
2.只能与https配置使用,否则token会被窃取,他人就可以伪装成该token的持有者去各个服务器获取数据;
3.各个服务器都得实现JWT,才可以相互请求资源。

这个链接是JWT的官网,里面有JWT的介绍和各种语言对应的JWT library,对应的api在auth0这里。


你可能感兴趣的:(综合)