If I get the api_token,user_token and so on through the grab bag and so on all parameters and header, that in a short period of time, I directly with the parameters I obtained, validation rules passed, I can not use this interface? The only way a person can think of is to shorten the time of token verification. Don't know how the great gods solved this problem?
Reply content:
Token is the role of the AH ... is not the token that you can use to design. The main purpose of the design token is not to want to save the user's user name and password for a long time, so the conversion into a random code, the code itself has the role of replacing the user name and password, so once leaked, the natural consequences will be very serious.
Now the security level of the API is generally only use HTTPS, so from the middle of the path is not able to catch the content of the connection, so the token will not be leaked to others. As for the two, a user, one is your own server, this token is supposed to be shared on both sides of the content bar.
Another design used to be using Api_key and Secret_key two values, where api_key is transmitted in plaintext, and Secret_key does not appear in HTTP plaintext, but as part of the MD5 hash. In general, the entire URL parameters are normalized (by parameter name, uniform conversion to lowercase, URL encoding correctly), and then add Secret_key, Calculate MD5, and then the MD5 as an additional sig parameter passed through HTTP, so that even if the middle caught packet, can only see Api_key , you cannot freely use this interface without seeing the Secret_key. But this design has a weakness for replay, and although I am not free to regroup parameters, I can reuse the previously caught parameters, which is still unsafe, and lacks a means of distributing secret_key securely to the terminal. So in fact, it is more effective to use HTTPS directly.
As a reference we look at the design of OAuth 2.0, OAuth 2.0 is a third-party login, involving the user, authentication center, third-party application three aspects of the relationship, it encountered more complex problems, we can see how it gets tokens, and to prevent tokens from being leaked to a party that should not be disclosed:
- The OAuth server knows the same api_key as the third-party server, Secret_key
- Users and third-party servers know Api_key (usually carried by a third-party app or web page)
- The user knows the same user name password as the OAuth server, and the third-party app does not know
- When a user requests a third-party login, use Api_key to invoke the OAuth server login interface (typically guided by a third-party app), use the OAuth server's page to enter the username password, and the OAuth server returns Auth_code, which can be considered a temporary token. This step must use HTTPS to ensure that the user name and password are not stolen.
- The user uses Auth_code to invoke the interface of a third-party application (usually done automatically by the callback mechanism), which can use HTTP, so Auth_code may leak
- Third-party apps use Auth_code + Api_key + Secret_key to call the OAuth server's second-step login interface to get Access_token, which is the official token. Although the Auth_code may be compromised, the auth_code cannot be used in exchange for tokens because Secret_key attackers are unable to obtain them. This step must use HTTPS to ensure that the Secret_key does not leak.
At this point, the third-party application has successfully acquired the Access_token, and this access_token is only shared between the OAuth server and the third-party server and is not disclosed to third parties, including users. It can be seen that this process relies primarily on HTTPS encryption features to ensure that the most important data (user name, password, secret_key) is not compromised. In addition, tokens at different security levels should have different time-outs, such as the Auth_code timeout is very short, and the Access_token has a relatively long time-out.
Interface with HTTPS, grab packets are garbled. But there's a way to disguise the middleman? Thank you for your invitation.
The most extreme approach:
Each token is valid only once ...
Of course, this involves a lot of read and write operations.
So ... Generally do not do so ... Random number plus token plus time stamp for MD5 signature to pass the signature and the random number time stamp to the server is not such, in the server side first to judge the session, through before it will enter into our written token verification. 1:https;
2: Authentication module independent, token into the session, re-check, this and the design of the certification is related;
3: High frequency replacement token, the specific view of business importance;
The above personal views may not be very rigorous
