JWT文档翻译中英对照 -- introduction-CSDN博客

2019独角兽企业重金招聘Python工程师标准>>>

What is JSON Web Token?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

JWT是一开源的标准，定义了一种使用JSON在不同的实体之间安全地传输数据的办法。

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

使用JWT传输的数据是可以信赖的，因为这些信息有电子签名。电子签名可以通过HMAC算法实现，或者通过RSA公钥/私钥对实现。

Compact: Because of their smaller size, JWTs can be sent through a URL, POST parameter, or inside an HTTP header. Additionally, the smaller size means transmission is fast.

Compact: 是指其size较小，JWT数据可以通过URL、POST参数或者HTTP header来传输。

Self-contained: The payload contains all the required information about the user, avoiding the need to query the database more than once.

Self-contained: JWT信息的payload部分包含了所有的用户信息，让服务端可以免于多次查询数据库

When should you use JSON Web Tokens?

Here are some scenarios where JSON Web Tokens are useful:

Authentication: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.

鉴权：这是JWT应用的最常见场景。只要user成功登录，其后续的所有请求信息都会包含JWT，允许user访问这个JWT被允许访问的所有路径、服务和资源。如今单次登录广泛采用JWT实现，因为JWT的费用较低，并且可以很容易在各种领域中通用。

Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.

信息交互：JWT是一种在不同实体间安全交互消息的有效方法。因为JWT可以被“签名”，比如使用公钥/私钥对，可以有效掌握“the senders are who they say they are”。另外，由于签名是通过header和payload计算得来，同样可以用来验证消息的内容没有被修改过。

What is the JSON Web Token structure?

JSON Web Tokens consist of three parts separated by dots (.), which are:

Header Payload Signature Therefore, a JWT typically looks like the following.

xxxxx.yyyyy.zzzzz

Let's break down the different parts.

JSON Wwb Tokens通常由用.分隔的三个部分组成，包括：

Header，头部
Payload，数据
Signature，数字签名

所以JWT的样式一般为：xxxxx.yyyyy.zzzzz。

下面分别看看这三个部分。

Header头部

The header typically consists of two parts: the type of the token, which is JWT, and the hashing algorithm being used, such as HMAC SHA256 or RSA.

头部通常由两个部分组成：

JWT的类型
摘要生成使用的离散算法，比如HMAC SHA256或者RSA

For example:

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

Then, this JSON is Base64Url encoded to form the first part of the JWT.

这个JSON经过Base64Url编码后就组成了JWT的头部。

Payload数据

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional metadata. There are three types of claims: reserved, public, and private claims.

token的第二部分是payload，这个部分包括了身份声明。身份声明一般包括用户的信息，以及其他附加的元信息。声明有三种类型：reserved,public和private的。

Reserved claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience), and others.

Reserved claims: 包括一些预定义的、非强制性的但是推荐使用的、有助于交互的声明，比如说：

iss(issuer)发行人
exp(expiration time)过期时间
sub(subject)主题
aud(audience)目标听众

Notice that the claim names are only three characters long as JWT is meant to be compact.

注意到声明的名字是三个字母长度的简写，因为JWT需要是compact的。

Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.

Public claims: 保留给JWT的使用者自定义。但是需要注意避免使用IANA JSON Web Token Registry中定义的关键字。

Private claims: These are the custom claims created to share information between parties that agree on using them.

Private claims: 用户声明，用来传送传输双方约定好的消息

An example of payload could be:

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

The payload is then Base64Url encoded to form the second part of the JSON Web Token. 这个JSON经过Base64Url编码后就组成了JWT的第二部分。

Signature签名

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

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

The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.

Putting all together

The output is three Base64 strings separated by dots that can be easily passed in HTML and HTTP environments, while being more compact when compared to XML-based standards such as SAML.

How do JSON Web Tokens work?

In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned and must be saved locally (typically in local storage, but cookies can be also used), instead of the traditional approach of creating a session in the server and returning a cookie.

在验证过程中，当user使用其密码成功登录后，服务端会返回给user一个JWT，user需要将其保存在本地，或者保存在cookied中。而不是像传统的做法，需要创建一个session，然后服务器返回一个cookie给user。

Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following:

无论何时user想要访问一个受保护的路径或者资源，user需要发送一个在HTTP请求的头部使用Bearer schema添加JWT 。请求的头部看起来会像下面这样：

Authorization: Bearer <token>

This is a stateless authentication mechanism as the user state is never saved in server memory. The server's protected routes will check for a valid JWT in the Authorization header, and if it's present, the user will be allowed to access protected resources. As JWTs are self-contained, all the necessary information is there, reducing the need to query the database multiple times.

只要服务端不保存用户的状态，这就是一个无状态的验证机制。服务端的受保护路径会检查登录请求头部的JWT，如果有，该用户就可以访问这些受保护的资源。由于JWT包含了user的所有需要的信息，服务端就不必多次访问数据库来验证。

This allows you to fully rely on data APIs that are stateless and even make requests to downstream services. It doesn't matter which domains are serving your APIs, so Cross-Origin Resource Sharing (CORS) won't be an issue as it doesn't use cookies.

这个做法让你可以完全依赖于无状态的数据API，甚至访问下游的服务。无论你在哪个领域中使用你的API，CORS都不会造成困扰因为其不使用cookies。

The following diagram shows this process: