JWT
官方简介: Introduction to JSON web Tokens
文章基本是官网内容的翻译, 英文不错的同学可点击上面的链接直接看英文文档.
什么是 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 的结构格式
由三部分组成, 这些部分由点. 分隔, 分别是:
- Header
- Payload
- Signature
因此, JWT 通常如下所示.
xxxxx.yyyyy.zzzzz Header
通常由两部分组成:
令牌的类型(即 JWT)
所使用的签名算法, 例如: HMAC https://baike.baidu.com/item/hmac SHA256 https://baike.baidu.com/item/sha256 或.
例如:
- {
- "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 https://jwt.io/ 验证和生成 JWT
JWT 如何工作
在身份验证中, 当用户使用其凭据成功登录时, 将返回令牌. 由于令牌是凭据, 因此必须格外小心以防止安全问题. 通常, 令牌的有效时间不宜设置过长.
Tip: 由于缺乏安全性, 您也不应该将敏感的会话数据存储在浏览器存储中.
每当用户想要访问受保护的路由或资源时, 用户代理通常应在 Bearer 模式中使用授权头发送 JWT.Header 的内容应如下所示:
Authorization: Bearer <token>
在某些情况下, 接口访问并不需要身份授权. 服务器的受保护路由将在 Authorization Header 中检查 JWT 令牌是否有效, 如果存在且有效, 则将允许用户访问受保护的资源.
如果 JWT 包含必要的数据, 则可以减少查询数据库中某些操作的需求.
如果令牌是在 Authorization Header 中发送的, 则跨域资源共享 (CORS) 不会成为问题, 因为它不使用 cookie.
下图显示了如何获取 JWT 并将其用于访问 API 或资源:
应用程序或客户端向授权服务器请求授权. 生产 JWT 令牌.
授予授权后, 授权服务器会将访问令牌返回给应用程序.
应用程序使用访问令牌来访问受保护的资源(例如 API).
服务器检查 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 令牌进行客户端处理的简便性.
如果您想了解有关 JSON Web 令牌的更多信息, 甚至开始使用它们在自己的应用程序中执行身份验证, 请浏览到 Auth0 上的 JSON Web 令牌登录 页面.
咨询请加微信: 轻撩即可.
来源: https://www.cnblogs.com/gdragon/p/11878935.html