Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Method course of token-based Multi-platform identity Authentication Architecture Design

2025-02-23 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/03 Report--

This article introduces the "token-based multi-platform identity authentication architecture design method tutorial" related knowledge, in the actual case operation process, many people will encounter such a dilemma, then let the editor lead you to learn how to deal with these situations! I hope you can read it carefully and be able to achieve something!

1. Overview

In the information system where there is an account system, the identification of identity is very important.

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

Different clients produce different user usage scenarios, these scenarios:

There are different environmental security threats

Different session life cycle

Different user access control systems

Different levels of interface calls

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

This paper will use some space to analyze and sort out these scenes.

2. Use the scene

Here are some common usage scenarios for IT services:

Users log in to the system on the web browser and use the system service

Users log in to the system on the Android/iOS and use the system services

Users use open interfaces to log in to the system and invoke system services

When PC handles login status, users are authorized to log in via mobile phone by scanning code (less used)

Users log in through mobile phone code scanning authorization PC when processing login status on mobile phone (more common)

Through the subdivision of the scenario, the following different authentication token categories are obtained:

1. Password category of the original account

User name and password

API application ID/KEY

2. Session ID category

Browser-side token

Mobile token

API application token

3. API call category

Interface access to token

Identity authorization category

PC and mobile token authorized by each other

3. The category of token

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

Comparison of natural attributes:

1. Cost of use

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

Account password requires the user to open the page and type it one by one

The QR code requires the user to take out the mobile phone to scan the code.

2. Change cost

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

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

When the authorized QR code changes, the user needs to reopen the mobile app to scan the code.

Environmental risk

The risk of being peeped

The risk of being caught

The risk of being forged

Comparison of controllable attributes:

1. Frequency of use

The frequency transmitted over the network

2. Effective time

The lifetime of this token from creation to termination

The ultimate goal: security and impact.

Security and privacy are mainly reflected in:

Token is not easy to steal and steal (by controlling the transmission frequency)

Even if the token is stolen, the impact is controllable (by controlling the effective time)

With regard to privacy and the consequences of the destruction of privacy, there are the following basic conclusions:

Those with high exposure frequency are easy to be intercepted.

With a long life cycle, the impact after being intercepted is more serious and far-reaching.

Observe the following principles:

Token with high cost should not be changed easily.

Token which does not change easily should reduce the exposure frequency (network transmission times).

The life cycle of token with high exposure frequency should be as short as possible.

After regulating the inherent characteristics and controllable attributes of all kinds of token, and scoring each index quantitatively (1-5 points), we can get the following comparison table:

Note: username/passwd and appid/app_key are equivalent effects

4. The hierarchical relationship of token

Referring to the comparison table in the previous section, you can easily layer these token for different purposes, which can be divided into four layers:

Password layer: the most traditional digital authentication method between the user and the system

Session layer: session authentication in the session lifecycle after user login

Call layer: the user authenticates calls to the application interface during the session

Application layer: some scenarios or identity authentication applications after the user has obtained the permission to access the interface

The hierarchical diagram of token is as follows:

In a multi-client information system, the internal relations between the generation and application of these token are as follows:

The user enters the user name and password for one-time authentication

Generate session token with different lifecycles in different terminals

Client session token accesses token from server exchange interface with short life cycle but frequent exposure

Session token can be generated and refreshed to extend the lifetime of access_token

Access_token can generate token for authorized QR codes with the shortest lifetime.

Using the above architecture has the following benefits:

Good unity. It can solve the problem of normalization of the life cycle of certified token on different platforms.

Good decoupling. The authentication access_token of the server called by the core interface can be independently implemented and deployed.

Good hierarchy. Different platforms can have completely different user rights control systems, and this control can be solved in each platform in the session layer.

4.1, account password

In a broad sense, the account / password can be presented as follows:

Traditional registered username and password

Appid/appkey of the application

Their characteristics are as follows:

1. It will have special significance.

For example: users themselves in order to facilitate memory, will set a certain meaning of the account and password.

2. Not often modified

The account password has a special meaning to the user, generally there are no special circumstances will not be willing to change. While appid/appkey will be written in the application, modification will mean the cost of republishing and launching.

3. Once leaked, the impact is far-reaching.

Because it is not often modified, as long as the disclosure is basically equivalent to the user's network identity is disclosed, and as long as this identity theft will always exist as long as it is not detected.

Therefore, in the authentication system, the chance of transmission should be reduced as much as possible to avoid leakage.

4.2.client session token

Features:

Acting as a session, different clients have different lifecycles.

Steps to use:

Users use account passwords in exchange for session token

Token on different platforms has different characteristics:

Web platform has a short life cycle.

Main reasons:

Environmental security: because the web login environment is generally a public environment, the risk of being stolen by others is high.

Input convenience: it is more convenient to use the keyboard to type on the PC

Long life cycle of mobile terminal

Main reasons:

Environmental security: mobile platform is an extremely private platform for individual users, and there is little chance for them to get in touch with each other.

Input convenience: the input experience of using fingers on the small screen is poor, and the input cost is high.

4.3 、 access_token

Features:

The credentials that are accessed and invoked by the api interface of the server application.

Steps to use:

Use a session token with a long life cycle in exchange for this interface to access the token.

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

Note: add an access_token under the client token, mainly to enable the client token with different lifecycles to have a unified authentication method when calling api.

4.4 、 pam_token

Features:

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

The main steps are as follows:

The user on PC has completed authentication and logged in to the system

The PC side generates a set of pam_token associated with this user

The PC side generates a QR code from the usage link of this pam_token.

After scanning the code on the mobile end, the server is requested and associated with the user information.

Mobile side acquires refresh_token (long-lived session)

Obtain accesstoken according to refreshtoken

Complete the normal interface call work

Remarks:

The life cycle is 2 minutes, and it will be deleted after 2 minutes.

Change every minute when it is not in use

Delete it as soon as it is used

This kind of authentication mode is generally not used

4.5 、 map_token

Features:

The mobile app that has been logged in will scan the code to authenticate the PC-side system, and complete the login (Mobile Auth Pc) of the PC-side system.

Main steps:

Mobile end completes user identity authentication and logs in to app

PC that is not logged in generates anonymous map_token

After scanning the code on the mobile terminal, generate map_token and user association in db (complete signature)

Db also generates web_token for this user

The PC side has been using maptoken as a parameter to find the webtoken of this named user.

The PC side acquires accesstoken according to webtoken

Subsequent normal call API call work

Remarks:

The life cycle is 2 minutes, and it will be deleted after 2 minutes.

Change every minute when it is not in use

Delete it as soon as it is used

"token-based multi-platform authentication architecture design method tutorial" is introduced here, thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report