jwt token 太长_理解 JWT 鉴权的应用场景及使用建议

JWT 介绍

JSON Web Token(JWT)是一个开放式标准(RFC 7519)，它定义了一种紧凑(Compact)且自包含(Self-contained)的方式，用于在各方之间以JSON对象安全传输信息。

这些信息可以通过数字签名进行验证和信任。可以使用秘密(使用HMAC算法)或使用RSA的公钥/私钥对对JWT进行签名。

虽然JWT可以加密以提供各方之间的保密性，但我们将重点关注已签名的令牌。签名的令牌可以验证其中包含的索赔的完整性，而加密令牌隐藏来自其他方的索赔。

当令牌使用公钥/私钥对进行签名时，签名还证明只有持有私钥的方是签名方。

我们来进一步解释一些概念：

Compact(紧凑)：由于它们尺寸较小，JWT可以通过URL，POST参数或HTTP标头内发送。另外，尺寸越小意味着传输速度越快。
Self-contained(自包含):有效载荷(Playload)包含有关用户的所有必需信息，避免了多次查询数据库。

JWT适用场景

Authentication(鉴权)：
这是使用JWT最常见的情况。一旦用户登录，每个后续请求都将包含JWT，允许用户访问该令牌允许的路由，服务和资源。
单点登录是当今广泛使用JWT的一项功能，因为它的开销很小，并且能够轻松地跨不同域使用。
Information Exchange(信息交换)：JSON Web Tokens是在各方之间安全传输信息的好方式。因为JWT可以签名：例如使用公钥/私钥对，所以可以确定发件人是他们自称的人。
此外，由于使用标头和有效载荷计算签名，因此您还可以验证内容是否未被篡改。

JWT结构

在紧凑的形式中，JWT包含三个由点(.)分隔的部分，它们分别是：

Header
Payload
Signature

JWT结构通常如下所示：

xxxxx.yyyyy.zzzzz

下面我们分别来介绍这三个部分：

Header

Header通常由两部分组成：令牌的类型，即JWT。和常用的散列算法，如HMAC SHA256或RSA。

例如：

{
  "alg": "HS256",
  "typ": "JWT"
}

Header部分的JSON被Base64Url编码，形成JWT的第一部分。

Payload

这里放声明内容，可以说就是存放沟通讯息的地方，在定义上有3种声明(Claims)：

Registered claims(注册声明):这些是一组预先定义的声明，它们不是强制性的，但推荐使用，以提供一组有用的，可互操作的声明。其中一些是：iss(发行者)，exp(到期时间)，sub(主题)，aud(受众)等。
#Registered Claim Names#https://tools.ietf.org/html/rfc7519#section-4.1

Public claims(公开声明):这些可以由使用JWT的人员随意定义。但为避免冲突，应在IANA JSON Web令牌注册表中定义它们，或将其定义为包含防冲突命名空间的URI。
Private claims(私有声明):
这些是为了同意使用它们但是既没有登记，也没有公开声明的各方之间共享信息，而创建的定制声明。

Playload示例如下：

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Playload部分的JSON被Base64Url编码，形成JWT的第二部分。

Notice:

请注意，对于已签名的令牌，此信息尽管受到篡改保护，但任何人都可以阅读。除非加密，否则不要将秘密信息放在JWT的有效内容或标题元素中。这也是很多文章争论jwt安全性原因，不要用 JWT 取代 Server-side 的 Session状态机制。详情请阅读这篇文章：Stop Using Jwt For Sessions.

Signature

第三部分signature用来验证发送请求者身份，由前两部分加密形成。
要创建签名部分，您必须采用编码标头，编码有效载荷，秘钥，标头中指定的算法并签名。

例如，如果你想使用HMAC SHA256算法，签名将按照以下方式创建：

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

JWT实践

JWT输出的是三个由点分隔的Base64-URL字符串，可以在HTML和HTTP环境中轻松传递，而与基于XML的标准(如SAML)相比，它更加紧凑。

以下JWT示例，它具有先前的标头和有效负载编码，并且使用秘钥进行签名。

我们可以使用jwt.io调试器来解码，验证和生成JWT：

JWT工作原理

在身份验证中，当用户使用他们的凭证成功登录时，JSON Web Token将被返回并且必须保存在本地(通常在本地存储中，但也可以使用Cookie)，而不是在传统方法中创建会话服务器并返回一个cookie。

关于存储令牌(Token)的方式，必须考虑安全因素。
参考： #Where to Store Tokens#https://auth0.com/docs/tokens/concepts/token-storage

无论何时用户想要访问受保护的路由或资源，用户代理都应使用承载方案发送JWT，通常在请求头中的Authorization字段，使用Bearer schema：

Authorization: Bearer

这是一种无状态身份验证机制，因为用户状态永远不会保存在服务器内存中。服务器受保护的路由将在授权头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。由于JWT是独立的，所有必要的信息都在那里，减少了多次查询数据库的需求。这使得我们可以完全依赖无状态的数据API，甚至向下游服务提出请求。无论哪些域正在为API提供服务并不重要，因此不会出现跨域资源共享(CORS)的问题，因为它不使用Cookie。