jwt::decode_停止猜测：什么是JWT？

最新推荐文章于 2024-09-03 08:35:11 发布

weixin_26738395

最新推荐文章于 2024-09-03 08:35:11 发布

阅读量467

点赞数

原文链接：https://medium.com/steve-cruz/stop-guessing-what-is-a-jwt-2ecd1726d2b6

版权

本文深入解析JWT（JSON Web Token）的核心组件jwt::decode，帮助读者清晰了解JWT的工作原理及其在身份验证和授权中的应用。

摘要由CSDN通过智能技术生成

jwt::decode

JSON Web令牌(JWT) (JSON Web Token (JWT))

A JWT Is an open standard that defines a compact and self-contained way for performing Authentication in REST APIs where information is securely transmitted between both parties as a JSON object.

JWT是一种开放标准 ，它定义了一种紧凑且自包含的方式，用于在REST API中执行身份验证，在REST API中 ，信息在双方之间作为JSON对象安全地传输。

This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with HMAC algorithm) or a public/private key pair using RSA.

由于此信息是经过数字签名的，因此可以被验证和信任。可以使用秘密 (使用HMAC算法 )或使用RSA的公/私钥对对 JWT进行签名。

NOTE 1: We consider it compact because of its size, it’s possible to send it through an URL, POST parameter, or inside an HTTP header. Also due to its size its transmission is fast.NOTE 2: We consider it self-contained because we do not need to query the database more than once, the payload contains all the necessary information about the user.

注意1 ：由于它的大小，我们认为它是紧凑的，可以通过URL，POST参数或HTTP标头发送它。同样由于其尺寸，其传输速度很快。注2 ：我们认为它是独立的，因为我们不需要查询数据库一次以上，有效负载包含有关用户的所有必要信息。

什么时候使用JWT？ (When to use JWT?)

Authentication: After the user is signed in, each subsequent request includes the JWT. This allows the user to access routes, services, and resources that require that token.
身份验证 ：用户登录后，每个后续请求都包含JWT。这允许用户访问需要该令牌的路由，服务和资源。
Information Exchange: JWTs are a secure way of transmitting information between parties, because you can be sure that the sender is who they say they are, since they can be signed (possibly by using a public/private key pair). You can also verify that the content hasn’t changed, since the signature is created using the header and the payload.
信息交换 ：JWT是在各方之间传输信息的一种安全方式，因为您可以确定发送者是他们所说的人，因为可以对其进行签名(可能使用公钥/私钥对)。您还可以验证内容没有更改，因为签名是使用标头和有效负载创建的。

JWT结构 (JWT Structure)

A JWT is formed by three parts separated by dots (.): a Header, a Payload, and a Signature. These parts follow this structure: xxxxx.yyyyy.zzzzz.

JWT由用点( . )分隔的三个部分组成： Header ， Payload和Signature 。这些部分遵循以下结构： xxxxx.yyyyy.zzzzz 。

Image for post — The red part is the header, the pink part is the payload and the blue part is the signature.

标头 (Header)

Contains some information that usually include the token type (which is JWT) and the hashing algorithm (such as HMAC, SHA256 or RSA).

包含一些通常包含 token type (即JWT )和hashing algorithm (例如HMAC ， SHA256或RSA )的信息。

Afterwards the JSON containing that Header is Base64Url encoded to form the first part of the JWT.

之后，包含该Header的JSON被Base64Url编码以形成JWT的第一部分 。

//Example of a Header
{
  "alg": "HS256",
  "typ": "JWT"
}

有效载荷 (Payload)

Contains the claims that are statements about an entity (usually the user) and additional metadata.NOTE: Can not contain sensible information about a user like password, but it's ok to include user id, name or email.

包含claims是关于实体(通常是用户的)和附加元数据 语句。注意： 不能包含有关用户的 明智信息 ，例如password ，但是可以包含用户ID ，名称或电子邮件 。

Example of claims: iss (issuer), exp (expiration time), sub (subject), aud (audience), among others.

索赔示例 ： iss ( 发行方 )， exp ( 到期时间 )， sub ( 主题 )， aud ( 受众 ) 等。

Afterwards the JSON containing the payload is then Base64Url encoded to form the second part of the JWT.

然后，将包含有效负载的JSON进行Base64Url编码，以形成JWT的第二部分 。

//Example of a Payload
{
  "sub": "0987654321",
  "name": "Jane Doe",
  "admin": true 
}

签名 (Signature)

Is used to verify that the sender of the JWT is who he claims to be and to ensure that the message wasn’t changed while it was being transmitted.

