Introduction to JSON Web Tokens

好久没有码字了，今天来补个坑。本篇文章记录一下JSON Web Tokens的概念以及如何使用。大部分内容直接翻译自官方文档。

1、JSON Web Token是什么

JSON Web Token (简称JWT)不是一项技术，而是为了让JSON对象在各方之间安全地传输而制定的一项标准（RFC 7519)。这些信息能够被验证和信任，因为他们是基于签名算法的，可以通过秘钥验证JWT的合法性以及数据是否被篡改。

常见的签名算法有HS256和RS256两种，前一种称为对称算法，他使用同一个秘钥（secret）对签名进行签发和验证。后一种称为非对称算法，他提供一组公钥和私钥，采用公钥进行签发，采用私钥进行验证。(如果不能理解这个也没啥事，看到后面自然就知道了。)

2、JSON Web Token 的组成

JWT的组成包括下面三个部分，每个部分之间用'.'隔开：

• Header
• Payload
• Signature

就是类似于"xxxxx.yyyyy.zzzzz"这个样子的字符串

2.1、Header

Header通常由两个部分组成，token的类型以及使用的签名算法(例如HS256、RS256)

举个栗子:

{

"alg": "HS256",

"typ": "JWT"

}

将头部用Base64Url加密，构成了第一部分。

2.2、Payload

PayLoad是存放有效信息的部分。它包括三个部分：

• Registered claims
• Public claims
• Private claims

Registered claims: 包括iss (签发者), exp (过期时间), sub (主体), aud (接收者)等等，这是一组预定义的声明，推荐但是不强制使用。

Public claims:由使用JWTs的用户随意定义。但是为了避免冲突，应该在IANA JSON Web令牌注册表中定义它们。

Private claims：由使用JWTs的用户随意定义。

举个栗子

{

"sub": "1234567890",

"name": "John Doe",

"admin": true

}

将PayLoad用Base64Url加密，构成第二部分

注意：由于Base64Url是可解密的，JWT仅保证他们不会被篡改，所以不应该在这些地方存储敏感信息。这个很重要！！

2.3、Signature

JWT的可靠性是由这个部分支持的，称为签名部分。我们一开始介绍的签名算法也是运用在这部分的。这部分由上述经过Base64Url加密后的Header和PayLoad以及一个秘钥加密而成。如果说你使用HS256对称算法，如下

HMACSHA256(  base64UrlEncode(header) + "." +  base64UrlEncode(payload),  secret)

3、小结

经过上述的步骤最终生成的JWT形如下方字符串的样子。

• JWT的签名部分保证了前两部分是不会被篡改，一旦被恶意修改了，这个签名在校验时都会失败
• JWT仅保证其内容不会被篡改，对于任意程序来说，前两个包含信息的部分都是可读的，不应该将敏感数据存放在其中。

适用场景

作为传统登录替换方案

JWT也是替换cookie-session的一种解决方案。相比于cookie-session的方案，他具有如下优点

1、服务器不需要去维护session，节省内存开销

2、支持移动端(安卓，ios)

3、支持跨域

3.客户端带着JWT访问服务A(通常是放在请求头中)，服务A校验JWT（是否是合法的以及是否被篡改）。校验通过则响应请求。