JWT的介绍与使用

了解JWT,认识JWT的优缺点,学习接口中通如何使用JWT

Posted by 呆贝斯 on April 24, 2022

什么是JWT?

JWT( json web token )是一个开放标准 ( RFC 7519 ),它定义了一种紧凑且自包含的方式, 用于在各方之间以JSON对象的形式安全传输信息。信息可以验证和信任,因为它是数字签名的。 JWT可以使用密钥( 使用HMAC算法 )或使用RSA或ECDSA的公钥/私钥对进行签名。

让我们进一步解释这个定义的一些概念。

紧凑:由于它的大小,它可以通过 URL、POST 参数或 HTTP 标头内部发送。此外,由于它的大小,它的传输速度很快。
自包含:有效负载包含有关用户的所有必需信息,以避免多次查询数据库。

虽然 JWT 可以加密以在各方之间提供保密性,但我们将专注于签名令牌。 签名的令牌可以验证其中包含的声明的完整性,而加密的令牌会向其他方隐藏这些声明。 当使用公钥/私钥对对令牌进行签名时,签名还证明只有持有私钥的一方才是签署它的一方。

JWT结构是什么?

在其紧凑的形式中,JSON Web Tokens 由以点 ( .) 分隔的三部分组成。它们是标题、有效载荷、签名。 通常如下所示。 JWT是三个用点分隔的 Base64-URL 字符串,可以在 HTML 和 HTTP 环境中轻松传递,同时与基于 XML 的标准(如 SAML)相比更紧凑。 如果您想玩 JWT 并将这些概念付诸实践,您可以使用jwt.io Debugger来解码、验证和生成 JWT。 让我们分解不同的部分。

  • 标题: 标头通常由两部分组成:令牌的类型,即 JWT,以及正在使用的签名算法,例如 HMAC SHA256 或 RSA。 然后,这个 JSON 被Base64Url编码以形成 JWT 的第一部分。
    {
     "alg": "Hash算法(HMAC、SHA256或RSA)",
     "typ": "Token的类型(JWT)"
     }
    
  • 有效载荷: 其中包含声明。声明是关于实体(通常是用户)和附加数据的陈述。 声明分为三种类型:reserved、public和private声明(注册声明:这些是一组预定义的声明,它们不是强制性的,但建议使用, 以提供一组有用的、可互操作的声明。其中一些是: iss(发行人)、 exp(到期时间)、  sub(令牌的主体,一般设为资源拥有者的唯一标识)、iat(令牌颁发的时间)、 aud(受众)等。 请注意,声明名称只有三个字符,只要 JWT 是紧凑的。 公共声明:这些可以由使用 JWT 的人随意定义。但是为了避免冲突,它们应该在IANA JSON Web Token Registry中定义,或者定义为包含抗冲突命名空间的 URI。 私人声明:这些是为在同意使用它们的各方之间共享信息而创建的自定义声明,既不是注册声明也不是公共声明。)。然后对有效负载进行Base64Url编码以形成 JSON Web 令牌的第二部分。 请注意,对于已签名的令牌,此信息虽然受到保护以防篡改,但任何人都可以读取。除非已加密,否则请勿将机密信息放入 JWT 的有效负载或标头元素中。
    {
     "iss": "签发人(issuer)",
     "exp": "过期时间(expiration time)",
     "sub": "主题(subject)",
     "aud": "受众(audience)",
     "nbf": "生效时间(not before)",
     "iat": "签发时间(issued at)",
     "jti": "编号(JWT ID)",
     "uid": "自定义字段(可以存储用户ID等)",
     "name": "f",
     "admin": true
     }
    
  • 签名: 要创建签名部分,您必须获取编码的标头、编码的有效负载、秘密、标头中指定的算法,并对其进行签名。 例如,如果您想使用 HMAC SHA256 算法,签名将通过以下方式创建。 签名用于验证消息在此过程中没有被更改,并且在使用私钥签名的令牌的情况下,它还可以验证 JWT 的发送者就是它所说的那个人。
    HMACSHA256(
    base64UrlEncode(header) + "." + base64UrlEncode(payload),
    secret  //设置的密钥
    )
    

什么时候应该使用JWT?

以下是 JSON Web 令牌有用的一些场景:

  • 授权:这是使用 JWT 最常见的场景。用户登录后,每个后续请求都将包含 JWT,从而允许用户访问该令牌允许的路由、服务和资源。 单点登录是当今广泛使用 JWT 的一项功能,因为它的开销很小并且能够在不同的域中轻松使用。

  • 信息交换:JSON Web 令牌是在各方之间安全传输信息的好方法。 因为可以对 JWT 进行签名(例如,使用公钥/私钥对),所以您可以确定发件人就是他们所说的那个人。 此外,由于使用标头和有效负载计算签名,您还可以验证内容没有被篡改。

JSON Web 令牌如何工作?

在身份验证中,当用户使用其凭据成功登录时,将返回一个 JSON Web Token。由于令牌是凭据, 因此必须非常小心以防止出现安全问题。通常,您不应将令牌保留超过所需的时间。 由于缺乏安全性,您也不应该在浏览器存储中存储敏感的会话数据。

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

Authorization: Bearer <token>

