JWT
JSON Web Token (abbreviated JWT) is the most popular cross-domain authentication solution available today
JWT Background
Internet services are inseparable from user authentication. The general process is as follows.
The user sends the username and password to the server.
After server authentication, relevant data is saved inside the current session, such as user role, login time, etc.
The server returns a session_id to the user, which is written to the user’s cookie.
Each subsequent request from the user will send the session_id back to the server via a cookie.
The server receives the session_id, finds the data saved in the previous session, and learns the identity of the user from it.
The problem with this model is that scaling is not good. If it is a server cluster, or a cross-domain service-oriented architecture, it requires session data sharing, and each server can read the session.
For example, site A and site B are affiliated services of the same company. Now, it is required that once a user logs in at one of the sites, he/she will automatically log in when visiting the other site.
One solution is session data persistence, written to a database or another persistence layer. When various services receive a request, they request data from the persistence layer. The advantage of this solution is that it has a clear architecture, but the disadvantage is that it is a large amount of work. In addition, if the persistence layer hangs, there will be a single point of failure.
Another option is that the server simply does not store the session data, all data is stored on the client side and sent back to the server for each request. jwt is a representative of this option.
Structure of JWT
jwt is a very long string with three parts separated by a dot.
The three parts of the JWT are as follows in order.
- Header
- Payload
- Signature
Written in one line, it looks like the following.
``javascript
Header.Payload.Signature
2
3
4
5
6
7
8
9
10
### Header
The Header section is a JSON object that describes the metadata of the JWT and usually looks like the following.
``javascript
{
"alg": "HS256",
"typ": "JWT"
}
In the above code, the alg attribute indicates the algorithm of the signature (algorithm), the default is HMAC SHA256 (written as HS256); the typ attribute indicates the type of this token (token) (type), JWT tokens are uniformly written as JWT.
Finally, the JSON object above is converted to a string using the Base64URL algorithm (see later for details).
Payload
The Payload section is also a JSON object that holds the actual data to be passed. jwt specifies 7 official fields to choose from.
- iss (issuer): issuer
- exp (expiration time): expiration time
- sub (subject): subject
- aud (audience)：受众
- nbf (Not Before): effective time
- iat (Issued At): Time of issuance
- jti (JWT ID): No.
In addition to the official fields, you can also define private fields in this section, an example of which is shown below.
2
3
4
5
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Note that the JWT is unencrypted by default and can be read by anyone, so don’t put secret information in this section.
This JSON object is also converted to a string using the Base64URL algorithm.
Signature
The Signature section is a signature for the first two sections to prevent data tampering.
First, a key (secret) needs to be specified. This key is known only to the server and cannot be disclosed to the user. Then, using the signature algorithm specified in the Header (the default is HMAC SHA256), the signature is generated according to the following formula.
2
3
4
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
After the signature is calculated, the Header, Payload and Signature are put together into a string, and each part is separated by a . ) between each part, and then it can be returned to the user.
Features of JWT
Advantages
1. The solution is more easily scalable horizontally
In the cookie-session scheme, the cookie contains only a session identifier, and information such as user information and authorization lists are stored in the session on the server side. If the authentication information in the session is stored in the JWT, there is no need for the session to exist on the server side. When the server side scales horizontally, there is no need to deal with session replication / session sticky session or to introduce external session storage.
2. The solution protects against CSRF attacks
Disadvantages
**More space occupation. **
If the various types of information that originally existed in the server-side session are placed in the JWT and stored in the client, it may cause the JWT to occupy a larger space, requiring consideration of factors such as the space limitations of cookies, and if placed in Local Storage, it may be subject to XSS attacks.
**More insecure. **
This refers specifically to the solution of saving JWT in Local Storage and then sending it to the server as HTTP header using Javascript. Storing sensitive information in Local Storage is not safe and vulnerable to cross-site scripting (xss for short), which is a kind of “HTML injection” and is called “cross-domain scripting” because the attacking scripts are mostly cross-domain. "These scripts can steal cookies or data from Local Storage. You can see the explanation of the principle of XSS attack in this article.
**It is not possible to void a token that has been issued. **
All authentication information is in the JWT, and since there is no state on the server side, even if you learn that a JWT has been stolen, there is nothing you can do to invalidate it. Until the JWT expires (and you should absolutely set an expiration time), there is nothing you can do about it.
**It is not easy to cope with data expiration. **
Similar to the previous article, JWT is somewhat like a cache in that you can only live with “expired” data until it expires, since you can’t void the issued token.
Reference article:
http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html