JWT：JSON Web Token
2016-01-22
为什么需要授权算法
我们现在的应用程序一般都会保存用户的数据，如用户上传的图片，文件等。有时用户可能不希望他自己上传的这些资源其他人都能访问，也有可能我们的 系统希望这些资源至少是要登录后才能访问。这些应该都是很自然的需要，但是我们想现在的系统一般都是分布式的，举例来说，我们一般希望有单独的图片或者 文件服务器来处理这些资源，但是这又和我们的业务系统一般是分开的，以前我们对于这样保护资源的需要一般的做法是：
由于 http 是无状态协议，所以我们通过 cookie 来存储一个 sessionID，服务器通过这个 sessionID 来跟踪用户的状态。
但是现在我们的资源服务器和业务服务器是不同的服务器，我们又需要保护资源的访问，这时我们就希望我们不用通过 cookie 来跟踪用户的状态，这个时候 JWT 授权协议就是为了解决这个问题的：
从上图中我们可以看到 Auth server 和 API server 已经是不同的服务器了。
JWT 是授权算法的一些细节
JWT 是 IETF 的标准授权协议，我们来看一个 JWT 的列子，了解下这其中的细节
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
上面的列子中的形式如下：
header.claims.signature
其中 header claims 部分是用 base64 编码过的 json 对象，所以这个是 url 友好的。
Header
header 部分是一个简单的声明对象，这个声明包括 signature 使用的算法.
{
"alg" : "AES256",
"typ" : "JWT"
}
Claims
claims 部分是最重要的部分了对于业务的实现来说，这个部分包含了业务中的所有的信息，我们看看下面的示例：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
其中 JWT 中一些保留的字段，具体细节可以参考- rfc7519，rfc7518
Signature
Signature 的主要目的是保护 Header 和 Claims 部分不能被篡改，一般的做法就是使用 hash 算法生成一个签名。这个只要保证服务器端的私有 key 是一致的，且不被泄露，就能保证这个 Claims 部分的信息是可信的。
JWT 的适用范围和缺点
从上面的分析和 JWT 的细节，可以知道 JWT 非常适用于我们的分布式的无状态 API 服务器鉴权，我们再看看 JWT 的优点和一些限制
优点：
- 开发简单
- 不需要 cookie
- 使用了对移动端友好的 JSON 格式
- 不依赖于登陆服务器
- 概念简单容易理解
限制：
- Tokens 有大小限制
- Tokens 授权后不能撤销
