JWT简介

原文地址:https://jwt.io/introduction/

什么是JSON Web Token?

JSON Web Token(JWT)是一个开放标准(RFC 7519),它定义了一种紧凑且自包含的方式,用于在各程序之间以JSON对象方式安全地传输信息。由于此信息是经过数字签名的,因此可以被验证和信任。可以使用加密算法(使用HMAC算法)或使用RSAECDSA的公钥/私钥对对JWT进行签名

尽管JWTs可以被加密以在双方之间提供保密性,但我们将重点关注已签名的令牌。签名的令牌可以验证其中包含的claims 完整性,而加密的令牌则将这些claims 隐藏了当使用公钥/私钥对token进行签名时,签名还证明只有持有私钥的一方才是对其进行签名的一方。

什么时候应该使用JSON Web Token?

以下是JSON Web Token使用场景:

  • Authorization(授权):这是使用JWT最常见的场景。一旦用户登录,后续的每一个请求将附带JWT,从而允许用户访问该token允许的路由,服务和资源。单点登录是当今广泛使用JWT的一个特性,因为它的开销很小并且可以在不同的域中轻松使用。

  • 信息交换:JSON Web Token是在各程序之间安全地传输信息的好方法。因为可以对JWT进行Signature(例如,使用公钥/私钥),所以您可以确定发件人是他本人。另外,由于Signature是使用header和payload计算出来的,因此您还可以验证内容是否未被篡改。

JSON Web令牌结构是什么?

JSON Web Token以紧凑的形式由三部分组成,这些部分由点(.分隔,分别是:

  • header
  • payload
  • signature

因此,JWT通常如下所示。

xxxxx.yyyyy.zzzzz

让我们分解不同部分。

header

header通常由两部分组成:token的类型(JWT)和所使用的签名算法,例如HMAC SHA256或RSA。

例如:

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

然后,此JSON通过Base64Url编码作为JWT的第一部分。

payload

token的第二部分是payload,其中包含claims。claims是有关实体(通常是用户)和其他数据的claims。claims有以下三种类型:registeredpublic, 和 private claims

  • registered claims:这些是一组非强制性的但建议使用的预定义claims,以提供一组有用的,可互操作的claims。其中一些是: iss(发出者), exp(到期时间), sub(主题), aud(受众)

    请注意,声明名称仅是三个字符,因为JWT是紧凑的。

  • public claims:使用JWT的人可以随意定义这些claims。但是为避免冲突,应在 IANA JSON Web令牌注册表中定义它们,或将其定义为包含避免冲突名称空间的URI。

  • private claims:这些自定义claims是为在同意使用这些声明的各方之间共享信息而创建的,它们既不是注册声明,也不是公开声明。

payload示例可能是:

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

然后,对payload进行Base64Url编码,作为JSON Web令牌的第二部分。

请注意,对于已签名的token,此信息尽管可以防止篡改,但任何人都可以读取。除非将其加密,否则请勿将机密信息放入JWT的payload或header元素中。

signature

要创建signature部分,您必须获取编码的header,编码的payload,secret,header中指定的算法,并对其进行签名。

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

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

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

放在一起

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

下图显示了一个JWT,它已对先前的header和payload进行了编码,并用一个secret进行了签名。 编码的JWT

如果您想使用JWT并将这些概念付诸实践,则可以使用jwt.io Debugger解码,验证和生成JWT。

JWT.io调试器

JSON Web Token如何工作?

在身份验证中,当用户使用其凭据成功登录时,将返回JSON Web Token。由于token是凭据,因此必须格外小心以防止安全问题。通常,令牌的保留时间不应超过要求的时间。

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

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

Authorization: Bearer <token>

在某些情况下,这可以是无状态授权机制。服务器的受保护路由将在Authorization标头中检查有效的JWT ,如果存在,则将允许用户访问受保护的资源。如果JWT包含必要的数据,则可以减少查询数据库中某些操作的需求,尽管这种情况并非总是如此。

如果token是在Authorization标头中发送的,则跨域资源共享(CORS)不会成为问题,因为它不使用cookie。

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

JSON Web令牌如何工作

  1. 应用程序或客户端向授权服务器请求授权。这是通过不同的授权流程之一执行的。例如,典型的符合OpenID Connect的 Web应用程序将/oauth/authorize使用授权代码流通过端点
  2. 授予权限后,授权服务器会将访问token返回给应用程序。
  3. 应用程序使用访问token来访问受保护的资源(例如API)。

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

我们为什么要使用JSON Web Token?

让我们谈谈简单Web Token(SWT)安全性声明标记语言令牌(SAML)相比JSON Web Token(JWT)的好处

由于JSON不如XML冗长,因此在编码时JSON的大小也较小,从而使JWT比SAML更紧凑。这使得JWT是在HTML和HTTP环境中传递的不错的选择。

在安全方面,只能使用HMAC算法由共享机密对SWT进行对称签名。但是,JWT和SAML令牌可以使用X.509证书形式的公用/专用密钥对进行签名。与签名JSON的简单性相比,使用XML Digital Signature签名XML而不引入模糊的安全漏洞是非常困难的。

JSON解析器在大多数编程语言中都很常见,因为它们直接映射到对象。相反,XML没有自然的文档到对象映射。与SAML断言相比,这使使用JWT更加容易。

关于用法,JWT是在Internet规模上使用的。这强调了在多个平台(尤其是移动平台)上对JSON Web令牌进行客户端处理的简便性。

比较已编码的JWT和已编码的SAML的长度 

编码的JWT和编码的SAML的长度比较

原文地址:https://www.cnblogs.com/SmilingEye/p/12163637.html