聊一聊JWT与session

前言

认证和受权，其实吧简单来讲就是:认证就是让服务器知道你是谁，受权就是服务器让你知道你什么能干，什么不能干，认证受权俩种方式：Session-Cookie与JWT，下面咱们就针对这两种方案就行阐述。

Session

工做原理

当 client经过用户名密码请求server并经过身份认证后，server就会生成身份认证相关的 session 数据，而且保存在内存或者内存数据库。并将对应的 sesssion_id返回给client，client会把保存session_id（能够加密签名下防止篡改）在cookie。此后client的全部请求都会附带该session_id（毕竟默认会把cookie传给server），以肯定server是否存在对应的session数据以及检验登陆状态以及拥有什么权限，若是经过校验就该干吗干吗，不然从新登陆。

前端退出的话就清cookie。后端强制前端从新认证的话就清或者修改session。

优点

相比JWT，最大的优点就在于能够主动清除session了

session保存在服务器端，相对较为安全

结合cookie使用，较为灵活，兼容性较好

弊端

cookie + session在跨域场景表现并很差

若是是分布式部署，须要作多机共享session机制，实现方法可将session存储到数据库中或者redis中

基于 cookie 的机制很容易被 CSRF

查询session信息可能会有数据库查询操做

session、cookie、sessionStorage、localstorage的区别

session: 主要存放在服务器端，相对安全

cookie: 可设置有效时间，默认是关闭浏览器后失效，主要存放在客户端，而且不是很安全，可存储大小约为4kb

sessionStorage: 仅在当前会话下有效，关闭页面或浏览器后被清除

localstorage: 除非被清除，不然永久保存

JWT

JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且独立的方式，能够将各方之间的信息做为JSON对象进行安全传输。该信息能够验证和信任，由于是通过数字签名的。

JWT基本上由.分隔的三部分组成，分别是头部，有效载荷和签名。 一个简单的JWT的例子，以下所示：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ.ec7IVPU-ePtbdkb85IRnK4t4nUVvF2bBf8fGhJmEwSs
复制代码

若是你细致得去看的话会发现其实这是一个分为 3 段的字符串，段与段之间用 点号 隔开，在 JWT 的概念中，每一段的名称分别为：

Header.Payload.Signature
复制代码

在字符串中每一段都是被 base64url 编码后的 JSON，其中 Payload 段可能被加密。

Header

JWT 的 Header 一般包含两个字段，分别是：typ(type) 和 alg(algorithm)。

• typ：token的类型，这里固定为 JWT

• alg：使用的 hash 算法，例如：HMAC SHA256 或者 RSA

一个简单的例子：

{
      "alg": "HS256",
      "typ": "JWT"
    }
复制代码

咱们对他进行编码后是：

>>> base64.b64encode(json.dumps({"alg":"HS256","typ":"JWT"}))
    'eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9'
复制代码

Payload

JWT 中的 Payload 其实就是真实存储咱们须要传递的信息的部分，例如正常咱们会存储些用户 ID、用户名之类的。此外，还包含一些例如发布人、过时日期等的元数据。

可是，这部分和 Header 部分不同的地方在于这个地方能够加密，而不是简单得直接进行 BASE64 编码。可是这里我为了解释方便就直接使用 BASE64 编码，须要注意的是，这里的 BASE64 编码稍微有点不同，切确得说应该是 Base64UrlEncoder，和 Base64 编码的区别在于会忽略最后的 padding（=号），而后 '-' 会被替换成'_'。

举个例子，例如咱们的 Payload 是：

{"user_id":"zhangsan"}
复制代码

那么直接 Base64 的话应该是：

>>> base64.urlsafe_b64encode('{"user_id":"zhangsan"}')
    'eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ=='
复制代码

而后去掉 = 号，最后应该是：

'eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ'
复制代码

Signature

Signature 部分其实就是对咱们前面的 Header 和 Payload 部分进行签名，保证 Token 在传输的过程当中没有被篡改或者损坏，签名的算法也很简单，可是，为了加密，因此除了 Header 和 Payload 以外，还多了一个密钥字段，完整算法为：

Signature = HMACSHA256(
        base64UrlEncode(header) + "." +
        base64UrlEncode(payload),
        secret)
复制代码

仍是之前面的例子为例，

base64UrlEncode(header)  =》 eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9
    base64UrlEncode(payload) =》 eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ
复制代码

secret 就设为："secret", 那最后出来的签名应该是：

