Shulou(Shulou.com)06/03 Report--

Not long ago, I mentioned Token-based authentication in the front-end separation practice, and now let's go a little further.

Usually, when we talk about a technology, we start with a problem. So the first question:

Why use Token?

And it's easy to answer this question-because it can solve the problem!

What problems can be solved?

Token is completely managed by the application, so it can avoid the same origin policy Token and avoid CSRF * Token can be stateless and can be shared among multiple services.

Token is generated on the server side. If the front end requests authentication from the server using the user name / password, and the server authentication is successful, the Token will be returned to the front end on the server side. The front end can take a Token to prove its legal status with each request. If the Token is persisted on the server side (such as storing it in a database), it is a permanent identity token.

So another question arises: do you need to set an expiration date for Token?

Do you need to set the validity period?

For this problem, we might as well look at two examples first. One example is the login password, which is generally required to change the password regularly to prevent disclosure, so the password is valid; another example is the security certificate. SSL security certificates are valid, the purpose is to solve the problem of revocation, for details of this question, let's take a look at Zhihu's answer. Therefore, no matter from the perspective of security, or from the perspective of revocation, Token needs to set the period of validity.

So how long is the validity period?

It can only be said that, according to the security needs of the system, it should be as short as possible, but not ridiculously short-imagine the auto-shutdown time of the phone, if it is set to 10 seconds without operation, and you need to enter a password to light up again, will you go crazy? If you don't think so, try it yourself, set it to the shortest time you can set, and stick to it for a week (don't rule out the possibility that some people adapt to this time, after all, mobile phone manufacturers also have user experience research).

Then a new problem arises, if the Token expires in the course of normal operation, the user is required to log in again. Isn't the user experience terrible?

In order to solve the problem that users can not feel that Token is invalid during operation, one solution is to save the Token state on the server side, and the user will automatically refresh (postpone) the expiration time of the Token each time they operate-this is the strategy that Session uses to maintain the user login status. However, there is still a problem. In the case of front-end separation and single-page App, there may be many requests per second, and it will be very expensive to refresh the expiration time each time. If the expiration time of Token is persisted to a database or file, the cost is even greater. So usually in order to improve efficiency and reduce consumption, the expiration of Token will be saved in cache or memory.

There is another option, using Refresh Token, which avoids frequent read and write operations. In this solution, the server does not need to refresh the expiration time of the Token. Once the Token expires, it will feed back to the front end, and the front end uses Refresh Token to apply for a new Token to continue to use. In this scheme, the server only needs to check the validity of the Token when the client requests to update the Refresh Token, which greatly reduces the operation of updating the validity period and avoids frequent reading and writing. Of course, Refresh Token also has a validity period, but this validity period can be a little longer, for example, in days.

Time sequence diagram representation

The sequence diagram for using Token and Refresh Token is as follows:

1) Log in

2) Business request

3) Token expires, refresh Token

The timing diagram above does not mention what to do when Refresh Token expires. But obviously, now that Refresh Token has expired, it's time to ask the user to log in again.

Of course, you can make this mechanism a little more complex, for example, Refresh Token updates its expiration time every time it is used, until it has exceeded a very long period of time compared to its creation time (such as three months), which is tantamount to allowing Refresh Token to renew automatically for quite a long time.

So far, Token has been stateful, that is, relevant properties need to be saved and recorded on the server side. What about the statelessness we talked about? how can it be realized?

Stateless Token

If we attach all the state information to the Token, the server can not save it. However, the server still needs to verify that the Token is valid. However, as long as the server can confirm that it is a self-signed Token and its information has not been altered, then the Token can be considered valid-a "signature" can guarantee this. It is often said that signatures are signed by one party and verified by the other party, so asymmetric encryption algorithm should be used. But here, the signing and verification are on the same side, so the symmetric encryption algorithm can meet the requirements, while the symmetric algorithm is much faster than the asymmetric algorithm (up to tens of times the gap). To take it a step further, symmetric encryption algorithms have the ability to restore encrypted content in addition to encryption, which is not necessary when signing Token-since there is no need for decryption, the digest (hash) algorithm is faster. You can specify the hash algorithm for the password, which is naturally HMAC.

With all that has been said above, do you still need to do it yourself? No, no, no! JWT has defined detailed specifications and has several implementations in various languages.

