jwt 私钥_JWT 开发设计详解

什么是 JWT

JWT 全称是 JSON Web Token(JWT) 是一个 开放标准(RFC 7519) ，它定义了一种紧凑且自包含的方式，用于在各方之间作为 JSON 对象安全地传输信息。由于此信息是经过数字签名的，因此可以被验证和信任。

可以使用密钥( HMAC算法 )或使用 RSA 或 ECDSA 的公用/专用密钥对对 JWT 进行签名。

什么时候使用 JWT 验证

• 授权 (Authorization)
  这是使用 JWT 的最常见情况。一旦用户登录，每个后续请求将包括 JWT ，从而允许用户访问该令牌允许的路由，服务和资源。单一登录是当今广泛使用 JWT 的一项功能，因为它的开销很小并且可以在不同的域中轻松使用。
• 信息交换 (Information Exchange)
  JWT 是在各方之间安全地传输信息的好方法。因为可以对 JWT 进行签名(例如，使用公钥/私钥对)，所以您可以确保发件人是他们所说的人。另外，由于签名是使用 Header 和 payload 计算的，因此您还可以验证内容是否未被篡改。

JWT 的结构格式

由三部分组成，这些部分由点 . 分隔，分别是：

HeaderPayloadSignature

因此， JWT 通常如下所示。

xxxxx.yyyyy.zzzzz

Header

通常由两部分组成：

• 令牌的类型(即 JWT )
• 所使用的签名算法，例如： HMAC SHA256 或 RSA 。

例如：

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

然后，将此 JSON 通过 Base64Url 编码以形成 JWT 的第一部分。

Payload

令牌的第二部分是 有效负载 ，其中包含声明。声明是有关实体(通常是用户)和其他数据的声明。共有三种类型的索赔： registered、public、private claims

• Registered claims
  这些是一组预定义的权利要求，不是强制性的，而是建议使用的，以提供一组有用的可互操作的权利要求。其中一些是： iss (发出者)， exp (到期时间)， sub (主题)， aud (受众) 等。Tip: 请注意，声明名称仅是三个字符，因为 JWT 是紧凑的。
• Public claims
  这些可以由使用 JWT 的人员随意定义。但是为避免冲突，应在 IANA JSON Web 令牌注册表中定义它们，或将其定义为包含抗冲突名称空间的 URI 。
• Private claims
  这些是自定义声明，旨在在同意使用它们的各方之间共享信息，既不是注册声明也不是公共声明。

有效负载示例：

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

同样需要 Base64Url 编码，以形成 JWT 的第二部分。

Signature

签名 (Signature) 用于验证消息在整个过程中没有更改，并且对于使用私钥进行签名的令牌，它还可以验证 JWT 的发送者是它所说的真实身份。

例如，如果要使用 HMAC SHA256 算法，则将通过以下方式创建签名：

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

将这三部分合并

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

下图显示了一个 JWT ，它已对先前的 Header 和 Payload 进行了编码，并用一个 Signature 。

可以在这个网页 jwt.io Debugger 验证和生成 JWT

JWT 如何工作

在身份验证中，当用户使用其凭据成功登录时，将返回令牌。由于令牌是凭据，因此必须格外小心以防止安全问题。通常，令牌的有效时间不宜设置过长。

Tip: 由于缺乏安全性，您也不应该将敏感的会话数据存储在浏览器存储中。

每当用户想要访问受保护的路由或资源时，用户代理通常应在 Bearer 模式中使用授权头发送 JWT 。 Header 的内容应如下所示：

Authorization: Bearer 

在某些情况下，接口访问并不需要身份授权。服务器的受保护路由将在 Authorization Header 中检查 JWT令牌 是否有效，如果存在且有效，则将允许用户访问受保护的资源。

如果 JWT 包含必要的数据，则可以减少查询数据库中某些操作的需求。

如果令牌是在 Authorization Header 中发送的，则跨域资源共享 (CORS) 不会成为问题，因为它不使用 cookie 。

下图显示了如何获取 JWT 并将其用于访问 API或资源 ：

JWT令牌JWT令牌

下图详细的流程：

ps:请注意，使用签名令牌，令牌或令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改它。这意味着您不应将机密信息放入令牌中。

为什么需要 JWT

对比 Simple Web Tokens (SWT) 和 Security Assertion Markup Language Tokens (SAML) ，看看使用 JSON Web Tokens (JWT) 有什么好处。

• 由于 JSON 不如 XML 冗长，因此在编码时 JSON 的大小也较小，从而使 JWT 比 SAML 更紧凑。这使得 JWT 是在 HTML 和 HTTP环境 中传递的不错的选择。
• 在安全方面， SWT 只能使用 HMAC算法 进行对称签名。但是 JWT 和 SAML令牌 可以使用 X.509证书形式 的公用/专用密钥对进行签名。与签名 JSON 的简单性相比，使用 XML Digital Signature 签名 XML 而不引入模糊的安全漏洞是非常困难的。
• JSON 解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反， XML 没有自然的文档到对象映射。与 SAML 断言相比，这使使用 JWT 更加容易。
• 关于用法， JWT 是在 Internet 规模上使用的。这强调了在多个平台(尤其是移动平台)上对 JSON Web令牌 进行客户端处理的简便性。