用于验证 JWT的发送者 是否是他声称的身份，并用于确保消息在传输过程中没有被更改。

To create the signature take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign it.

要创建 签名，请使用encoded header ， encoded payload ， secret ， 标头中指定的algorithm ，并对它进行签名 。

//Example of a Signature using the HMAC SHA256 algorithm
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

NOTE: A simple way to generate a secret is using http://www.md5.cz/ to generate a MD5 hash of a string.

注意：生成secret一种简单方法是使用http://www.md5.cz/生成字符串的MD5哈希。

结合三个部分 (Uniting the three parts)

The output is three Base64 strings separated by dots: an encoded header, an encoded payload and it is signed with a secret. They can be passed in HTML and HTTP environments.

输出由点分隔的三个Base64字符串：一个编码的标头 ，一个编码的有效负载，并用secret签名 。它们可以在HTML和HTTP环境中传递。

NOTE: Go to jwt.io, a website that allows you to decode, verify and generate JWT.

注意：请访问jwt.io ，该网站可让您解码，验证和生成JWT。

JWT如何工作？ (How does a JWT work?)

When the user is authenticated by successfully signing in using their credentials, a JWT will be returned.
通过使用其凭据成功登录来认证用户后，将返回JWT。

NOTE: Keep in mind that tokens are credentials, so you must prevent security issues: do not keep tokens longer than required.

注意：请记住， 令牌是凭据 ，所以您必须防止安全问题：令牌的保存时间不能超过要求的时间。

2. Whenever the user wants to access a protected route, its request should send the JWT, usually in the Authorization header using the Bearer schema: Authorization: Bearer <token>.

2.每当用户想要访问受保护的路由时，它的请求都应该发送JWT，通常是使用Bearer模式在Authorization header发送： Authorization: Bearer <token> 。

NOTE: This authentication mechanism is stateless, because the user state is not saved in the server memory. Instead, the server’s protected routes check for a valid JWT in the Authorization header, and only allows the user if this condition is fulfilled. As a result it is not necessary to query the database multiple times as JWTs are self-contained, so it already has all the necessary information.

注意：此身份验证机制是无状态的 ，因为用户状态未保存在服务器内存中。相反，服务器的受保护路由会在Authorization标头中检查有效的JWT，并且仅在满足此条件时才允许用户使用。结果，由于JWT是独立的，因此不必多次查询数据库，因此它已经具有所有必需的信息。

为什么要使用JWT？ (Why Should You Use JWT?)

They are stateless: Since tokens are self-contained they have all the information that is needed for authentication. This is good for scalability as your server does not have to store session state.
它们是无状态的：由于令牌是独立的，因此它们具有身份验证所需的所有信息。这对于可伸缩性很有用，因为您的服务器不必存储会话状态。
They can be generated from anywhere: Token generation and token verification are decoupled. This allows you to handle the signing of tokens on a separate server.
它们可以在任何地方生成：令牌生成和令牌验证是分离的。这使您可以在单独的服务器上处理令牌的签名。
They allow access control: Within the payload it’s possible to specify user roles and permissions. You can also define the resources that the user can access.
它们允许访问控制：在有效负载中，可以指定用户角色和权限。您还可以定义用户可以访问的资源。

最佳实践 (Best Practices)

Let tokens expire: When a token is signed it will never expire unless you change the signing key or explicitly set an expiration. This could pose potential issues so it’s necessary to have a strategy for expiring and/or revoking tokens.
让令牌过期：签名令牌后，它将永远不会过期，除非您更改签名密钥或明确设置过期时间。这可能会带来潜在的问题，因此有必要制定一种策略来过期和/或吊销令牌。
Do not store sensitive data in the payload: Tokens can be easily decoded, their goal is to protect against manipulation with their signature. So only add the necessary number of claims to the payload to have the best possible performance and security.
不要将敏感数据存储在有效负载中：令牌可以轻松解码，其目的是防止签名对其进行操作。因此，仅将必要数量的声明添加到有效负载中，以具有最佳的性能和安全性。
Be a good magician, don’t reveal your secret: Only reveal the signing key to services that really need it. It should be treated like any other credentials.
成为一名优秀的魔术师，不要泄露您的秘密：只透露真正需要它的服务的签名密钥。应该像对待其他任何凭据一样对待它。
Utilize HTTPS: On non-HTTPS connections the requests can be intercepted and tokens compromised more easily.
利用HTTPS：在非HTTPS连接上，可以拦截请求，更轻松地破坏令牌。