这是一种无状态身份验证机制,因为用户状态永远不会保存在服务器内存中。 服务器的受保护路由将检查Authorization标头中是否存在有效的 JWT, 如果存在,则允许用户访问受保护的资源。由于 JWT 是自包含的,所有必要的信息都在那里, 则可能会减少查询数据库以进行某些操作的需要,尽管情况并非总是如此。 这允许完全依赖无状态的数据 API,甚至可以向下游服务发出请求。哪些域为您的 API 提供服务并不重要,因为跨域资源共享 (CORS) 不会成为问题,因为它不使用 cookie。 请注意,如果您通过 HTTP 标头发送 JWT 令牌,则应尽量防止它们变得太大。某些服务器不接受超过 8 KB 的标头。如果您试图在 JWT 令牌中嵌入太多信息, 例如通过包含所有用户的权限,您可能需要替代解决方案,例如Auth0 Fine-Grained Authorization。 如果令牌在Authorization标头中发送,则跨域资源共享 (CORS) 不会成为问题,因为它不使用 cookie。

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

  1. 应用程序或客户端向授权服务器请求授权。这是通过不同的授权流程之一执行的。例如,一个典型的符合OpenID Connect的Web 应用程序将使用授权代码流/oauth/authorize通过端点。
  2. 当授权被授予时,授权服务器向应用程序返回一个访问令牌。
  3. 应用程序使用访问令牌访问受保护的资源(如 API)。 请注意,使用签名令牌,令牌中包含的所有信息都会向用户或其他方公开,即使他们无法更改。这意味着您不应将秘密信息放入令牌中。

为什么我们应该使用 JSON Web Tokens?

让我们谈谈JSON Web Tokens (JWT)与Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML)相比的优势。 由于 JSON 不像 XML 那样冗长,因此在对其进行编码时,它的大小也更小,这使得 JWT 比 SAML 更紧凑。这使得 JWT 成为在 HTML 和 HTTP 环境中传递的不错选择。 安全方面,SWT 只能通过使用 HMAC 算法的共享密钥进行对称签名。但是,JWT 和 SAML 令牌可以使用 X.509 证书形式的公钥/私钥对进行签名。与签署 JSON 的简单性相比,使用 XML 数字签名签署 XML 而不引入隐蔽的安全漏洞是非常困难的。 JSON 解析器在大多数编程语言中都很常见,因为它们直接映射到对象。相反,XML 没有自然的文档到对象映射。这使得使用 JWT 比使用 SAML 断言更容易。 关于使用,JWT 用于 Internet 规模。这突出了 JSON Web 令牌在多个平台(尤其是移动平台)上客户端处理的便利性。

JWT 优缺点

  • 优点
    1. 计算代替存储
    2. 加密
    3. 增强系统可用性和可伸缩性
    4. 降低AuthServer压力
    5. 简化AuthServer实现
  • 缺点 无状态和吊销无法两全,比如我在使用xx时,可能因为莫须有原因修改了在公众号平台的密码或突然取消了给xx的授权。这时,令牌状态就该有变更,将原来对应令牌置为无效。 但使用JWT时,每次颁发的令牌都不会存在服务端,无法改变令牌状态。这表示JWT令牌再有小区内畅通无阻。 那么可以把JWT令牌存储在一个分布式内存数据库,比如redis中吗? NO!这违背JWT意义-将信息结构化存入令牌本身。 通常有两种方案:
    1. 将每次生成JWT令牌时的密钥粒度缩小到用户将级别,即一个用户一个密钥。如此,当用户取消收取那或修改密码时,可让该密钥一起修改。这种方案一般还需要配套单独密钥管理服务。
    2. 在不提供用户主动取消授权的环境里面,若只考虑修改密码场景,即可把用户密码作为JWT的密钥,这也是用户力度,这样用户修改密码就相当于修改了密钥。 网络传输开销 随claims增多而增大

OAuth2.0使用JWT

授权服务的核心就是颁发访问令牌,而OAuth2.0规范并没有约束访问令牌内容的生成规则,只要符合唯一性、不连续性、不可猜性。可以灵活的选择令牌的形式, 既可以是没有内部结构且不包含任何信息的随机字符串,也可以是具有内部结构且包含信息含义的字符串。

令牌的生命周期

令牌都有有效期,只有JWT可以把有效期的信息存在本身结构。 OAuth2.0的令牌生命周期,通常有三种情况:

  1. 令牌自然过期,该过程中不排除主动销毁令牌的可能,比如令牌被泄露,授权服务可让令牌失效。
  2. 访问令牌失效后可使用刷新令牌请求新令牌,提高用户使用三方软件的体验。
  3. 让三方软件比如XX,主动发起令牌失效请求,然后授权服务收到请求后让令牌立即失效。何时需要该机制? 比如用户和三方软件之间存在一种订购协议:我购买了xx软件,那么到期或退订时且我授权的token还未到期情况下,就需要这样一种令牌撤回协议, 支持xx主动发起令牌失效的请求。作为开放平台,也建议有责任的三方软件遵守这样的一种令牌撤回协议。

总结

OAuth2.0的核心是授权服务,没有令牌就没有OAuth,令牌表示授权后的结果。令牌在OAuth2.0系统中对于第三方软件都是不透明的。需要关心令牌的,是收取那服务和受保护资源服务。

  1. JWT默认是不加密,但也是可以加密的。生成原始Token以后,可以用密钥再加密一次。
  2. JWT不加密情况下,不能将秘密数据写入JWT。
  3. JWT不仅可以用于认证,也可以用于交换信息。有效使用JWT,可以降低服务器查询数据库的次数。
  4. JWT的最大缺点是,由于服务器不保存session状态,因此无法在使用过程中废止某个token,或者更改token的权限