APP接口设计-用户认证(JWT)

目录

1. 1. 前言
2. 2. Session
   1. 2.1. 工作原理
   2. 2.2. 优势
   3. 2.3. 弊端
   4. 2.4. session、cookie、sessionStorage、localstorage的区别
3. 3. JWT
   1. 3.1. Header
   2. 3.2. Payload
   3. 3.3. Signature
   4. 3.4. 工作原理
4. 4. JWTs vs. Sessions
   1. 4.1. 可扩展性
   2. 4.2. 安全性
   3. 4.3. RESTful API服务
   4. 4.4. 性能
   5. 4.5. 下游服务
   6. 4.6. 实效性
5. 5. node中使用JWT

前言

认证就是让服务器知道你是谁，授权就是服务器让你知道你什么能干，什么不能干，认证授权俩种方式：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和何时使用它们的更多信息。另外，请查看本文，了解有关黑名单的更多信息。

下游服务

现代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，但建议不要存储用户密码等敏感信息。

作者：chengkai
链接：https://juejin.im/post/5a437441f265da43294e54c3
来源：掘金

---

个人总结：JWT可以作为APP认证中的token来使用，后台从token中获取用户id、姓名等基本信息，省去了查询数据库的步骤。