Server 端的认证——拥抱 JWT（一）

What is Json Web Token

根据官网的定义，JWT 是一套开放的标准（RFC 7519），它定义了一套简洁的（compact）、自包含的（self-contained）方案，来让我们安全地在客户端和服务器之间传递 JSON 格式的信息。

Advantages

  • 体积小，因而传输速度快
  • 传输方式多样，可以通过 URL/POST 参数/HTTP 头部 等方式传输
  • 严谨的结构化。它自身（在 payload 中）就包含了所有与用户相关的验证消息，如用户可访问路由、访问有效期等信息，服务器无需再去连接数据库验证信息的有效性，并且 payload 支持为你的应用而定制化
  • 支持跨域验证，多应用于单点登录。

单点登录（Single Sign On）：在多个应用系统中，用户只需登陆一次，就可以访问所有相互信任的应用。

WHY JWT

除了上面说到的优点之外，相比传统的服务端验证， JWT 还有以下优点。

  • 充分依赖无状态 API ，契合 RESTful 设计原则
  • 易于实现 CDN，将静态资源分布式管理
  • 验证解耦，无需使用特定的身份验证方案， token 可以在任何地方生成
  • 比 cookie 更支持原生移动端应用
  1. 关于状态
    首先我们先看一下，什么是状态，什么是有状态与无状态。

状态：请求的状态是 client 与 server 交互过程中，保存下来的相关信息，客户端的保存在 page/request/session/application 或者全局作用域中，而 server 的一般存在 session 中。

有状态 API：server 保存了 client 的请求状态， server 会通过 client 传递的 sessionID 在其 session 作用域内找到之前交互的信息并应答。

无状态 API：无状态是 RESTful 架构设计的一个非常主要的原则。无状态 API 的每一个请求都是独立的，它要求由客户端保存所有需要的认证信息，每次发请求都要带上自己的状态，以 url 的形式提交包含了 cookies 等状态的数据。

JWT 就很好地体现了无状态原则。用户登陆之后，服务器会返回给他一个 token，由他保存在本地，在这之后的对服务器的访问都要带上这串 JWT ,来获得访问服务器相关路由、服务及资源的权限。比如单点登录就比较多地使用了 JWT，因为它的体积小，并且简单处理（使用 HTTP 头带上 Bearer 属性 + token ）就可以支持跨域操作。

  1. 分布式管理
    在传统的 session 验证中，服务端必须保存 session ID，用于与用户传过来的 cookie 验证。而在一开始保存 session ID 时， 只会保存在一台服务器上，所以只能由一个 server 应答，就算其他服务器有空闲也无法应答，因此也利用不到分布式服务器的优点。
    而 JWT 依赖的是在客户端本地保存验证信息，不需要利用服务器保存的信息来验证，所以任意一台服务器都可以应答，服务器的资源也被较好地利用。

  2. 验证解耦
    只要拥有生成 token 所需的验证信息，在何处都可以调用 token 生成接口，无需繁琐的耦合的验证操作，可谓是一次生成，永久使用。

  3. 对原生应用的支持（我对移动端开发不够深入，这点不是很清楚）
    原生的移动应用对 cookie 与 session 的支持不够好，而对 token 的方式支持较好。

除此之外，JWT 的可靠的结构化的标准，也是我们选择它的一大原因。特别是使用 nodejs 开发时，嗯，node 大法好！

client 使用 JWT 与 server 交互的过程

image

首先，拥有某网站账号的某 client 使用自己的账号密码发送 post 请求 login，由于这是首次接触，server 会校验账号与密码是否合法，如果一致，则根据密钥生成一个 token 并返回，client 收到这个 token 并保存在本地的 localStorage。在这之后，需要访问一个受保护的路由或资源时，而只要附加上你保存在本地的 token（通常使用 Bearer 属性放在 Header 的 Authorization 属性中），server 会检查这个 token 是否仍有效，以及其中的校验信息是否正确，再做出相应的响应。

JWT 由三部分组成：Header/Payload/Signature

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Header
{
  "alg": "HS256",
  "type": "JWT"
}
// Payload
{
  // reserved claims
  "iss": "a.com",
  "exp": "1d",
  // public claims
  "http://a.com": true,
  // private claims
  "company": "A",
  "awesome": true
}
// $Signature
HS256(Base64(Header) + "." + Base64(Payload), secretKey)
JWT = {Base64(Header), Base64(Payload), $Signature}

第一部分是 Header。首先声明一个 JSON 对象，对象里有一个 type 属性，值为 JWT ，以及 alg 属性，值为 HS256，表明最终使用的加密算法是 HS256。

第二部分是 Payload Claim。这一部分被定义为实体的状态，就像 token 自身附加元数据一样，claim 包含我们想要传输的信息，以及用于服务器验证的信息，一般有 reserved/public/private 三类。

第三部分是 Signature。它由前面在 Header 指定的算法 HS256 加密两个参数构成，第一个参数是经过编码的 Header 与经过编码的 Payload 通过 . 连接之后的字符串，第二个参数是生成的密钥，会由服务器保存。每次服务器接收到 token 之后，也是先解密出用于验证的用户信息以及密钥，再与自己保存的密钥对比是否相同，以此来验证用户的身份。

写完这么一大篇真是好累…还想继续深挖一下 JWT 具体的应用、服务端如何验证、JWT 使用 cookie 存储好还是 HTML5 Web Storage 好的，剩下的只能留在下回分解啦。。

感谢以下参考文章：
Json Web Token Introduction
使用Json Web Token设计Passport系统
深入RESTful无状态原则

我说我萌萌哒<br>你信吗？