基于前后端分离的身份认证方式——JWT
目录：
一、什么是JWT
二、我们为什么要使用JWT（与传统的session认证有何区别）
三、如何使用JWT
四、JWT的构成及原理
五、JWT加解密实例
一、什么是JWT
JWT——Json web token
是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准，可实现无状态、分布式的Web应用授权。
二、我们为什么需要JWT？
首先，当前后端分离时我们会因为同源策略而无法设置cookie和sessionid。当然了我们有很多方式去解决这个问题，比如反向代理和jsonp等。但这仍然不如直接使用jwt来的简便。其次就是要说到jwt与传统的身份认证相比有什么优势了。
回答这个问题需要来看看基于token的认证和传统的session认证的区别
1、传统的session认证
我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。
但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来.
2、基于token的鉴权机制
基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。
流程上是这样的：
1、用户使用用户名密码来请求服务器 2、
2、服务器进行验证用户的信息 服务器通过验证发送给用户一个token
3、 客户端存储token，并在每次请求时附送上这个token值 服务端验证token值，并返回数据
4、这个token必须要在每次请求时传递给服务端，它应该保存在请求头里，
另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin:*。
也就是说相比于传统基于cookie的session，基于token的jwt有以下优点：
Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
无状态(也称：服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
更适用CDN: 可以通过内容分发网络请求你服务端的所有资料（如：javascript，HTML,图片等），而你的服务端只要提供API即可.
去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
更适用于移动应用: 当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。
CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理.
基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.
三、如何使用jwt
安装方式：
//--save是否需要取决于你是否需要把安装版本写进package.json
npm install （--save）jwt-simple
- 1
- 2
- 3
使用方式
var jwt = require('jwt-simple');
var payload = { foo: 'bar' };
var secret = 'xxx';
// HS256 secrets are typically 128-bit random strings, for example hex-encoded:
// var secret = Buffer.from('fe1a1915a379f3be5394b64d14794932', 'hex)
// encode
var token = jwt.encode(payload, secret);
// decode
var decoded = jwt.decode(token, secret);
console.log(decoded); //=> { foo: 'bar' } - 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
注意secret是用于解密的密文，是必须保存在服务器端。
四、JWT的原理及构成
JWT的构成：
jwt由三部分构成：头部（header)、载荷（payload, )、签证（signature).
头部：jwt的头部承载两部分信息：
声明类型，这里是jwt
声明加密的算法 通常直接使用 HMAC SHA256
完整的头部就像下面这样的JSON：
{
'typ': 'JWT',
'alg': 'HS256'
}- 1
- 2
- 3
- 4
然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
playload- 1
- 2
载荷：就是存放有效信息的地方。，这些有效信息包含三个部分
标准中注册的声明
公共的声明
私有的声明
标准中注册的声明 (建议但不强制使用) ：
iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。- 1
- 2
- 3
- 4
- 5
- 6
- 7
公共的声明 ：
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.
私有的声明 ：
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
定义一个payload:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}- 1
- 2
- 3
- 4
- 5
然后将其进行base64加密，得到Jwt的第二部分。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
signature- 1
- 2
签证：这个签证信息由三部分header (base64后的)
payload (base64后的)
secret分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。
// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);
var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ- 1
- 2
- 3
- 4
将这三部分用.连接成一个完整的字符串,构成了最终的jwt:
五、jwt运用实例
/**
* 身份验证.
*/
const jwt = require('jwt-simple');
const moment = require('moment');
//加密过程
var getJwt = function(userId，secret)
{
var expires = moment().add( 7,'days').valueOf();
var token = jwt.encode({
iss: userId,
exp: expires
}, secret);
return token;
}
//解密过程
var testJwt = function(token，secret){
//返回{foo: 'bar'}
var decoded = jwt.decode(token,secret)
return decoded;
}
module.exports = {
create: getJwt,
test: testJwt
}