Currently I have thought of a solution, but I don’t know if there is a similar mature solution.
1. User's first verification
2. Create a file named with the token value in the specified token directory.
3. Return the token to the user for saving.
4. Client: pass judgment URL200 or 404 is processed logically. Server side: Logical processing is performed by determining whether the file exists.
The security setting that comes to mind is to prohibit crawlers from crawling the directory, and monitor the number of user connections to the directory to prevent brute force cracking.
Is there any bugs or performance issues with this method?
Or is there something better than this? Good solution?
For this solution, please see my other answer: /q/10...
Although this solution is not regarded as a standard, it is a commonly used solution.
There are still some shortcomings, such as:
If the generated token is too long, you must consider whether it exceeds the GET request length limit when doing GET (because the URL length is limited), but a token that is too short cannot ensure high uniqueness and security
Of course, using token as a user token is not safe. If the token is stolen by others before the token expires, others can impersonate the user and perform operations without logging in.
If you want a safer method, it is to use the Session server to verify the user. However, the Session cross-domain issue is indeed a commonplace issue, and there is no problem with the cross-domain token. As long as the interface can be accessed, the token is requesting passed in the data. So my personal point of view is that the only choice is between security and ease of use. Of course, other verification methods can also be used, such as JWT, etc., but this method is more cumbersome (unless you don't have to reinvent the wheel).
1. The client submits information
2. The server checks the correctness of the information. If the login is illegal, the login fails
3. The server uses an algorithm to generate a token, and stores the token in a high-concurrency database such as redis, and sets the expiration time
4. The server returns the token to the client
5. The client saves the token
6. The next time the client requests, it carries the token. The server verifies the validity of the token. If it is valid, it passes, if it is invalid, the verification fails