Json Web Token(JWT)详解

 

什么是Json Web Token

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登陆（SSO）场景。JWT的声明通常被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也能够增长一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

为何要用Json Web Token

       咱们知道HTTP通讯是无状态的，所以客户端的请求到了服务端处理完以后是没法返回给原来的客户端。所以须要对访问的客户端进行识别，经常使用的作法是经过session机制：客户端在服务端登录成功以后，服务端会生成一个sessionID，返回给客户端，客户端将sessionID保存到cookie中，再次发起请求的时候，携带cookie中的sessionID到服务端，服务端会缓存该session（会话），当客户端请求到来的时候，服务端就知道是哪一个用户的请求，并将处理的结果返回给客户端，完成通讯。流程图以下。

 

1.服务器开销过大：每次认证用户发起请求时，服务器须要去建立一个Seesion记录来存储信息。当愈来愈多的用户发请求时，内存的开销也会不断增长。

2.可扩展性：在服务端的内存中使用Seesion存储登陆信息，伴随而来的是可扩展性问题。

3.CORS(跨域资源共享)：当咱们须要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另外一个域的资源，就能够会出现禁止请求的状况。

4.CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，而且可以被利用其访问其余的网站。

五、当服务器应用重启时，用户会被强制登出

六、当站点用负载均衡部署多份时，每一个站点实例的session没法共享。固然，咱们可使用单独的session存储服务来解决这些问题，但这样会增长系统不小的复杂性与维护成本。 

在这些问题中，可扩展性是最突出的。所以咱们有必要去寻求一种更有行之有效的方法。

Json Web Token是怎么作的

使用基于 Token 的身份验证方法，在服务端不须要存储用户的登陆记录。大概的流程是这样的： 

      一、客户端经过用户名和密码登陆服务器；
      二、服务端对客户端身份进行验证；
      三、服务端对该用户生成Token，返回给客户端；
      四、客户端将Token保存到本地浏览器，通常保存到cookie中；
      五、客户端发起请求，须要携带该Token；
      六、服务端收到请求后，首先验证Token，以后返回数据。

 

使用token认证有如下优势：

1.无状态、可扩展 ：在客户端存储的Token是无状态的，而且可以被扩展。基于这种无状态和不存储Session信息，负载均衡器可以将用户信息从一个服务传到其余服务器上。

2.安全性 

请求中发送token而再也不是发送cookie可以防止CSRF(跨站请求伪造)。即便在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让咱们少了对session操做。token是有时效的，一段时间以后用户须要从新验证。咱们也不必定须要等到token自动失效，token有撤回的操做，经过token revocataion可使一个特定的token或是一组有相同认证的token无效。

3.提供接口给第三方服务

使用tokens时，能够提供可选的权限给第三方应用程序。当用户想让另外一个应用程序访问它们的数据，咱们能够经过创建本身的API，得出特殊权限的tokens。

4.多平台跨域 

对应用程序和服务进行扩展的时候，须要介入各类各类的设备和应用程序。 

假如咱们的后端api服务器a.com只提供数据，而静态资源则存放在cdn 服务器b.com上。当咱们从a.com请求b.com下面的资源时，因为触发浏览器的同源策略限制而被阻止。

咱们经过CORS（跨域资源共享）标准和token来解决资源共享和安全问题。

举个例子，咱们能够设置b.com的响应首部字段为：

Access-Control-Allow-Origin: http://a.com

Access-Control-Allow-Headers: Authorization, X-Requested-With, Content-Type, Accept

Access-Control-Allow-Methods: GET, POST, PUT,DELETE

第一行指定了容许访问该资源的外域 URI

第二行指明了实际请求中容许携带的首部字段，这里加入了Authorization，用来存放token

第三行用于预检请求的响应。其指明了实际请求所容许使用的 HTTP 方法。

而后用户从a.com携带有一个经过了验证的token访问B域名，数据和资源就可以在任何域上被请求到。 

 

Json Web Token长什么样子呢？

一个JWT实际就是一个字符串，它包含三部分，分别是： 头部（header ），载荷（payload ），签名 （signature）。

他们按照 A.B.C 的格式拼接起来，其中C由A和B生成，他们之间的格式为 Base64(header).Base64(payload).H256(A.B)。须要注意的是header和payload都是使用Base64URL 算法对象序列化以后的字符串. 

一个JWT大概长这样：

 

 头部(header)

Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常不多改动直接使用默认的便可            

{

    'typ': 'JWT',

    'alg': 'HS256'

}

 

alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。

  载荷(playload)

Payload 部分也是一个 JSON 对象，用来存放实际须要传递的数据。

可自行指定字段很灵活，也有固定字段表示特定含义（但不必定要包含特定字段，只是推荐）。下面是官方推荐的字段：

            {
                    'iss':'签发者',
                    'sub':'面向的用户',
                    'aud':'接收方',
                    'exp':  过时时间,
                    'iat':  建立时间,
                    'nbf':  在什么时间以前，该Token不可用,
                    'jti':'Token惟一标识'
             }

下面就是一个例子：

{

"sub": "1234567890",

"name": "John Doe",

"admin": true

}

 

签名(signature)

Signature 部分是对前两部分的签名，防止数据篡改。

首先，须要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。而后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

 

算出签名之后，如今把header和payload用Base64URL 算法对象序列化，而后把这三部分用“.”拼接起来就是生成的token了。

 

怎样使用token？

能够放到HTTP请求的请求头中，一般是Authorization字段。
也有人说放到cookie。不过移动端app用cookie彷佛不方便。

 

-END-

 

若是你以为本文对你有用，请转发支持一下

长按并识别下方二维码，点击关注，便可获取最新走心文章

记得把我设为星标或置顶哦

 

在公众号后台回复“前端资源”便可获取最新前端开发资源