However, when using stateless Token, there will be some changes on the server side. Although the server side does not save the valid Token, it needs to save the unexpired but logged-out Token. If a Token is actively logged out by the user before it expires, the server needs to save the logged-out Token so that it can be invalidated the next time it receives the Token that is still valid. Do you feel a little depressed?

When the front end is controllable (for example, the front end and the server are in the same project team), it can be negotiated that as soon as the front end logs out successfully, the Token and Refresh Token saved locally (such as in memory, LocalStorage, etc.) will be lost. Based on this convention, the server can assume that the Token received must not be logged out (because the front end will no longer be used after logout).

If the front end is out of control, the above assumption can still be made, but in this case, the validity of the Token needs to be shortened as much as possible, and the Refresh Token must be invalidated if the user logs out voluntarily. There is a certain security hole in this operation, because the user will think that it has been logged out, but in fact it has not been logged out for a short period of time. If this loophole does not cause any loss in the application design, then it is feasible to adopt this strategy.

There are two things to be aware of when using stateless Token:

Refresh Token is valid for a long time, so it should be stateful on the server side to enhance security and ensure that users can log out. Secondary authentication should be considered to enhance the security of sensitive operations.

At this point, the topic of Token seems to be almost done-but no, what about the integration of authentication services and business services, what if it is a separation?

Separate authentication service

When Token is stateless, single sign-on becomes easier. The front end gets a valid Token and it can be authenticated on any service of the same system-as long as they use the same key and algorithm to authenticate the validity of the Token. Just like this:

Of course, if the Token expires, the front end still needs to go to the authentication service to update Token:

It can be seen that although authentication and business are separated, there is not much difference in practice. Of course, this is based on the premise that the authentication server trusts the business server, because the key generated by the authentication server for Token is the same as the key and algorithm for the business server to authenticate Token. In other words, the business server can also create a valid Token.

What if the business server cannot be trusted?

Untrusted business server

When you encounter an untrusted business server, it is easy to think of a way to use a different key. The authentication server uses key 1 to sign, and the business server uses key 2 to verify-this is a typical application scenario for asymmetric encryption signatures. The authentication server uses the private key to sign the Token and the public key. The business server that trusts this authentication server holds the public key to verify the signature. Fortunately, JWT can sign not only with HMAC, but also with RSA, an asymmetric encryption algorithm.

However, when business servers are no longer trusted, it is not secure for users to use the same Token among multiple business servers. Because any server that gets the Token can impersonate the user to another server to handle business. Tragedies can happen at any time.

In order to prevent this from happening, you need to record the information of the business server using the Token in the Token when the authentication server generates the Token, so that when another business server gets the Token and finds that it is not the Token that it should verify, you can directly reject it.

Now, authentication servers do not trust business servers, and business servers do not trust each other, but the front end trusts these servers-- if the front end does not trust them, it will not use Token to request authentication. So why trust? It may be because these are service systems made up of several services provided by the same company or in the same project.

However, front-end trust does not represent user trust. If Token does not carry user privacy (such as names), then users will not care about trust issues. But if Token contains user privacy, users have to care about trust. At this time, authentication services have to be more verbose. When users request Token, ask, "do you really want to authorize so-and-so business services?" And this "so-and-so", how do users know if it is really "so-and-so"? Of course, users do not know, even authentication services do not know, because the public key has been made public, any business can declare itself as "so-and-so".

In order to gain the trust of users, authentication services have to help users to identify business services. Therefore, the authentication server decides not to disclose the public key, but requires the business service to apply for registration and pass the audit first. Only the audited business server can get the public key created for it by the authentication service for its use only. If the business service leaks the public key, the risk shall be borne by the business service. Now the authentication service can clearly tell users what the "so-and-so" service is. If the user still does not trust enough, the authentication service can even ask, so-and-so business service needs to request A, B, C three items of personal data, of which An is necessary, otherwise it does not work, will authorization be allowed? If you authorize it, I will encrypt some of the data you authorized and put it in Token.

With so much nonsense, is there any deja vu? By the way, this is similar to the authentication process of open API. The development type API mostly uses the OAuth authentication, but the discussion resources about OAuth are very rich, so we will not delve into it here.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.