Token-based multi-platform identity authentication price design

1 Overview

In an information system with an account system, identification of 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 generate different user usage scenarios, these scenarios:

1. There are different environmental security threats
2. Different session lifetimes
3. Different user permission control systems
4. Interface calling methods at different levels

To sum up, there are some differences in their identity authentication methods.

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

2 usage scenarios

Here are some common usage scenarios in IT services:

1. Users log in to the system on the web browser side and use system services
2. The user logs in to the system on the mobile phone (Android/iOS) and uses system services
3. Users log in to the system using the open interface and call system services
4. When the user processes the login status on the PC, the mobile phone scans the code to authorize the mobile phone to log in (it is rarely used)
5. 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 subdivision of the scene, the following different authentication token categories are obtained:

1. Original account password category

   • user name and password
   • API application ID/KEY

2. session id category

   • browser-side token
   • mobile token
   • API application token

3. Interface call category

   • Interface access token

4. Identity authorization category

   • Token for mutual authorization between PC and mobile terminal

3 categories of tokens

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

Natural Properties Comparison:

1. The cost

   The inconvenience caused by the use of this authentication method. for example:

   • The account password requires the user to open the page and type one by one
   • The QR code requires the user to take out the mobile phone to scan the code

2. cost of change

   In this authentication method, when the token changes, the cost of the corresponding change that the user needs to make:

   • When the username and password are changed, the user needs to additionally memorize and retype the new password
   • When the API application ID/KEY changes, the third-party application needs to be re-modified and deployed in the code
   • When the authorized QR code changes, the user needs to reopen the mobile app to scan the code

3. environmental risk

   • risk of being peeped
   • Risk of being caught
   • risk of being counterfeited

Adjustable Properties Comparison:

1. usage frequency

   • frequency of transmission over the network

2. Effective time

   • The lifetime of this token from creation to termination

The ultimate goal: safety and impact.

Security and privacy are mainly reflected in:

• The token is not easy to be stolen and stolen (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:

1. High exposure frequency is easy to be intercepted
2. Long-lived ones have more serious and far-reaching effects after being intercepted

Adhere to the following principles:

1. Tokens with high change costs should not be easily changed
2. Tokens that do not change easily should reduce the exposure frequency (the number of network transmissions)
3. The life cycle of tokens with high exposure frequency should be as short as possible

After adjusting the inherent characteristics and controllable attributes of various tokens, each index is quantitatively scored (1 to 5 points), and we can get the following comparison table:

Remark:

• user_name/passwd and app_id/app_key are equivalent

4 Hierarchical relationship of tokens

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

1. cryptographic layer

   The most traditional digital identity authentication method agreed between users and systems

2. session layer

   Session authentication for session lifecycle after user login

3. call layer

   User authentication of API calls during a session

4. application layer

   Some scenarios or authentication applications after the user obtains the interface access call permission

The hierarchical diagram of tokens is as follows:

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

1. User enters user name and user password for one-time authentication
2. Generate session tokens with different life cycles in different terminals
3. The client session token exchanges the access token from the server with a short life cycle but frequently exposed interface
4. Session tokens can be generated and refreshed to extend the lifetime of access_token
5. access_token can generate a QR code token with the shortest lifetime for authorization

Using the above architecture has the following benefits:

1. good uniformity. It can solve the normalization problem of the life cycle of authentication tokens on different platforms
2. Good decoupling. The core interface calls the server's authentication access_token to complete independent implementation and deployment
3. Good hierarchy. Different platforms can have completely different user permission control systems, and this control can be solved by each platform in the session layer

4.1 Account password

The generalized account/password has the following presentation methods:

1. Traditional registered username and password
2. app_id/app_key of the application

Their characteristics are as follows:

1. will have special meaning

   For example, for the convenience of memory, the user will set a certain account and password with a certain meaning.

2. Modified infrequently

   Account passwords have special meanings to users, and generally they are not willing to modify them without special circumstances. The app_id/app_key will be written in the application, and the modification will mean the cost of re-publishing and going online.

3. Once the leak is far-reaching

   Because of the infrequent modification, as long as the disclosure is basically equivalent to the disclosure of the user's network identity, and as long as the identity theft is not detected, this kind of identity theft will always exist.

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

4.2 Client session token

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

Steps for usage:

1. The user uses the account password in exchange for the session token

The tokens of different platforms have different characteristics.

Web platform has a short life cycle

main reason:

1. environmental safety

   Since the web login environment is generally likely to be a public environment, the risk of being stolen by others is relatively high.

2. input convenience

   It is easier to use keyboard input on PC

Mobile terminal has a long life cycle

main reason:

1. environmental safety

   The mobile platform is an extremely private platform for individual users, and there is little chance for people to contact it

2. input convenience

   Using a finger on a mobile terminal to touch input on a small screen has poor experience and high input cost

4.3   access_token

Function: Credentials for accessing and calling the API interface of the server application.

Steps for usage:

1. Use a session token with a longer lifetime in exchange for this interface access token.

Its exposure frequency is directly related to the frequency of interface calls, and is a credential for high-frequency use. In order to take care of privacy and minimize its life cycle, even if it is intercepted, it will not have serious consequences.

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

4.4   pam_token

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

The main steps are as follows:

1. The user on the PC has completed the authentication and logged in to the system
2. The PC side generates a set of pam_token associated with this user
3. The PC side generates a QR code from the use link of pam_token
4. After the mobile terminal scans the code, it requests the server and associates it with the user information
5. The mobile terminal gets refresh_token (long-term session)
6. Get access_token according to refresh_token
7. Complete the normal interface call work

Remark:

• The lifetime is 2 minutes, and it expires and deletes after 2 minutes
• Changes every 1 minute when not in use
• Delete immediately after use
• This authentication mode is generally not used

4.5   map_token

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

The main steps:

1. The mobile terminal completes the authentication of the user's identity and logs in to the app
2. An anonymous map_token is generated by an unlogged PC
3. After the mobile terminal scans the code, the map_token is generated in the db and associated with the user (signature is completed)
4. db also generates web_token for this user
5. The PC side has always used map_token as a parameter to find the web_token of this named user
6. The PC side obtains access_token according to web_token
7. Subsequent normal call interface calls work

Remark:

• The lifetime is 2 minutes, and it expires and deletes after 2 minutes
• Changes every 1 minute when not in use
• Delete immediately after use

5 Summary and Outlook

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

1. Token classification problem
2. Token privacy parameter setting problem
3. Token usage scenarios
4. Token Hierarchical Transformation Relationships with 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:

1. User login
2. Time-limited coupons issued
3. Time-limited invitation codes are issued
4. Time-effective QR code authorization
5. Time-limited mobile phone/email verification code
6. Multiple different platforms call the same set of API interfaces
7. Multiple platforms use the same authentication center

As for more usage scenarios, we need to explore.

How to technically realize the life cycle of different tokens will be introduced in subsequent articles, so stay tuned.