>>> import hmac
    >>> import hashlib
    >>> import base64
    >>> dig = hmac.new('secret',     >>> msg="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ", 
               digestmod=
    >>> base64.b64encode(dig.digest())
    'ec7IVPU-ePtbdkb85IRnK4t4nUVvF2bBf8fGhJmEwSs='
复制代码

将上面三个部分组装起来就组成了咱们的 JWT token了，因此咱们的

{'user_id': 'zhangsan'}
复制代码

的 token 就是：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ.ec7IVPU-ePtbdkb85IRnK4t4nUVvF2bBf8fGhJmEwSs
复制代码

工做原理

1.首先，前端经过Web表单将本身的用户名和密码发送到后端的接口。这一过程通常是一个HTTP POST请求。建议的方式是经过SSL加密的传输（https协议），从而避免敏感信息被嗅探。

2.后端核对用户名和密码成功后，将用户的id等其余信息做为JWT Payload（负载），将其与头部分别进行Base64编码拼接后签名，造成一个JWT。造成的JWT就是一个形同lll.zzz.xxx的字符串。

3.后端将JWT字符串做为登陆成功的返回结果返回给前端。前端能够将返回的结果保存在localStorage或sessionStorage上，退出登陆时前端删除保存的JWT便可。

4.前端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)

5.后端检查是否存在，如存在验证JWT的有效性。例如，检查签名是否正确；检查Token是否过时；检查Token的接收方是不是本身（可选）。

6.验证经过后后端使用JWT中包含的用户信息进行其余逻辑操做，返回相应结果。

JWTs vs. Sessions

可扩展性

随着应用程序的扩大和用户数量的增长，你必将开始水平或垂直扩展。session数据经过文件或数据库存储在服务器的内存中。在水平扩展方案中，你必须开始复制服务器数据，你必须建立一个独立的中央session存储系统，以便全部应用程序服务器均可以访问。不然，因为session存储的缺陷，你将没法扩展应用程序。解决这个挑战的另外一种方法是使用 sticky session。你还能够将session存储在磁盘上，使你的应用程序在云环境中轻松扩展。这类解决方法在现代大型应用中并无真正发挥做用。创建和维护这种分布式系统涉及到深层次的技术知识，并随之产生更高的财务成本。在这种状况下，使用JWT是无缝的;因为基于token的身份验证是无状态的，因此不须要在session中存储用户信息。咱们的应用程序能够轻松扩展，由于咱们可使用token从不一样的服务器访问资源，而不用担忧用户是否真的登陆到某台服务器上。你也能够节省成本，由于你不须要专门的服务器来存储session。为何？由于没有session！

注意：若是你正在构建一个小型应用程序，这个程序彻底不须要在多台服务器上扩展，而且不须要RESTful API的，那么session机制是很棒的。 若是你使用专用服务器运行像Redis那样的工具来存储session，那么session也可能会为你完美地运做！

安全性

JWT签名旨在防止在客户端被篡改，但也能够对其进行加密，以确保token携带的claim 很是安全。JWT主要是直接存储在web存储（本地/session存储）或cookies中。 JavaScript能够访问同一个域上的Web存储。这意味着你的JWT可能容易受到XSS（跨站脚本）攻击。恶意JavaScript嵌入在页面上，以读取和破坏Web存储的内容。事实上，不少人主张，因为XSS攻击，一些很是敏感的数据不该该存放在Web存储中。一个很是典型的例子是确保你的JWT不将过于敏感/可信的数据进行编码，例如用户的社会安全号码。

最初，我提到JWT能够存储在cookie中。事实上，JWT在许多状况下被存储为cookie，而且cookies很容易受到CSRF（跨站请求伪造）攻击。预防CSRF攻击的许多方法之一是确保你的cookie只能由你的域访问。做为开发人员，无论是否使用JWT，确保必要的CSRF保护措施到位以免这些攻击。

如今，JWT和session ID也会暴露于未经防范的重放攻击。创建适合系统的重放防范技术，彻底取决于开发者。解决这个问题的一个方法是确保JWT具备短时间过时时间。虽然这种技术并不能彻底解决问题。然而，解决这个挑战的其余替代方案是将JWT发布到特定的IP地址并使用浏览器指纹。

注意：使用HTTPS / SSL确保你的Cookie和JWT在客户端和服务器传输期间默认加密。这有助于避免中间人攻击！

RESTful API服务

现代应用程序的常见模式是从RESTful API查询使用JSON数据。目前大多数应用程序都有RESTful API供其余开发人员或应用程序使用。由API提供的数据具备几个明显的优势，其中之一就是这些数据能够被多个应用程序使用。在这种状况下，传统的使用session和Cookie的方法在用户认证方面效果不佳，由于它们将状态引入到应用程序中。

RESTful API的原则之一是它应该是无状态的，这意味着当发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。保持API无状态，不产生附加影响，意味着维护和调试变得更加容易。

