Original link: https://editor.leonh.space/2022/oauth-token/
This article is some thoughts on the OAuth 2 token update strategy recently. The title of the article is “discussion”, because I am not sure whether these ideas are the so-called best practices. Readers are welcome to leave a message for discussion.
In the various flows of OAuth 2, two tokens, access token and refresh token, will be obtained in the end, as tokens representing users to access services and resources. The characteristics of these two tokens are as follows:
Access Token
- Access services on behalf of users.
- The validity period is short.
- Because the validity period is short, there is no need to worry about being stolen, and it can generally be stored in cookies, local storage, session storage, memory, etc.
– Refresh Token
- Used to update access token and refresh token.
- It cannot be used to access services other than to update the token.
- Long validity period.
- Because of the long validity period, it needs to be stored properly. It is generally recommended to store it in a cookie with the HttpOnly attribute, but some people still put it in local storage.
Token update
Because the validity period of the access token is short, in order to create a good user experience, do not allow users to log in frequently, we must use the refresh token to update the token on the client app. Generally speaking, when the token is updated, not only a new access token will be obtained, but also Get a new refresh token.
Based on the preceding conditions, we can envisage an update strategy for the first edition.
Update Policy Version 1
described as follows:
- The user clicks a link or presses a button.
- Enter the blue area and check the validity period of the access token. If everything is in order, go directly to the green square and take the access token to ask the server for content or perform certain transactions.
- If the client does not have an access token at all, enter the yellow area and exchange the refresh token for a new pair of access token and refresh token.
- If the client has an access token, but it has expired, then use the refresh token to exchange for a new pair.
- If the refresh token fails, it means that the refresh token is also expired, so the user has to log in again.
- If the client knows that the refresh token has expired, it also asks the user to log in again.
In this seemingly chaotic but not too chaotic strategy, the client app needs to manage the status of the access token and refresh token, that is, to know their validity period, but remember, the refresh token is an HttpOnly cookie, which cannot be read by JS .
Besides, whether I know the validity of the refresh token or not, I have to go to the “Refresh token” step. The only difference is that I take the initiative to find that the refresh token has expired and be directed to the login page, or go directly to the “Refresh token” box, Failed to redirect to login page. From the user’s point of view, he can’t feel the difference between the two paths. Everything only happens in the dialogue of the host and client programs. Based on the above, we can remove the entire yellow area:
So it was simplified to the second edition.
Update Policy Second Edition
The second version is much cleaner and reduces the logic of the client app. You don’t need to worry about whether there is a refresh token or not, just whether the access token exists or has expired.
If it does not exist or expires, go to the “Refresh token” box and run it. If it succeeds, it will succeed, and if it fails, it will take the user to log in again.
Similarly, if there is a problem with the blue square, it will go to “Refresh token”, why not even save the blue square:
So we have the third edition.
Update Strategy 3rd Edition
The logic of the third edition is indistinguishable. There is no need for any logic to judge the existence and validity of the token. It does not care about the status. It only has no brains to update. If it is wrong, the user will be caught to log in again.
The third version is stupid enough and smart enough, but it may not be feasible. The small icon on the upper right of the red square indicates that they are going to go online and update without a brain, which means that the server must respond. If there are many people on the client app, it is equivalent to the right When the server launches a DDoS attack, either the server is bombed, or the user is blocked.
In this way, the interaction between the host and the client is very expensive. For the server, the generation efficiency of the token should be considered. The mainstream choice of the token is JWT. JWT is calculated based on Base64 and HS256, which means that the server needs high Efficient Base64 and HS256 decoding algorithm, each language has a variety of Base64, HS256 codecs, you can also use APM to monitor the load of the refresh token endpoint, and then optimize as needed.
The Access Token Paradox
The same field adds access token paradox.
As mentioned earlier, the accsss token has a short validity period and is more able to withstand the risk of outflow. For example, an access token with a validity period of only one minute, even if it flows out, most of them don’t panic because it expires after one minute. On the contrary, another one has a short validity period. A day’s worth of access tokens flow out, then we might get nervous.
Based on the above settings, we can conclude that the shorter the validity period, the greater the sense of security. Therefore, if we want to have an infinite sense of security, the validity period must be infinitely short, as short as close to zero, but this will lose its function. Maybe we can use the “times” point of view to look at the validity period, from the original time validity period to the times validity period, which is the so-called one-time token, but the access token also has a stateless feature, how can it be managed without Its state also allows it to be used only once, and the answer may be blockchain-like technology.
This article is reprinted from: https://editor.leonh.space/2022/oauth-token/
This site is for inclusion only, and the copyright belongs to the original author.