Recently, JWT has been adopted in the security authentication mechanism of the project. Now, when the whole work has basically come to an end, some knowledge points will be summarized and released.
The reason is very simple, just as follows:
- In order to migrate to the microservice architecture, because the single login entry point disappears after service splitting, token is the inevitable choice.
- For the sake of scalability, using cookie + session mechanism will inevitably face the problem of application state, and will inevitably involve the replication of session. Use token to avoid this. This does not mean that there is no session at all, but at least it can be reduced to the minimum.
- For the sake of mobile terminal, token is more suitable for mobile terminal and more flexible than cookie.
- For the sake of safety, token mechanism [only when verifying request header] is naturally immune to CSRF.
What is JWT?
JWT consists of three parts: header + payload + signature. Each part is a JSON representation. The final token encodes the three parts of the string, which is separated by “.” in the middle
token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) # token is now: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
The token in the form of the above string is passed between the application and the server.
How to use JWT?
Applications that use JWT basically follow the following usage process:
- Access the login point.
- After the login service is verified, the certificate is issued and returned to the client.
- The client saves the certificate and attaches it to the request header every time it requests, indicating that it is logged in.
- After receiving the request, the server verifies the validity of the token by signing and timestamp.
- If valid, respond to the client.
The corresponding request header is as follows:
The whole process is as follows:
In general applications, after successful verification, the server may retain some additional user related information in the cookie or session to simplify the subsequent programming and avoid repeatedly reading the database.
In JWT, the same function can be realized: just put the corresponding content into the payload. In this way, the next token sent from the client can be decoded.
When verifying the effectiveness of JWT, at least the following two points will be considered:
- Is the signature correct?
- Is the token due?
The coding of the whole process is not complicated. Please refer to the link at the end of the article, which is no longer wordy.
Precautions in use
For safety reasons, pay attention to the following points:
- The signing certificate needs to be stored safely
- Do not put sensitive information in token
- Please use it in combination with SSL
If you want to save the token in the cookie [at this time, the server should verify whether there is a token in the cookie or header at the same time]
- Note that the token size exceeds the cookie limit
- Please use the only flag. If possible, use the secure flag.
- Synchronize token is used to prevent CSRF [this is because when a request is made to site B on site a, the cookie of site B will also be sent to B. If you don’t use another token to protect, you can’t know whether the JWT in the cookie belongs to subordinate a – > b or from B – > B. At present, most of the existing frameworks already support it].
- To prevent replay attacks, JTI, exp, and IAT declarations can be added
The above is a whirlwind description of JWT. For other contents, please refer to the references.
- Get Started with JSON Web Tokens
- Introduction to JSON Web Tokens
- JWT on Wikipedia
- JWT example of vert. X Web
- Where to Store your JWTs – Cookies vs HTML5 Web Storage
- Use JWT The Right Way!
- Authentication: Cookies vs JWTs and why you’re doing it wrong
- How to store a JWT token inside an HTTP only cookie?
- Cookies vs Tokens: The Definitive Guide
- Managing the JWT lifecycle
- JWT specification