Official account: Java Xiaokaxiu, website: Javaxks.com

By Harmer, source: cnblogs.com/beer/p/6029…

1, an overview of the

Identification is very important in information systems with account systems.

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

Different clients generate different user usage scenarios, which are:

  • There are different environmental security threats
  • Different session life cycles
  • Different user authority control systems
  • How interfaces are invoked at different levels

To sum up, their identity authentication methods also have certain differences.

This paper will spend a certain amount of time to analyze and sort out these scenarios.

2. Application scenarios

Here are some common usage scenarios in IT services:

  • A user logs in to the system from a Web browser to use system services
  • Users log in to the system on a mobile phone (Android or iOS) to use system services
  • Users log in to the system using open interfaces and invoke system services
  • The user authorizes the mobile login by scanning the phone code when the PC processes the login status (rarely used)
  • The user authorizes PC to log in by scanning code on the mobile phone in the login state (common)

By subdividing the scenario, different authentication token categories are obtained as follows:

1. Type of original account password

  • User name and password
  • API application ID/KEY

2. Session ID category

  • Browser-side token
  • The mobile end token
  • Application API token

3. Interface invocation categories

  • Interface Access Token
  • Identity authorization Category
  • Tokens for mutual authorization between PC and mobile devices

3. Categories of tokens

Tokens in different scenarios are compared in the following dimensions:

Comparison of natural properties:

1. Use cost

This authentication method in the use of the inconvenience caused. Such as:

  • Accounts and passwords require users to open the page and type them one by one
  • Qr code requires users to take out their mobile phones to scan code operation
2. Variation costs

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

  • When the user name and password change, the user needs to memorize the new password and re-enter the new password
  • If the API application ID or KEY is changed, the third-party application needs to be modified in the code and deployed again
  • When the authorization QR code changes, the user needs to open the mobile phone application again to scan the code

Environmental risk

  • The risk of being peeped into
  • The risk of being caught
  • The risk of counterfeiting

Comparison of adjustable attributes:

1. Frequency of use

The frequency transmitted over the network

2. Valid time

The lifetime of this token from creation to termination

Ultimate goal: security and impact.

Security and privacy are mainly reflected in:

  • Tokens are not easily stolen and misappropriated (by controlling transmission frequency)
  • Even if the token is stolen, the impact is controllable (by controlling the effective time)

As for privacy and its consequences, there are the following basic conclusions:

  • High exposure frequencies are easy to intercept
  • The effects of long life cycle interception are more serious and far-reaching

Abide by the following principles:

  • Do not easily change tokens with high cost of change
  • Token that does not change easily should reduce exposure frequency (network transmission times)
  • The lifetime of tokens with high exposure frequency should be as short as possible

After adjusting the inherent characteristics and controllable attributes of various tokens, the following comparison table can be obtained by quantitative scoring each indicator (1-5 points) :

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

4. Hierarchy of token

Referring to the comparison table in the previous section, it is easy to layer these tokens for different purposes, which can be divided into four main layers:

  • Password layer: the most traditional form of digital identity authentication between the user and the system
  • Session layer: Session authentication during the session life cycle after a user logs in
  • Invocation layer: Authentication of user calls to the application interface during the session
  • Application layer: some scenarios or identity authentication applications after users obtain the interface access and invocation permission

The hierarchy 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:

  • A user enters a user name and password for one-time authentication
  • Generate session tokens with different lifecycles on different terminals
  • Client session Token Exchanges tokens from the server to the interface with a short lifetime but frequent exposure
  • Session tokens can be generated and refreshed to extend the lifetime of access_tokens
  • Access_token can generate the token with the shortest lifetime of the QR code used for authorization

Using the above architecture has the following benefits:

  • Good uniformity. It can solve the normalization problem of the lifetime of authentication token on different platforms
  • Good decoupling. The core interface calls the authentication access_token of the server and can be implemented and deployed independently
  • Good hierarchy. Different platforms can have completely different user permission control systems, and this control can be resolved in the session layer for each platform

4.1. Account password

A generalized account/password can be represented as follows:

  • Traditional registered username and password
  • App_id /app_key of the application
Their characteristics are as follows:

1. Will have special meaning

For example, in order to facilitate memory, users will set up accounts and passwords with certain meanings.

2, not often modified

The account password has special meaning for users, and they are not willing to change it without special circumstances. The app_id/app_key will be written in the application, and changing it will mean the cost of re-publishing

3. Once leaked, the impact will be far-reaching

Because of the infrequent changes, a breach is basically the equivalent of a user’s online identity being compromised, and identity theft continues as long as it goes undetected

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

4.2 Client session token

Function:

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

Use steps:

A user uses the account password to exchange for a session token

Tokens on different platforms have different characteristics:

The Web platform has a short lifetime

Main reasons:

  • Environment security: Because the Web login environment is likely to be a public environment, the risk of being stolen by others is large
  • Input convenience: It is convenient to use the keyboard to input information on a PC
The mobile terminal has a long life cycle

Main reasons:

  • Environmental security: mobile terminal platform is an extremely private platform for individual users, and there is little chance for people to contact it
  • Input convenience: Using fingers 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 server application API interface access and invocation.

Use steps:

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

Its exposure frequency is directly related to the interface call frequency, which belongs to the certificate of high frequency use. In order to protect privacy and minimize its life cycle, even if intercepted, it will not have serious consequences.

Note: An access_token is added to the client token so that the client tokens with different lifecycles will eventually have a unified authentication mode when calling the API.

4.4, pam_token

Function:

The original serial number of the QR code generated by the logged-in and authenticated PC (PC Auth Mobile).

The main steps are as follows:

  1. The user has been authenticated on the PC and logged in to the system
  2. The PC generates a set of PAM_tokens associated with this user
  3. The PC side generates a QR code by using this pam_token link
  4. The mobile terminal scans the code, requests the server, and associates it with user information
  5. Get refresh_token on mobile (long duration session)
  6. Obtain access_token based on refresh_token
  7. Normal interface calls are completed

Remark:

  • The validity period is 2 minutes. The deletion will expire after 2 minutes
  • Changes every 1 minute when not in use
  • Delete it as soon as it is used
  • This authentication mode is generally not used

4.5, map_token

Function:

The Mobile APP that has been logged in will scan code to authenticate the PC system and complete the login of the PC system (Mobile Auth PC).

Main steps:

  1. The mobile terminal completes user identity authentication and logs in to the APP
  2. The unlogged PC generates an anonymous MAP_token
  3. Generate MAP_token and user association in DB after scanning code on mobile terminal (complete signature)
  4. Db also generates a Web_token for the user
  5. The PC always searches for the web_token of the named user using map_token as parameter
  6. The PC obtains the Access_token based on the web_token
  7. Subsequent normal call interface calls work

Remark:

  • The validity period is 2 minutes. The deletion will expire after 2 minutes
  • Changes every 1 minute when not in use
  • Delete it as soon as it is used

5. Summary and prospect

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

  • Token classification problem
  • The token privacy parameter Settings are incorrect
  • The usage scenario of the token is incorrect
  • Token hierarchical transformation relationship in different life cycles

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

  • The user login
  • Time-limited coupon issuance
  • A valid invitation code is issued
  • Time-limited QR code authorization
  • With time-sensitive mobile phone/email verification code
  • Multiple platforms call the same SET of APIS
  • Multiple platforms use the same authentication authority

As for more usage scenarios, you need to explore.