另外一个挑战是，由一个服务器提供API，而实际应用程序从另外一个服务器调用它的模式是很常见的。为了实现这一点，咱们须要启用跨域资源共享（CORS）。Cookie只能用于其发起的域，相对于应用程序，对不一样域的API来讲，帮助不大。在这种状况下使用JWT进行身份验证能够确保RESTful API是无状态的，你也不用担忧API或应用程序由谁提供服务。

性能

对此的批判性分析是很是必要的。当从客户端向服务器发出请求时，若是大量数据在JWT内进行编码，则每一个HTTP请求都会产生大量的开销。然而，在会话中，只有少许的开销，由于SESSION ID实际上很是小。看下面这个例子：

JWT有5个claim：

{

  "sub": "1234567890",

  "name": "Prosper Otemuyiwa",

  "admin": true,

  "role": "manager",

  "company": "Auth0"

}
复制代码

编码时，JWT的大小将是SESSION ID（标识符）的几倍，从而在每一个HTTP请求中，JWT比SESSION ID增长更多的开销。而对于session，每一个请求在服务器上须要查找和反序列化session。

JWT经过将数据保留在客户端的方式以空间换时间。你应用程序的数据模型是一个重要的影响因素，由于经过防止对服务器数据库不间断的调用和查询来减小延迟。须要注意的是不要在JWT中存储太多的claim，以免发生巨大的，过分膨胀的请求。

值得一提的是，token可能须要访问后端的数据库。特别是刷新token的状况。他们可能须要访问受权服务器上的数据库以进行黑名单处理。获取有关刷新token和什么时候使用它们的更多信息。另外，请查看本文，了解有关黑名单的更多信息(auth0.com/blog/blackl…)。

下游服务

现代web应用程序的另外一种常见模式是，它们一般依赖于下游服务。例如，在原始请求被解析以前，对主应用服务器的调用可能会向下游服务器发出请求。这里的问题是，cookie不能很方便地流到下游服务器，也不能告诉这些服务器关于用户的身份验证状态。因为每一个服务器都有本身的cookie方案，因此阻力很大，而且链接它们也是困难的。JSON Web Token再次垂手可得地作到了！

实效性

此外，无状态JWT的实效性相比session太差，只有等到过时才可销毁，而session则可手动销毁。

例若有个这种场景，若是JWT中存储有权限相关信息，好比当前角色为 admin，可是因为JWT全部者滥用自身权利，高级管理员将权利滥用者的角色降为 user。可是因为 JWT 没法实时刷新，必须要等到 JWT 过时，强制从新登陆时，高级管理员的设置才能生效。

或者是用户发现帐号被异地登陆，而后修改密码，此时token还未过时，异地的帐号同样能够进行操做包括修改密码。

但这种场景也不是没有办法解决，解决办法就是将JWT生成的token存入到redis或者数据库中，当用户登出或做出其余想要让token失效的举动，可经过删除token在数据库或者redis里面的对应关系来解决这个问题。

node中使用JWT

我这个项目中使用的是JWT，使用方法以下：

首先安装JWT库：

npm install jsonwebtoken
复制代码

而后建立签名数据，生成token：

let jwt = require('jsonwebtoken');

var token = jwt.sign({ name: '张三' }, 'shhhhh');
console.log(token);
复制代码

运行程序能够看到打印出来的内容相似这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoi5byg5LiJIiwiaWF0IjoxNDYyODgxNDM3fQ.uVWC2h0_r1F4FZ3qDLkGN5KoFYbyZrFpRJMONZrJJog
复制代码

以后，对token字符串，能够这样解码：

let decoded=jwt.decode(token);
console.log(decoded);
复制代码

将打印出：

{ name: '张三', iat: 1462881437 }
复制代码

其中iat是时间戳，即签名时的时间（注意：单位是秒）。

不过，通常咱们不会使用decode方法，由于它只是简单的对claims部分的作base64解码。

咱们须要的是验证claims的内容是否被篡改。

此时咱们须要使用verify方法：

let decoded = jwt.verify(token, 'shhhhh');
console.log(decoded);
复制代码

虽然打印出的内容和decode方法是同样的。可是是通过校验的。

咱们能够改变校验用的密钥，好比改成shzzzz，使之和加密时的密钥不一致。那么解码就会出现报错：

JsonWebTokenError: invalid signature
复制代码

咱们也能够偷偷修改token的claims或者header部分，会获得这样的报错：

JsonWebTokenError: invalid token
复制代码

最后，根据本身的需求，决定是否须要将生成的token存入数据库或者redis，但建议不要存储用户密码等敏感信息。