Token multi-platform identity authentication architecture design ideas

Overview

In the information system with the account system, the identification of the identity is very important.

With the advent of the mobile Internet era, there are more and more types of clients, and a pattern of one server and N clients has gradually emerged.

Different clients have produced different user usage scenarios, these scenarios:

• There are different environmental security threats
• Different session life cycles
• Different user authority control systems
• Different levels of interface calling methods

In summary, their identity authentication methods also have certain differences.

This article will use a certain amount of space to analyze and sort out these scenarios.

scenes to be used

The following are some common usage scenarios in IT services:

• Users log in to the system on the web browser and use system services
• Users log in to the system on the mobile phone (Android/iOS) and use system services
• Users log in to the system using an open interface and call system services
• The user authorizes the mobile phone to log in by scanning the code of the mobile phone when the PC is processing the login state (used less)
• The user processes the login status on the mobile phone and authorizes the PC to log in by scanning the code on the mobile phone (more common)

Through the segmentation of the scene, the following different authentication token categories are obtained:

• Original account password category
• user name and password
• API application ID/KEY
• Session ID category
• Browser token
• Mobile token
• API application token
• Interface call category
• Interface access token
• Identity authorization category
• Token for mutual authorization between PC and mobile terminal

Type of token

The tokens in different scenarios are compared in the following dimensions:

Natural attribute comparison

• The cost
• The account password requires the user to open the page and then type it one by one
• The QR code requires the user to take out the phone to scan the code
• The inconvenience caused when this authentication method is used. such as:
• Change cost
• When the user name and password change, the user needs to remember and retype the new password
• When the API application ID/KEY changes, the third-party application needs to be modified and deployed in the code again
• When the authorized QR code changes, the user needs to reopen the mobile app to scan the code
• In this authentication method, when the token changes, the cost of the corresponding changes that the user needs to make:
• Environmental risk
• Risk of being peeped
• Risk of being caught
• Risk of being forged

Controllable attribute comparison

• usage frequency
• Frequency of transmission on the network
• Effective time
• The lifetime of this token from creation to end

The ultimate goal: safety and impact.

• Security and privacy are mainly reflected in:
• Token is not easy to be stolen and misappropriated (by controlling the transmission frequency)
• Even if the token is stolen, the impact is controllable (by controlling the effective time)

Regarding privacy and the consequences of privacy breaches, there are the following basic conclusions:

• High exposure frequency is easy to be intercepted
• The long-lived ones will have a more serious and far-reaching impact after being intercepted

Observe the following principles:

• Don't change tokens with high cost easily
• The token that is not easily changed should reduce the exposure frequency (the number of network transmissions)
• The life cycle of the token with high exposure frequency should be as short as possible

After adjusting the inherent characteristics and controllable attributes of various tokens, and quantifying each indicator (1~5 points), we can get the following comparison table:

Note: user_name/passwd and app_id/app_key are equivalent effects

Hierarchical relationship of token

With reference to the comparison table in the previous section, these tokens for different purposes can be easily layered, which can be divided into 4 layers:

• Cryptographic layer
• The most traditional digital identity authentication method agreed between the user and the system
• Session layer
• Session authentication for the session life cycle after user login
• Call layer
• User's call authentication to the application program interface during the session
• Application layer
• Some scenes or identity authentication applications after the user has obtained the interface access and invocation permission

The layered diagram of token is as follows:

In a multi-client information system, the internal connection between the generation of these tokens and the application is as follows:

• The user enters the user name and user password for one-time authentication
• Generate session tokens with different life cycles in different terminals
• The client session token is exchanged from the server to access the token from an interface with a short life cycle but frequent exposure.
• Session token can be generated and refreshed to extend the lifetime of access_token
• access_token can generate the token of the QR code with the shortest life cycle for authorization

Using the above architecture has the following advantages:

• Good unity. It can solve the normalization problem of the life cycle of authentication tokens on different platforms
• Good decoupling. The core interface calls the server's authentication access_token to complete independent implementation and deployment
• Good hierarchy. Different platforms can have completely different user authority control systems. This control can be solved by each platform in the session layer.

account password

The broad account/password has the following presentation methods:

• Traditional registered username and password
• App_id/app_key of the application

Their characteristics are as follows:

• Will have a special meaning
• For example: the user himself will set a meaningful account and password for the convenience of memory.
• Modify infrequently
• The account password has a special meaning to the user, and it is generally unwilling to modify it without special circumstances. The app_id/app_key will be written in the application, and the modification will mean the cost of re-release and online
• Once the leak has a far-reaching impact
• Because of the infrequent modification, as long as the user's network identity is leaked, it will always exist as long as the identity theft is not detected.

Therefore, in the authentication system, the chance of transmission should be minimized to avoid leakage.

Client session token

Function: Acting as a session, different clients have different life cycles.

Steps for usage:

• The user uses the account password in exchange for the session token
• Tokens on different platforms have different characteristics.

Web platform has a short life cycle

• main reason
• It is more convenient to use the keyboard to input on the PC
• Since the web login environment is generally likely to be a public environment, the risk of being stolen by others is relatively high
• Environmental safety
• Input convenience

The mobile terminal has a long life cycle

• main reason
• Using a finger on a small screen on the mobile terminal has a poor touch input experience and high input cost
• The mobile platform is an extremely private platform for individual users, and it has little chance for people to contact
• Environmental safety
• Input convenience

access_token

Function: Credentials for server application api interface access and call.

Steps for usage:

• Use a session token with a longer life cycle in exchange for this interface access token.
• The exposure frequency is directly related to the interface call frequency, which is a certificate for high-frequency use. In order to take care of privacy, try to reduce its life cycle, even if it is intercepted, it will not produce serious consequences.

Note: An access_token is added under the client token, mainly to enable client tokens with different life cycles to have a unified authentication method when they finally call the api.

pam_token

Function: The original serial number (Pc Auth Mobile) of the QR code generated by the PC that has logged in and authenticated.

The main steps are as follows:

• The user on the PC has been authenticated and logged in to the system
• The PC side generates a set of pam_token associated with this user
• The PC side uses this pam_token link to generate a QR code
• After scanning the code on the mobile terminal, request the server and associate it with the user information
• The mobile terminal obtains refresh_token (long-term session)
• Get access_token according to refresh_token
• Complete normal interface call work

Remarks:

• The lifetime is 2 minutes, and it will expire after 2 minutes.
• When not in use, it changes every 1 minute
• After being used, delete it immediately
• This authentication mode is generally not used

map_token

Function: Scan the code to authenticate the PC-side system by the logged-in mobile app, and complete the login of the PC-side system (Mobile Auth Pc).

The main steps:

• The mobile terminal completes the authentication of the user identity and logs in to the app
• Unlogged PC generates anonymous map_token
• After scanning the code on the mobile terminal, generate map_token in the db and associate it with the user (complete the signature)
• db also generates web_token for this user
• The PC side always uses map_token as a parameter to find the web_token of this named user
• The PC side obtains the access_token according to the web_token
• Subsequent normal call interface call work

Remarks:

• The lifetime is 2 minutes, and it will expire after 2 minutes.
• When not in use, it changes every 1 minute
• After being used, delete it immediately

Summary and outlook

The token-based identity authentication system designed in this article mainly solves the following problems:

• Token classification problem
• Token privacy parameter setting problem
• Token usage scenario problem
• Hierarchical transformation of tokens in different life cycles

The design method mentioned in this article can be applied to but not limited to the following scenarios in the application layer:

• User login
• Issuance of time-limited coupons
• Time-limited invitation code issuance
• Time-effective QR code authorization
• Time-sensitive mobile phone/email verification code
• Multiple different platforms call the same set of API interfaces
• Multiple platforms use the same identity authentication center

As for more usage scenarios, you need to explore them.

Author: Hamo
Original: cnblogs.com/beer/p/6029861.html