The paper

It’s easy to explain JWT in one sentence. Those of you who have written apis will be familiar with the introduction of parameter signatures in order to prevent the API from being called illegally. The easiest way to do this is to string the parameters, add a key, and then make an MD5 signature. As long as the requested signature does not match, the parameter is considered maliciously tampered with. JWT standardizes this. The header part of the JWT describes how to sign, the payload part is the parameter, and the signature part is the signature. Then, for URL security, make the entire data base64.

Break down

Recently I was thinking about making an OAuth2 API, but almost all OAuth2 routines pull out another concept is JWT (JSON Web Token), is it related to OAuth2? After further investigation, it turns out that there is no strong correlation between them, so what is JWT?

To put it simply, JWT is an authentication protocol. Its advantages are simplicity and URL security. Another advantage is that it frees the server of session access pressure and eliminates the need for session synchronization on cluster machines or multiple sub-sites.

Here is a schematic of JWT authentication

In fact, I think JWT is very similar to the traditional cookie-session mode in the browser environment. After authentication, the server generates an association between cookie and session, namely the session ID. The cookie is stored by the browser, and the session is saved by the server. When authentication is required, the session is obtained through the cookie whose key is the session ID. If the correct session data is obtained, the authentication succeeds.

In JWT authentication, JWT plays the role of cookie (browsers usually store JWT cookies). When the client needs identity authentication, it sends back to JWT. The difference lies in the server side, which does not need to obtain identity information through session, but directly extracts information from JWT. That is, JWT is not a simple token, but data that can be encoded with information (in Json format). If the server verifies that the signature matches, the data carried by the server can be used. Otherwise, the authentication fails. Because the information is encoded in the JWT, session queries are spared. The data in JWT needs to be compared to the signature to ensure that it is correct, and the key needed for the signature can only exist on the server side. The key to security is to process both JWT delivery and validation logic on the server side.

To put it simply, it is necessary to pack the session data into cookies, and then make a signature to verify the correctness of data.

Implementation method

So first of all, this is a JWT.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cB ab30RMHrHDcEfxjoYZgeFONFh7HgQ

It is the following three pieces of data through base64 after concatenation.

header.payload.signature

The following are explained separately

Header

{
    "alg" : "AES256",
    "typ" : "JWT"
}
Copy the code

Alg is used to declare which hash algorithm to use, as detailed below.

Payload

Load is the data carried, there are some officially defined standard fields, can also add their own data.

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

Where sub is the standard field, the common standard field is

  • iss: The issuer of the JWT
  • sub: The user for which the JWT is intended
  • aud: The party receiving the JWT
  • expExpires: When does it expire, in this case a Unix timestamp
  • iatA: When was it issued

Name and admin are user-defined data. You can add any content here. However, note that these data are public and sensitive information cannot be added.

One security concern with this example is that there is no expiration date, so it can be used without limit. I should add exp or IAT.

Signature

This is the security core of JWT certification. Because base64 encoding is basically equal to public, it is also easy to tamper with, how to ensure trust. That’s right there on the signature. A signature is a hash of a header, payload, and a key. Although the preceding data can be easily tampered with, it is difficult to ensure the signature is correct without knowing the signature key.

A few safety points

  1. Do not add sensitive information to load data, as Base64 can be decoded without barrier.
  2. The key must be kept well, only on the server. Because the core of security is the signature, and the core of the signature is the key.
  3. An expiration time or generation time should be added to the load. Because the server does not store state (another feature of JWT authentication), there is no way to determine its expiration date.
  4. To prevent XSS if JWT is storing cookies it is best to use Cookie plus HttpOnly attribute.

Afterword.

JWT has little to do with Oauth2 because JWT is just a token protocol and Oauth2 is a whole set of authentication logic. Perhaps because the traditional session cannot be used in the API environment, most Oauth2 uses JWT as the token of Oauth2 based on this feature. Therefore, Oauth2 and JWT have formed a difficult relationship.