Introduction to a new implementation mechanism for keeping mobile APP logged in

[[194514]]

Features of Mobile App

The difference between mobile APP and web login is that App does not require users to log in every time they use it, which increases ease of use. This article introduces the implementation mechanism of App to keep logged in

Currently common mechanisms:

1. Use the traditional session mechanism

Copy the mechanism of the web page and use the traditional web page's remember login mechanism. After the user enters the correct username and password, a login session is created, and a remember login token is generated and kept on the server side, and sent to the client at the same time. Each time the client starts, a new session is created by recording the login token, and the subsequent use adopts the session mechanism. The server side can use Memcache or Redis to store sessions.

Recalling this mechanism, the login token can also be set to a long validity period, such as 30 days. The login token is similar to the Refresh token of Oauth 2.0, and the Session Id in the Session mechanism is similar to the Access token. However, the Session Id in the Session mechanism will be automatically extended when it is used continuously.

The advantage of this mechanism is that it makes full use of existing knowledge, is simple and easy to use, and does not have too many new terms and concepts. The disadvantage is that it is not convenient for distributed authentication, and the Session mechanism has a small impact on performance. At the same time, it does not conform to the stateless design spirit of the Restful API.

2. Use a token mechanism with a long validity period

After the user logs in correctly, a token with a long validity period (for example, half a year) is generated and saved on the server side. It is also sent to the client. Each request from the client uses this token to verify the identity. Using https transmission encryption, the token will not be obtained in the middle, and the token saved locally cannot be accessed by other programs. For ordinary applications, this solution is also feasible.

3. Use a long-term Refresh Token and a short-term Access Token.

For solution 2, if the mobile phone hardware itself has been obtained by hackers, the long-term token may be stolen, which is a potential risk. Taking this into consideration, the Oauth 2.0 standard recommends the use of Refresh Token and Access Token. The validity period of Refresh Token is very long, and the validity period of Access Token is very short. After the user logs in, he will obtain both Refresh Token and Access Token. Normally, he will use Access Token. After the Access Token expires, he will use Refresh Token to obtain a new Access Token.

This solution is widely used, including the development of WeChat public platform.

But if you think about it carefully, this mechanism is not more secure than Solution 2 (using a long-term token). If a hacker can obtain the Access Token, it is not difficult to obtain the Refresh Token. Using two tokens only adds a little trouble to the hacker.

Once a hacker obtains the Refresh Token, he can repeatedly refresh the Access Token.

This paper introduces a new mechanism

Token exchange mechanism

This mechanism uses only a short-term token, such as 1 day. After the user logs in, the token is sent to the client. The user uses this token to authenticate his identity every time he requests. After the token expires, it can be exchanged for a new token. An expired token can only be exchanged for a new token. This is the key. If the token is stolen, the hacker needs to continue to use it and exchange it for a new token. Once the server finds that an old token has been tried to be exchanged for a new token many times, it means there is an abnormality. At this time, the user is forced to log in again. The old token can be exchanged for a new one, not necessarily after it expires. It can be exchanged for a new one when the application is started. This depends on the specific situation.

The validity period of this token can be adjusted for different applications. Take the design of China Merchants Bank's app as an example:

1. Use https encryption to ensure transmission security.
2. The validity period of the token is set to 15 minutes. Every 15 minutes, the old token is exchanged for a new one. Under normal circumstances, this exchange is invisible to users. Once two people try to exchange the old token for the new one, both will be blocked and need to log in again.
3. For key operations such as changing passwords and transferring payments, users are required to enter their passwords. This is foolproof.

To repeat, when designing a security mechanism, you must use https. Without https, most security designs are useless.

Appendix: Token Introduction

Token is translated into Chinese as token, which is the basis for identifying identity. There are usually two types of tokens:

A token without content

This token is a unique hash value. To know who owns this token, you need to query a central server. In the central server, user data may be stored in files, databases, or Redis. There is a session id in the cookie of the session mechanism, which is essentially a token of this type.

2. Token containing content

This kind of token, like an ID card, contains public user information and uses a signature mechanism to ensure that the token cannot be forged. The most common token of this type is: Json web token (JWT). The advantage of this token is that it does not need to be queried from a central server, which is very useful for distributed systems. For example, after a user logs in, they want to watch a video or download a file. Video and file resources all require user identity verification. Video and file resources are on different servers or even provided by different companies. In this case, JWT with distributed verification is very useful. This kind of distributed verification token usually cannot be cancelled after it is issued, and can only be expired. In order to ensure security, using short-term JWT and replacing the old token with the new one as mentioned above is very effective.

The token exchange mechanism mentioned in this article is applicable to both of the above two tokens. A token is a string of information. Even if there are 10,000 copies, there is no difference between them. With the exchange mechanism, the token is a bit like a physical object. If it has been exchanged, it cannot be exchanged again. No matter how many copies there are, only one can be exchanged for a new token. When two people take the same token to exchange for a new one, we cannot judge which one is legal and which one is illegal. Well, both of them log in again to confirm their identities.

renew

• For common applications, the validity period is set to 24 hours. You can change the token every time you start the application. It doesn't need to be too complicated.
• For applications like online banking, you can change the token when starting up, and use a timer to change the token every 15 minutes.