JWT的token与session的区别

背景知识

Authentication：用户认证，指的是验证用户的身份，例如你希望以小A的身份登录，那么应用程序需要通过用户名和密码确认你真的是小A。

Authorization：授权，指的是确认你的身份之后提供给你权限，例如用户小A可以修改数据，而用户小B只能阅读数据。

由于http协议是无状态的，每一次请求都无状态。当一个用户通过用户名和密码登录了之后，他的下一个请求不会携带任何状态，应用程序无法知道他的身份，那就必须重新认证。因此我们希望用户登录成功之后的每一次http请求，都能够保存他的登录状态。

目前主流的用户认证方法有基于token和基于session两种方式。

什么是JWT

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

起源

说起JWT，我们应该来谈一谈基于token的认证和传统的session认证的区别。

传统的session认证

我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息（session），这份登录信息（sessionID，sessionID用来识别session）会在响应时传递给浏览器，浏览器将sessionID保存在cookie中,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来.

session认证流程

1. 用户输入其登录信息

2. 服务器验证信息是否正确，并创建一个session，然后将用户信息（如用户名ID等）放在session中并保存在服务器端的内存中

3. 服务器为用户生成一个sessionId，将具有sesssionId的Cookie将放置在用户浏览器中（浏览器中cookie存放的是sessionID）

4. 在后续请求中，浏览器携带sessionID发送请求，服务器端会验证sessionID并从session中获取当前登录用户信息

5. 一旦用户注销应用程序，会话将在客户端和服务器端都被销毁

session代码示例

• 服务端向session中存储信息的过程，后续响应会返回sessionID存放在浏览器cookie中。session存在服务器内存中
  
• 服务端在session中获取用户信息的过程，请求时携带了sessionID（解析sessionID的过程不在代码中）。session存在服务器内存中
  

基于session认证所显露的问题

Session: 每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。

扩展性: 用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

CSRF: 因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。

基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

流程上是这样的：

1. 用户输入其登录信息

2. 服务器验证信息是否正确，并返回已签名的token

3. token储在客户端，例如存在local storage或cookie中

4. 之后的HTTP请求都将token添加到请求头里

5. 服务器解码JWT，并且如果令牌有效，则接受请求

6. 一旦用户注销，令牌将在客户端被销毁，不需要与服务器进行交互一个关键是，令牌是无状态的。后端服务器不需要保存令牌或当前session的记录。
   

这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。

基于token机制的代码示例

前后端分离项目

• 第一次登录时，验证后， 通过用户id和密码签证生成token，并在响应中返回token
  
• 前端存储token，存储在浏览器的localstorage中

• 前端请求其他后端接口时携带token，在请求头中携带

• 后端通过请求头token，不但可以获取用户信息，还可以进行用户认证，下面是拦截器进行用户认证
  
• 通过token获取当前登录用户信息，获取token后去数据库中查询，而不是向session那样直接在服务器内存中拿，不需要去考虑用户在哪一台服务器登录了
  
  

那么我们现在回到JWT的主题上。

JWT的详细解释见文章 JWT