json转jwt_JSON Web令牌(JWT)解释

JWT是一种用于创建访问令牌的标准,通过服务器生成并发送给客户端,客户端在后续请求中携带令牌以验证身份。常用于API认证和服务器间授权。JWT由头部、有效载荷和签名三部分组成,其安全性依赖于加密签名。尽管JWT常被批评过度使用,但在API认证中有其价值。不应将JWT用作会话令牌,应使用服务器端会话机制。选择JWT库时,可根据语言和环境从jwt.io等资源中选择。
摘要由CSDN通过智能技术生成

json转jwt

JSON Web Token is a standard used to create access tokens for an application.

JSON Web令牌是用于为应用程序创建访问令牌的标准。

It works this way: the server generates a token that certifies the user identity, and sends it to the client.

它是这样工作的:服务器生成一个证明用户身份的令牌,并将其发送给客户端。

The client will send the token back to the server for every subsequent request, so the server knows the request comes from a particular identity.

客户端将针对每个后续请求将令牌发送回服务器,因此服务器知道请求来自特定身份。

This architecture proves to be very effective in modern Web Apps, where after the user is authenticated we perform API requests either to a REST or a GraphQL API.

这种体系结构在现代Web应用程序中被证明是非常有效的,在现代Web Apps中,在对用户进行身份验证之后,我们向REST或GraphQL API执行API请求。

Who uses JWT? Google, for example. If you use the Google APIs, you will use JWT.

谁使用JWT? 以Google为例。 如果您使用Google API,则将使用JWT。

A JWT is cryptographically signed (but not encrypted, hence using HTTPS is mandatory when storing user data in the JWT), so there is a guarantee we can trust it when we receive it, as no middleman can intercept and modify it, or the data it holds, without invalidating it.

甲JWT被加密签名(但加密,因此使用HTTPS存储在所述JWT用户数据时是强制性的),所以有一个保证当我们收到它,因为没有中间人可以截取并修改它我们可以信任它,或数据它保持有效,而不会使其无效。

That said, JWTs are often criticized for their overuse, and especially for them being used when less problematic solutions can be used.

也就是说,JWT经常因使用过多而受到批评,尤其是当可以使用问题较少的解决方案时使用它们。

You need to form your opinion around the subject. I’m not advocating for a technology over another, just presenting all the opportunities and tools you have at your disposal.

您需要围绕该主题形成您的意见。 我并不是在提倡一项技术,而是要提供所有可用的机会和工具。

What are they good for? Mainly API authentication, and server-to-server authorization.

他们有什么用? 主要是API身份验证和服务器到服务器授权。

JWT令牌是如何生成的? (How is a JWT token generated?)

Using Node.js you can generate the first part of the token by using this code:

使用Node.js,可以使用以下代码生成令牌的第一部分:

const header = { "alg": "HS256", "typ": "JWT" }
const encodedHeader = Buffer.from(JSON.stringify(header)).toString('base64')

We set the signing algorithm to be HMAC SHA256 (JWT supports multiple algorithms), then we create a buffer from this JSON-encoded object, and we encode it using base64.

我们将签名算法设置为HMAC SHA256 (JWT支持多种算法),然后从此JSON编码对象创建一个缓冲区,然后使用base64对其进行编码。

The partial result is eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

部分结果是eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Next we add the payload, which we can customize with any kind of data. There are reserved keys, including iss and exp which identify the issuer and the expiration time of the token.

接下来,我们添加有效载荷,我们可以使用任何类型的数据对其进行自定义。 有保留的密钥,包括issexp ,用于标识发行者和令牌的到期时间。

You can add your own data to the token by using an object:

您可以使用对象将自己的数据添加到令牌中:

const payload = { username: 'Flavio' }

We convert this object, JSON-encoded, to a Buffer and we encode the result using base64, just like we did before:

我们将经过JSON编码的对象转换为Buffer,然后像以前一样使用base64对结果进行编码:

const encodedPayload = Buffer.from(JSON.stringify(payload)).toString('base64')

In this case the partial result is eyJ1c2VybmFtZSI6IkZsYXZpbyJ9.

在这种情况下,部分结果为eyJ1c2VybmFtZSI6IkZsYXZpbyJ9

Next, we get a signature from the header and payload content, which makes sure our content can’t be changed even if intercepted as our signature will be invalidated. To do this, we’ll use the crypto Node module:

接下来,我们从标头和有效内容中获取签名,以确保即使被截取也不会更改我们的内容,因为签名将无效。 为此,我们将使用crypto Node模块

const crypto = require('crypto')
const jwtSecret = 'secretKey'

const signature = crypto.createHmac('sha256', jwtSecret).update(encodedHeader + '.' + encodedPayload).digest('base64')

We use the secretKey secret key and create a base64 encoded representation of the encrypted signature.

我们使用secretKey秘密密钥并创建加密签名的base64编码表示。

The value of the signature in our case is

在我们的案例中,签名的价值是

MQWECYWUT7bayj8miVgsj8KdYI3ZRVS+WRRZjfZrGrw=

MQWECYWUT7bayj8miVgsj8KdYI3ZRVS+WRRZjfZrGrw=

We are almost done, we just need to concatenate the 3 parts of header, payload and signature by separating them with a dot:

我们差不多完成了,我们只需要通过用点分隔它们来将标头,有效负载和签名的3个部分连接起来:

const jwt = `${encodedHeader}.${encodedPayload}.${signature}`

API认证 (API authentication)

This is probably the only sensible way to use JWT.

这可能是使用JWT的唯一明智的方法。

A common scenario is: you sign up for a service and download a JWT from the service dashboard. This is what you will use from now on to authenticate all your requests to the server.

常见的情况是:您注册服务并从服务仪表板上下载JWT。 从现在开始,您将使用此身份验证对服务器的所有请求。

Another use case, which is the opposite, is sending the JWT when you manage the API and clients connect to you, and you want your users to send subsequent requests by just passing the token.

相反,另一个用例是在管理API和客户端连接到您时发送JWT,并且您希望您的用户仅通过传递令牌来发送后续请求。

In this case, the client needs to store the token somewhere. Where is the best place? In an HttpOnly cookie. The other methods are all prone to XSS attacks and as such they should be avoided. An HttpOnly cookie is not accessible from JavaScript, and is automatically sent to the origin server upon every request, so it perfectly suits the use case.

在这种情况下,客户端需要将令牌存储在某处。 最好的地方在哪里? 在HttpOnly cookie中 。 其他方法都容易受到XSS攻击,因此应避免使用它们。 无法从JavaScript访问HttpOnly cookie,并且会在每次请求时自动将其发送到原始服务器,因此非常适合用例。

选择最好的JWT库 (Choose the best JWT library)

Depending on the language and environment you use, you can choose from a number of libraries. The most popular are listed in the jwt.io website.

根据您使用的语言和环境,您可以从许多库中进行选择。 最受欢迎的网站在jwt.io网站上。

不要将JWT用作会话令牌 (Don’t use JWTs as session tokens)

You should not use JWTs for sessions. Use a regular server-side session mechanism, as it’s much more efficient and less prone to data exposure.

您不应将JWT用于会话。 使用常规的服务器端会话机制,因为它效率更高且不太容易暴露数据。

资源资源 (Resources)

阅读更多 (Read more)

There is a lot of literature covering JWTs on the internet.

互联网上有很多有关JWT的文献。

You can literally lose hours reading blog posts and opinions. Some of those posts are

您可能会浪费大量时间阅读博客文章和意见。 其中一些职位是

翻译自: https://flaviocopes.com/jwt/

json转jwt

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值