Introduction of a new implementation mechanism for mobile APP login

Features of mobile APP

Mobile APP and web login is a different point, App does not require users to log in every time, increase the ease of use, this article describes App, landing is the implementation mechanism

Current common mechanisms:

One, using the traditional session mechanism session

The mechanism of “copied by traditional web login mechanism. Remember
users enter the correct user name and password, create the login session, to generate a token landing on the server to keep in mind at the same time, also send a client.
client startup, the token log records the new session, the subsequent use will take session the mechanism of
. The server can use Memcache or Redis to store the session.

Remember this mechanism, which remember landing token, also can set a long effective period, such as 30 days,
remember landing token similar to the Oauth 2 Refresh token, Session Session Id Access mechanism similar to token.
but Session Session in the Id mechanism of continuous use, will be automatically extended.

This mechanism is good to make full use of existing knowledge, easy to use, not too many new concepts of
is inconvenient to distributed authentication, and Session mechanism is a little effect on performance, and does not meet the design spirit of Restful API stateless.

Two use a Token mechanism with a long validity

User right after landing, generate a valid long Token (such as half), stored in the server to the client at the same time, each client request to verify the identity of the Token.
uses HTTPS encryption, Token will not be available to save midway, also can’t visit in the local Token
other programs. The general application, this scheme is also possible.

Three use a long term Refresh Token and a short Access Token.

In scheme two, if the mobile phone hardware itself is acquired by hackers, the term Token may be stolen, there is a potential risk of
. Considering this, the standard of Oauth 2 Token and Access Token. recommended Refresh
Refresh Token Access Token for a long period of validity period is very short.
user login, and access to Refresh Token Access and Token, usually with Access Token, Access Token Refresh Token expired after the acquisition of new Access Token.

This scheme is widely used, including the WeChat public platform also use the mechanism of
but careful thought, this mechanism is not than scheme two (using a long token
) security, hackers can get Access if Token gets Refresh Token is not difficult, the two token is only increased a little trouble to hackers
. Once the hackers gained access to Refresh Token, you can repeatedly refresh the Access Token

A new mechanism is introduced in this paper

Token the mechanism of replacing old ones with new ones

This mechanism uses only a short 1 days.
Token, for example, the user login, the user Token to the client, every time a request is using the Token authentication, Token expired by the token for the new Token, an expired Token only in exchange for a new Token, which is the key. If Token stolen, hackers also need to continue to use continuous for new Token server, once found, an old Token repeatedly tried to exchange for the new Token, said there is an exception. Then force the user to log in again.

This Token is valid, for different applications can be adjusted to
. The design of China Merchants Bank as an example: app
1, the use of HTTPS encryption to ensure the security of
transmission. 2, the duration of the Token Token is set to 15 minutes, every 15 minutes, TM for the new Token. under normal circumstances, the TM are not visible to the user, but two people trying to trade in, two people need to stop, landing again.
3, to modify the password and transfer payment key operation that requires the user to enter a password.
this is no danger of anything going wrong.

Repeat, when designing security mechanisms, be sure to use HTTPS, without HTTPS, and most security designs are useless

Attached: Token brief introduction

Token Chinese translation is token, identification of identity based.
usually token two:

A content free token

The token is a unique hash value, to know who is this token to a central server query.
in the center server, user data may be stored in a file or database or Redis.
has a session ID mechanism in session Cookie, the essence is a this class token.

Token containing content

The token, like an identity card, including public user information, through the signature mechanism to ensure that token cannot be forged. The most common
this kind of token is: Json web token (JWT
token) this advantage is not to the center server query for distributed system is very useful, such as user login, to see video, to download the file.
video file resources are required to verify the identity of users, video, file resources in different servers, and even provided by different companies, which can be distributed to verify that the JWT is very useful. It can verify the Token
distributed usually issued can not be canceled, only its own expired
. Then in order to ensure safety, the use of short-term JWT, plus the token TM, is very effective.

The Token replacement mechanism is applicable to the above two token.
Token is a string of information, even if the ten thousand copies of each other, there is no difference between
, with the replacement of old mechanism, Token is a bit like a real, has changed since it can’t be changed again. No matter how many copies, there is only one for a new Token
when the two person has with the same token to new ones, we can not determine what is legal, which is illegal, well, two people landed again to confirm the identity.