全栈项目|小书架|服务器开发-JWT 详解

摘自:https://www.cnblogs.com/gdragon/p/11878935.html

全栈项目|小书架|服务器开发-JWT 详解

 

JWT#

官方简介:Introduction to JSON Web Tokens

文章基本是官网内容的翻译,英文不错的同学可点击上面的链接直接看英文文档。

什么是 JWT#

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

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

什么时候使用 JWT 验证#

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

JWT 的结构格式#

由三部分组成,这些部分由点.分隔,分别是:

  • Header
  • Payload
  • Signature

因此,JWT通常如下所示。

Copy
xxxxx.yyyyy.zzzzz

Header#

通常由两部分组成:

  • 令牌的类型(即JWT
  • 所使用的签名算法,例如:HMAC SHA256RSA

例如:

Copy
{
  "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
    这些是自定义声明,旨在在同意使用它们的各方之间共享信息,既不是注册声明也不是公共声明。

有效负载示例:

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

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

Signature#

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

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

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

将这三部分合并#

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

下图显示了一个JWT,它已对先前的HeaderPayload进行了编码,并用一个Signature
在这里插入图片描述

可以在这个网页 jwt.io Debugger 验证和生成JWT
在这里插入图片描述

JWT 如何工作#

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

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

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

Copy
Authorization: Bearer <token>

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

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

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

下图显示了如何获取JWT并将其用于访问API或资源
在这里插入图片描述

  1. 应用程序或客户端向授权服务器请求授权。生产JWT令牌
  2. 授予授权后,授权服务器会将访问令牌返回给应用程序。
  3. 应用程序使用访问令牌来访问受保护的资源(例如API)。
  4. 服务器检查JWT令牌是否有效,返回对应结果给客户端

下图详细的流程:
在这里插入图片描述

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

为什么需要 JWT#

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

  • 由于JSON不如XML冗长,因此在编码时JSON的大小也较小,从而使JWTSAML更紧凑。这使得JWT是在HTMLHTTP环境中传递的不错的选择。
  • 在安全方面,SWT只能使用HMAC算法进行对称签名。但是JWTSAML令牌可以使用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

版权:本站使用「CC BY 4.0」创作共享协议,转载请在文章明显位置注明作者及出处。

 
标签: JWTNodeJS
 
原文地址:https://www.cnblogs.com/xichji/p/11884246.html