Single-point intercommunication method and device based on multi-client independent security system scenario

CN123020105APending Publication Date: 2026-10-30LONGYING ZHIDA (BEIJING) TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610907302.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-23
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

但应用间互跳一般依赖用户自行导航或中心门户UI的二次选择,缺乏一套由任一客户端直接发起、直达另一客户端,无需回到中心门户UI进行二次选择且不改变各自认证边界的工程化方法

Benefits of technology

[0015]上述基于多客户端独立安全体系场景下的单点互通方法,受众绑定与最小权限:为目标客户端单独申请令牌,杜绝跨系统令牌复用,降低越权与横向移动风险。不改造各自认证体系:在不改变各自客户端既有安全框架的前提下完成互通,实施成本低、风险小。可插拔编排:责任链/事件委派(Delegator/Listener/Way)将校验、授权码、换取令牌、会话建立拆分为可独立演进的步骤,便于治理与扩展。全链路安全与可审计:互通凭证、授权码均是一次性且短时效的,防止重放攻击,登录中心保存有合法客户端清单,以防止非法系统攻击。不依赖中心门户UI的二次选择:在不改变各客户端既有认证体系的前提下,通过源客户端发起,登录中心生成授权码,生成专属的令牌,目标客户端根据其专属的令牌拉取当前用户的用户信息,从而实现目标客户端的自登录,建立本地会话,实现了当前用户直接从源客户端跳转到目标客户端,无需回到中心门户的页面进行二次选择。用户体验好:如果当前用户在登录中心未登录,登录中心不会展示登录页,而是主动向源客户端的后端发送登录用户检索请求,以完成自身侧自登录,即不会将登录中心的自登录过程展示给当前用户,更不会让当前用户人为登录过源客户端后,还要再人为登录该登录中心,实现静默授权,提高用户从源客户端一键跳至目标客户端的体验。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123020105A_ABST
    Figure CN123020105A_ABST
Patent Text Reader

Abstract

The application discloses a single-point intercommunication method and device based on a multi-client independent security system scene, relates to the technical field of application system login authentication, and realizes direct access from one client to another client, does not need to return to a central portal UI for secondary selection, and does not change respective authentication boundaries. The method comprises the following steps: in response to a login request of a current user to a target client, generating intercommunication credentials; sending the intercommunication credentials to a login center, so that the login center generates an authorization code according to the intercommunication credentials and sends the authorization code to a source client; receiving the authorization code and sending the authorization code to the target client, so that the target client sends the authorization code to the login center; the login center generates a token according to the authorization code and sends the token to the target client; the target client sends the token to the login center; the login center extracts user information corresponding to the current user according to the token and sends the user information to the target client; and the target client performs self-login according to the user information.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of application system login authentication technology, and in particular to a single-point interoperability method and apparatus based on a multi-client independent security system scenario. Background Technology

[0002] Within large organizations, multiple business systems (i.e., multiple clients) typically have their own established and solidified authentication and session systems. To unify identity sources and authorization, the industry generally adopts centralized authentication and authorization services based on OAuth2.0 / OIDC to achieve single sign-on.

[0003] Traditional single sign-on allows users to establish an authentication session with the login center in their browser once, and then access multiple registered clients without having to log in repeatedly. However, inter-application navigation generally relies on user navigation or secondary selection through the central portal UI. There is a lack of an engineered method that allows any client to directly initiate and access another client without returning to the central portal UI for secondary selection and without changing the authentication boundaries of each client. Summary of the Invention

[0004] In view of this, the present invention provides a single-point interoperability method and device based on a multi-client independent security system scenario, which enables direct access from one client to another without returning to the central portal UI for secondary selection and without changing the respective authentication boundaries.

[0005] One aspect provides a single-point interoperability method based on a multi-client independent security architecture scenario, applied to the source client. The method includes: The source client responds to the current user's login request to the target client by generating an interoperability credential, wherein the current user has already logged into the source client, and the interoperability credential includes the source client, the token corresponding to the current user, and the target client; The source client sends the interoperability certificate to the login center, so that the login center generates an authorization code corresponding to the target client and the current user based on the interoperability certificate, and sends the authorization code to the source client; The source client receives the authorization code and sends it to the target client, causing the target client to send the authorization code to the login center. The login center generates a token based on the authorization code and sends it to the target client. The target client then sends the token to the login center, which uses the token to extract the user information corresponding to the current user and sends it to the target client. The target client then performs a self-login based on the user information.

[0006] Preferably, the source client generates an interoperability credential in response to the current user's login request to the target client, wherein the current user has already logged into the source client, including: The source client responds to the current user's login request to the source client, and the current user completes the login to the source client; The source client sends a request to the login center to obtain the list of legitimate clients, receives the list of legitimate clients sent by the login center, renders the list of legitimate clients in the front end of the source client, and generates interoperability credentials in response to the current user's login request for any target client in the list of legitimate clients.

[0007] On another front, a single point-of-sight interoperability method based on a multi-client independent security architecture is provided, applied to a login center. The method includes: The login center receives an interoperability credential, wherein the interoperability credential is generated by the source client in response to the current user's login request to the target client, the current user has already logged into the source client, and the interoperability credential includes the source client, the token corresponding to the current user, and the target client; The login center generates an authorization code corresponding to the target client and the current user based on the interoperability certificate, and sends the authorization code to the source client, so that the source client sends the authorization code to the target client, and the target client sends the authorization code to the login center; The login center receives the authorization code sent by the target client, generates a token based on the authorization code, and sends it to the target client so that the target client sends the token to the login center. The login center receives the token, extracts the user information corresponding to the current user based on the token, and sends it to the target client so that the target client can log in automatically based on the user information.

[0008] Preferably, the login center generates an authorization code corresponding to the target client and the current user based on the interoperability credential, including: The login center obtains a list of legitimate clients and determines whether the source client is in the list of legitimate clients. If so, the verification is successful. A verification request is sent to the source client. The verification request includes the token corresponding to the current user, so that the source client receives the verification request sent by the login center and verifies whether the token corresponding to the current user is valid. If it is valid, the source client sends the user identity of the current user to the login center. The login center receives the user identity of the current user, determines whether the current user is logged in to the login center based on the user identity, and if not, the login center sends a login user retrieval request to the backend of the source client, receives the user information of the current user sent by the source client, and performs self-login based on the user information to realize that the current user is logged in to the login center and generates an authorization code corresponding to the target client and the current user.

[0009] On another front, a single-point interoperability method based on a multi-client independent security architecture is provided, applicable to any target client. The method includes: The target client receives the authorization code sent by the source client. The authorization code is generated by the login center based on the interoperability credential. The authorization code corresponds to the target client and the current user. The interoperability credential is generated by the source client in response to the current user's login request to the target client. The current user has logged into the source client. The interoperability credential includes the source client, the token corresponding to the current user, and the target client. The target client sends the authorization code to the login center, so that the login center generates a token based on the authorization code and sends the token to the target client. The target client receives the token and sends the token to the login center, so that the login center can extract the user information corresponding to the current user based on the token and send it to the target client. The target client receives the user information and performs self-login based on the user information.

[0010] In another aspect, a single-point interoperability device based on a multi-client independent security architecture is provided, applied to the source client. The device includes: The interoperability credential generation module is used by the source client to generate an interoperability credential in response to the current user's login request to the target client. The current user has already logged into the source client, and the interoperability credential includes the source client, the token corresponding to the current user, and the target client. The interoperability credential sending module is used by the source client to send the interoperability credential to the login center, so that the login center can generate an authorization code corresponding to the target client and the current user based on the interoperability credential, and send the authorization code to the source client; The first authorization code receiving module is used to receive the authorization code from the source client and send the authorization code to the target client, so that the target client sends the authorization code to the login center. The login center generates a token based on the authorization code and sends it to the target client. The target client sends the token to the login center. The login center extracts the user information corresponding to the current user based on the token and sends it to the target client. The target client then performs self-login based on the user information.

[0011] In another aspect, a single-point interoperability device based on a multi-client independent security system scenario is provided, applied to a login center. The device includes: The interoperability credential receiving module is used to receive interoperability credentials in the login center. The interoperability credential is generated by the source client in response to the current user's login request to the target client. The current user has already logged into the source client. The interoperability credential includes the source client, the token corresponding to the current user, and the target client. The authorization code generation module is used by the login center to generate an authorization code corresponding to the target client and the current user based on the interoperability credential, and send the authorization code to the source client, so that the source client sends the authorization code to the target client, and the target client sends the authorization code to the login center; The token generation module is used by the login center to receive the authorization code sent by the target client, generate a token based on the authorization code, and send it to the target client so that the target client sends the token to the login center. The first token receiving module is used to receive the token in the login center, extract the user information corresponding to the current user based on the token, and send it to the target client so that the target client can log in automatically based on the user information.

[0012] In another aspect, a single-point interoperability device based on a multi-client independent security system scenario is provided, applicable to any target client. The device includes: The second authorization code receiving module is used for the target client to receive the authorization code sent by the source client. The authorization code is generated by the login center based on the interoperability certificate. The authorization code corresponds to the target client and the current user. The interoperability certificate is generated by the source client in response to the current user's login request to the target client. The current user has logged into the source client. The interoperability certificate includes the source client, the token corresponding to the current user, and the target client. The authorization code sending module is used for the target client to send the authorization code to the login center, so that the login center generates a token based on the authorization code and sends the token to the target client; The second token receiving module is used for the target client to receive the token and send the token to the login center, so that the login center can extract the user information corresponding to the current user based on the token and send it to the target client; The user information receiving module is used by the target client to receive the user information and perform self-login based on the user information.

[0013] In another aspect, a storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the above-described single-point interoperability method based on a multi-client independent security architecture scenario.

[0014] In another aspect, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the program to implement the above-described single-point interoperability method based on a multi-client independent security architecture scenario.

[0015] The above-described single-point interoperability method based on a multi-client independent security architecture scenario features audience binding and least privilege: tokens are applied for separately for each target client, preventing token reuse across systems and reducing the risks of unauthorized access and lateral movement. It does not modify individual authentication systems: interoperability is achieved without altering the existing security framework of each client, resulting in low implementation cost and minimal risk. It offers pluggable orchestration: the chain of responsibility / event delegation (Delegator / Listener / Way) breaks down verification, authorization codes, token exchange, and session establishment into independently evolving steps, facilitating governance and expansion. It ensures end-to-end security and auditability: interoperability credentials and authorization codes are one-time and short-lived, preventing replay attacks. The login center maintains a list of legitimate clients to prevent attacks from unauthorized systems. It eliminates the need for secondary selection via the central portal UI: without changing the existing authentication systems of each client, the source client initiates the process, the login center generates an authorization code and a unique token, and the target client retrieves the current user's information based on its unique token, thus enabling self-login and establishing a local session for the target client. This allows the current user to directly jump from the source client to the target client without returning to the central portal page for secondary selection. Good user experience: If the current user is not logged in to the login center, the login center will not display the login page. Instead, it will actively send a login user retrieval request to the backend of the source client to complete its own self-login. That is, the self-login process of the login center will not be shown to the current user, and the current user will not have to manually log in to the login center again after manually logging in to the source client. This achieves silent authorization and improves the user experience of jumping from the source client to the target client with one click.

[0016] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of this application. In the drawings: Figure 1 The illustration shows a flowchart of a single-point interoperability method based on a multi-client independent security system scenario provided by an embodiment of the present invention; Figure 2 This invention provides a schematic flowchart of another single-point interoperability method based on a multi-client independent security architecture scenario. Figure 3 This diagram illustrates the structure of a single-point interoperability device based on a multi-client independent security system scenario, according to an embodiment of the present invention. Figure 4 This invention provides a schematic diagram of another single-point interconnection device based on a multi-client independent security system scenario. Figure 5 This invention provides a schematic diagram of the structure of another single-point interconnection device based on a multi-client independent security system scenario. Detailed Implementation

[0018] The present invention will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0019] In one embodiment, such as Figure 1 As shown, a single-point interoperability method based on a multi-client independent security architecture is provided. This method can be applied to the source client, the login center, and any target client. This embodiment illustrates the method by applying it to the source client, the login center, and any target client, and includes the following steps: 101. The source client responds to the current user's login request to the target client by generating an interoperability credential, wherein the current user has already logged into the source client, and the interoperability credential includes the source client, the token corresponding to the current user, and the target client. The source client sends the interoperability credential to the login center.

[0020] 102. The login center receives the interoperability certificate, generates an authorization code corresponding to the target client and the current user based on the interoperability certificate, and sends the authorization code to the source client.

[0021] In this system, the list of legitimate clients in the login center stores clients that have registered with the login center. Only clients that have registered with the login center can jump to each other. The source client is any client in the list of legitimate clients, and the target client is any client in the list of legitimate clients other than the source client. In step 101 of the embodiment, before the source client generates an interoperability credential in response to the current user's login request to the target client, the current user has already logged into the source client. In the source client, when the current user clicks on the target client, the source client receives the login request sent by the current user to the target client. In response to the current user's login request to the target client, the source client generates an interoperability credential and sends the interoperability credential to the login center through the browser.

[0022] The purpose of interoperability credentials is twofold: First, it informs the login center that the current user's login request to the target client is endorsed by the source client. Specifically, the interoperability credential explicitly identifies the source client, meaning it is signed by the source client. The login center can verify the signature to confirm that the current user's login request to the target client comes from a legitimate source client (if the source client is in its list of legitimate clients, then it is a legitimate source client), and not forged by an attacker. Second, the explicit identification of the target client prevents the interoperability credential from being misused to redirect to other unauthorized systems. Finally, the interoperability credential contains the token corresponding to the current user (this token is generated by the source client when the current user logs in, representing the current user's identity, such as an identifier). The login center can send a verification request to the source client through a backend interface. The source client verifies the validity of the token corresponding to the current user. If valid, the source client returns the current user's identity to the login center through the backend interface, eliminating the need to directly transmit the user's identity in the browser, thus adhering to the principle of least exposure. Finally, the interoperability credential is one-time and short-lived, preventing replay attacks.

[0023] Then, the login center generates an authorization code and sends it to the source client via the browser. This authorization code corresponds to both the target client and the current user. Specifically, the login center binds the authorization code to the target client and the current user. For example, if the current user is Zhang San and the target client is client App-B, then the authorization code uniquely corresponds to both Zhang San and client App-B. Since the authorization code does not contain sensitive information, such as the current user's identity, it can be sent to the source client via the browser.

[0024] The purpose of the authorization code is twofold: firstly, to exchange the authorization code for a token at the login center; secondly, to bind the authorization code to the target client and the current user at the login center, ensuring that the token is also bound to the target client and the current user when exchanging for a token; and finally, to prevent replay attacks, the authorization code is a one-time, short-term code.

[0025] 103. The source client receives the authorization code and sends the authorization code to the target client.

[0026] 104. The target client receives the authorization code sent by the source client, and the target client sends the authorization code to the login center.

[0027] In steps 103 and 104 of the embodiment, the authorization code is sent to the target client through the source client instead of directly by the login center. This is because by relaying the authorization code through the source client, the target client can determine that the authorization code was initiated by the source client. If the login center directly sends the authorization code to the target client, the target client cannot distinguish which source client initiated the authorization code.

[0028] 105. The login center receives the authorization code sent by the target client, generates a token based on the authorization code, and sends it to the target client.

[0029] 106. The target client receives the token and sends the token to the login center.

[0030] 107. The login center receives the token, extracts the user information corresponding to the current user based on the token, and sends it to the target client.

[0031] For steps 103-107 of the embodiment, the target client uses the authorization code to apply for a token from the login center, instead of the source client using the authorization code to apply for a token from the login center, and then using the token to apply for the user information corresponding to the current user from the login center, and then sending the user information to the target client. Because the target client cannot trust the user information sent by the source client, the target client needs to use the authorization code to apply for a token from the login center, and then use the token to apply for the user information corresponding to the current user from the login center.

[0032] In this embodiment, since the authorization code is bound to the target client and the current user in the login center, it is ensured that when exchanging tokens, the token is also bound to the target client and the current user. This avoids the transmission of inappropriate tokens between clients, which violates the audience binding principle. The audience binding principle states that each client must use a token specifically issued to itself, bound to its own audience, to avoid issues such as permission diffusion and token abuse. That is, each jump requires a separate token (aud=App-B) for the target client (App-B), and the token of the source client (App-A) is not reused across systems (aud=App-A), ensuring minimum permissions are bound to the audience.

[0033] It should be noted that the sending of tokens and user information is done through the backend interface, thus minimizing exposure.

[0034] 108. The target client receives the user information and performs self-login based on the user information.

[0035] The above-described single-point interoperability method based on a multi-client independent security architecture scenario features audience binding and least privilege: tokens are applied for separately for each target client, preventing token reuse across systems and reducing the risks of unauthorized access and lateral movement. It does not modify individual authentication systems: interoperability is achieved without altering the existing security framework of each client, resulting in low implementation cost and minimal risk. It offers pluggable orchestration: the chain of responsibility / event delegation (Delegator / Listener / Way) breaks down verification, authorization codes, token exchange, and session establishment into independently evolving steps, facilitating governance and expansion. It ensures end-to-end security and auditability: interoperability credentials and authorization codes are one-time and short-lived, preventing replay attacks. It eliminates the need for secondary selection via the central portal UI: without changing the existing authentication systems of each client, the source client initiates the process, logs into the central login center to generate an authorization code, and generates a unique token. The target client then uses its unique token to retrieve the current user's information, enabling self-login and establishing a local session. This allows the current user to directly jump from the source client to the target client without returning to the central portal for secondary selection.

[0036] In one embodiment, such as Figure 2As shown, another single-point interoperability method based on a multi-client independent security architecture is provided. This method can be applied to the source client, the login center, and any target client. This embodiment illustrates the method by applying it to the source client, the login center, and any target client, and includes the following steps: 201. In response to a login request from the current user to the source client, the source client sends a request to the login center to obtain a list of legitimate clients, receives the list of legitimate clients from the login center, renders the list of legitimate clients on the front end of the source client, and in response to a login request from the current user to any target client in the list of legitimate clients, the source client generates an interoperability credential, wherein the interoperability credential includes the source client, the token corresponding to the current user, and the target client, and the source client sends the interoperability credential to the login center.

[0037] 202. The login center receives the interoperability certificate. The login center obtains a list of legitimate clients and determines whether the source client is in the list of legitimate clients. If so, it passes the verification and sends a verification request to the source client. The verification request includes the token corresponding to the current user.

[0038] 203. The source client receives the verification request sent by the login center and verifies whether the token corresponding to the current user is valid. If it is, the source client sends the user identity of the current user to the login center.

[0039] 204. The login center receives the user identity of the current user, and determines whether the current user is logged in to the login center based on the user identity. If not, the login center sends a login user retrieval request to the backend of the source client.

[0040] 205. In response to the login user's retrieval request, the source client determines the current user's user information and sends the current user's user information to the login center.

[0041] 206. The login center receives the user information of the current user sent by the source client, performs self-login based on the user information, so as to enable the current user to log in to the login center, generates an authorization code corresponding to the target client and the current user, and sends the authorization code to the source client.

[0042] For steps 204-206 of the embodiment, since the current user is already logged in to the source client, but the current user is either logged in or not logged in to the login center, if the current user is logged in to the login center, an authorization code corresponding to the target client and the current user is generated and sent to the source client. If the current user is not logged in to the login center, the login center will not display a login page, but will actively send a login user retrieval request to the backend of the source client to complete its own self-login. That is, the self-login process of the login center will not be displayed to the current user, and the current user will not have to manually log in to the login center again after manually logging in to the source client. This achieves silent authorization and improves the user's experience of jumping from the source client to the target client with one click.

[0043] 207. The source client receives the authorization code and sends the authorization code to the target client.

[0044] 208. The target client receives the authorization code sent by the source client, and the target client sends the authorization code to the login center.

[0045] 209. The login center receives the authorization code sent by the target client, generates a token based on the authorization code, and sends it to the target client.

[0046] 210. The target client receives the token and sends the token to the login center.

[0047] 211. The login center receives the token, extracts the user information corresponding to the current user based on the token, and sends it to the target client.

[0048] 212. The target client receives the user information and performs self-login based on the user information.

[0049] Preferably, it also includes: failure and rollback: Target configuration mismatch: Terminate and prompt that the target is non-compliant, and log the audit event.

[0050] Token / User Information Retrieval Failed: Rollback with message "Interoperability Failed, please try again later".

[0051] Session establishment failed: Provides a safe fallback path for retrying and redirecting to the source client.

[0052] The above-described single-point interoperability method based on a multi-client independent security architecture scenario features audience binding and least privilege: tokens are applied for separately for each target client, preventing token reuse across systems and reducing the risks of unauthorized access and lateral movement. It does not modify individual authentication systems: interoperability is achieved without altering the existing security framework of each client, resulting in low implementation cost and minimal risk. It offers pluggable orchestration: the chain of responsibility / event delegation (Delegator / Listener / Way) breaks down verification, authorization codes, token exchange, and session establishment into independently evolving steps, facilitating governance and expansion. It ensures end-to-end security and auditability: interoperability credentials and authorization codes are one-time and short-lived, preventing replay attacks. The login center maintains a list of legitimate clients to prevent attacks from unauthorized systems. It eliminates the need for secondary selection via the central portal UI: without changing the existing authentication systems of each client, the source client initiates the process, the login center generates an authorization code and a unique token, and the target client retrieves the current user's information based on its unique token, thus enabling self-login and establishing a local session for the target client. This allows the current user to directly jump from the source client to the target client without returning to the central portal page for secondary selection. Good user experience: If the current user is not logged in to the login center, the login center will not display the login page. Instead, it will actively send a login user retrieval request to the backend of the source client to complete its own self-login. That is, the self-login process of the login center will not be shown to the current user, and the current user will not have to manually log in to the login center again after manually logging in to the source client. This achieves silent authorization and improves the user experience of jumping from the source client to the target client with one click.

[0053] It should be noted that the above-mentioned single-point interoperability method based on a multi-client independent security system is also built on the OAuth2.0 / OIDC standard, which facilitates integration with existing gateways, authorization servers and client SDKs.

[0054] Furthermore, as Figure 1 and Figure 2 The specific implementation of the method shown in this embodiment of the invention provides a single-point interoperability device based on a multi-client independent security system scenario, applied to the source client, such as... Figure 3 As shown, the device includes: an interoperability certificate generation module 31, an interoperability certificate sending module 32, and a first authorization code receiving module 33; Interoperability credential generation module 31 is used by the source client to generate interoperability credentials in response to the current user's login request to the target client, wherein the current user has logged into the source client, and the interoperability credentials include the source client, the token corresponding to the current user, and the target client; Interoperability credential sending module 32 is used for the source client to send the interoperability credential to the login center, so that the login center generates an authorization code corresponding to the target client and the current user based on the interoperability credential, and sends the authorization code to the source client; The first authorization code receiving module 33 is used for the source client to receive the authorization code and send the authorization code to the target client, so that the target client sends the authorization code to the login center, the login center generates a token based on the authorization code and sends it to the target client, the target client sends the token to the login center, the login center extracts the user information corresponding to the current user based on the token and sends it to the target client, and the target client performs self-login based on the user information.

[0055] In specific application scenarios, the interoperability credential generation module 31 can also be used by the source client to respond to the current user's login request to the source client, and the current user completes the login to the source client; the source client sends a request to the login center to obtain a list of legitimate clients, receives the list of legitimate clients sent by the login center, renders the list of legitimate clients on the front end of the source client, and generates an interoperability credential in response to the current user's login request to any target client in the list of legitimate clients.

[0056] It should be noted that other corresponding descriptions of the functional units involved in the single-point interoperability device based on a multi-client independent security system scenario provided in this embodiment can be found in [reference]. Figures 1 to 2 The corresponding description will not be repeated here.

[0057] Furthermore, as Figure 1 and Figure 2 The specific implementation of the method shown in this application provides a single-point interoperability device based on a multi-client independent security system scenario, applied to a login center, such as... Figure 4 As shown, the device includes: an interoperability credential receiving module 41, an authorization code generation module 42, a token generation module 43, and a first token receiving module 44; Interoperability credential receiving module 41 is used for receiving interoperability credentials in the login center. The interoperability credentials are generated by the source client in response to the current user's login request to the target client. The current user has already logged into the source client. The interoperability credentials include the source client, the token corresponding to the current user, and the target client. The authorization code generation module 42 is used by the login center to generate an authorization code corresponding to the target client and the current user based on the interoperability certificate, and send the authorization code to the source client, so that the source client sends the authorization code to the target client, and the target client sends the authorization code to the login center; The token generation module 43 is used for the login center to receive the authorization code sent by the target client, generate a token according to the authorization code, and send it to the target client so that the target client sends the token to the login center; The first token receiving module 44 is used to receive the token in the login center, extract the user information corresponding to the current user based on the token, and send it to the target client so that the target client can log in automatically based on the user information.

[0058] In specific application scenarios, the authorization code generation module 42 can also be used by the login center to obtain a list of legitimate clients, determine whether the source client is in the list of legitimate clients, and if so, pass the verification; send a verification request to the source client, the verification request including the token corresponding to the current user, so that the source client receives the verification request sent by the login center, verifies whether the token corresponding to the current user is valid, and if so, the source client sends the user identity of the current user to the login center; the login center receives the user identity of the current user, and determines whether the current user is logged in at the login center based on the user identity of the current user, if not, the login center sends a login user retrieval request to the backend of the source client, receives the user information of the current user sent by the source client, and performs self-login based on the user information to realize that the current user is logged in at the login center, and generates an authorization code corresponding to the target client and the current user.

[0059] It should be noted that other corresponding descriptions of the functional units involved in the single-point interoperability device based on a multi-client independent security system scenario provided in this embodiment can be found in [reference]. Figures 1 to 2 The corresponding description will not be repeated here.

[0060] Furthermore, as Figure 1 and Figure 2 The specific implementation of the method shown in this application provides a single-point interoperability device based on a multi-client independent security system scenario, applicable to any target client, such as... Figure 5 As shown, the device includes: a second authorization code receiving module 51, an authorization code sending module 52, a second token receiving module 53, and a user information receiving module 54; The second authorization code receiving module 51 is used for the target client to receive the authorization code sent by the source client. The authorization code is generated by the login center based on the interoperability certificate. The authorization code corresponds to the target client and the current user. The interoperability certificate is generated by the source client in response to the current user's login request to the target client. The current user has logged into the source client. The interoperability certificate includes the source client, the token corresponding to the current user, and the target client. The authorization code sending module 52 is used for the target client to send the authorization code to the login center, so that the login center generates a token based on the authorization code and sends the token to the target client; The second token receiving module 53 is used for the target client to receive the token and send the token to the login center, so that the login center can extract the user information corresponding to the current user based on the token and send it to the target client; User information receiving module 54 is used for the target client to receive the user information and perform self-login based on the user information.

[0061] It should be noted that other corresponding descriptions of the functional units involved in the single-point interoperability device based on a multi-client independent security system scenario provided in this embodiment can be found in [reference]. Figures 1 to 2 The corresponding description will not be repeated here.

[0062] Based on the above, Figures 1 to 2 Accordingly, this embodiment also provides a storage medium, which may be volatile or non-volatile, storing computer-readable instructions thereon. When these instructions are executed by a processor, they implement the above-described method. Figures 1 to 2 The battery swapping control method for the electric bicycle is shown.

[0063] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a storage medium (such as a CD-ROM, USB flash drive, portable hard drive, etc.) and includes several instructions to cause a computer device (such as a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0064] Based on the above, Figures 1 to 2 The method shown and Figure 3 , Figure 4 , Figure 5 To achieve the above objectives, this embodiment also provides a computer device, which includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to implement the above-described virtual device embodiment. Figures 1 to 2The battery swapping control method for the electric bicycle is shown.

[0065] Optionally, the computer device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0066] Those skilled in the art will understand that the computer device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0067] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned computer device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing device.

[0068] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platform, or it can be implemented by hardware.

[0069] Through the above description of the implementation methods, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented through hardware. The above-described single-point interoperability method based on a multi-client independent security architecture scenario features audience binding and least privilege: tokens are applied for separately for each target client, preventing cross-system token reuse and reducing the risk of unauthorized access and lateral movement. It does not modify the respective authentication systems: interoperability is achieved without changing the existing security framework of each client, resulting in low implementation cost and low risk. It offers pluggable orchestration: the chain of responsibility / event delegation (Delegator / Listener / Way) breaks down verification, authorization codes, token exchange, and session establishment into independently evolving steps, facilitating governance and expansion. It ensures end-to-end security and auditability: interoperability credentials and authorization codes are one-time and short-lived, preventing replay attacks; the login center maintains a list of legitimate clients to prevent attacks from unauthorized systems. Secondary selection without relying on the central portal UI: Without changing the existing authentication system of each client, the login center generates an authorization code and a unique token initiated by the source client. The target client then retrieves the current user's information based on its unique token, thus achieving self-login for the target client and establishing a local session. This allows the current user to directly jump from the source client to the target client without returning to the central portal page for secondary selection. Improved user experience: If the current user is not logged in to the login center, the login center will not display a login page. Instead, it proactively sends a login user retrieval request to the source client's backend to complete its own self-login. This means the login center's self-login process is not displayed to the current user, and the user does not need to manually log in to the login center after already logging in to the source client. This achieves silent authorization and improves the user experience of jumping from the source client to the target client with one click.

[0070] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0071] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A single-point interoperability method based on a multi-client independent security architecture scenario, applied to the source client, characterized in that, The method includes: The source client responds to the current user's login request to the target client by generating an interoperability credential, wherein the current user has already logged into the source client, and the interoperability credential includes the source client, the token corresponding to the current user, and the target client; The source client sends the interoperability certificate to the login center, so that the login center generates an authorization code corresponding to the target client and the current user based on the interoperability certificate, and sends the authorization code to the source client; The source client receives the authorization code and sends it to the target client, causing the target client to send the authorization code to the login center. The login center generates a token based on the authorization code and sends it to the target client. The target client then sends the token to the login center, which extracts the user information corresponding to the current user based on the token and sends it to the target client. The target client then performs self-login based on the user information.

2. The method according to claim 1, characterized in that, The source client responds to the current user's login request to the target client by generating interoperability credentials, wherein the current user is already logged into the source client, including: The source client responds to the current user's login request to the source client, and the current user completes the login to the source client; The source client sends a request to the login center to obtain the list of legitimate clients, receives the list of legitimate clients sent by the login center, renders the list of legitimate clients in the front end of the source client, and generates interoperability credentials in response to the current user's login request for any target client in the list of legitimate clients.

3. A single-point interoperability method based on a multi-client independent security system scenario, applied to a login center, characterized in that... The method includes: The login center receives an interoperability credential, wherein the interoperability credential is generated by the source client in response to the current user's login request to the target client, the current user has already logged into the source client, and the interoperability credential includes the source client, the token corresponding to the current user, and the target client; The login center generates an authorization code corresponding to the target client and the current user based on the interoperability certificate, and sends the authorization code to the source client, so that the source client sends the authorization code to the target client, and the target client sends the authorization code to the login center; The login center receives the authorization code sent by the target client, generates a token based on the authorization code, and sends it to the target client so that the target client sends the token to the login center. The login center receives the token, extracts the user information corresponding to the current user based on the token, and sends it to the target client so that the target client can log in automatically based on the user information.

4. The method according to claim 3, characterized in that, The login center generates an authorization code corresponding to the target client and the current user based on the interoperability credential, including: The login center obtains a list of legitimate clients and determines whether the source client is in the list of legitimate clients. If so, the verification is successful. A verification request is sent to the source client. The verification request includes the token corresponding to the current user, so that the source client receives the verification request sent by the login center and verifies whether the token corresponding to the current user is valid. If it is valid, the source client sends the user identity of the current user to the login center. The login center receives the user identity of the current user, determines whether the current user is logged in to the login center based on the user identity, and if not, the login center sends a login user retrieval request to the backend of the source client, receives the user information of the current user sent by the source client, and performs self-login based on the user information to realize that the current user is logged in to the login center and generates an authorization code corresponding to the target client and the current user.

5. A single-point interoperability method based on a multi-client independent security architecture, applicable to any target client, characterized in that, The method includes: The target client receives the authorization code sent by the source client. The authorization code is generated by the login center based on the interoperability credential. The authorization code corresponds to the target client and the current user. The interoperability credential is generated by the source client in response to the current user's login request to the target client. The current user has logged into the source client. The interoperability credential includes the source client, the token corresponding to the current user, and the target client. The target client sends the authorization code to the login center, so that the login center generates a token based on the authorization code and sends the token to the target client. The target client receives the token and sends the token to the login center, so that the login center can extract the user information corresponding to the current user based on the token and send it to the target client. The target client receives the user information and performs self-login based on the user information.

6. A single-point interoperability device based on a multi-client independent security system scenario, applied to the source client, characterized in that, The device includes: The interoperability credential generation module is used by the source client to generate an interoperability credential in response to the current user's login request to the target client. The current user has already logged into the source client, and the interoperability credential includes the source client, the token corresponding to the current user, and the target client. The interoperability credential sending module is used by the source client to send the interoperability credential to the login center, so that the login center can generate an authorization code corresponding to the target client and the current user based on the interoperability credential, and send the authorization code to the source client; The first authorization code receiving module is used to receive the authorization code from the source client and send the authorization code to the target client, so that the target client sends the authorization code to the login center. The login center generates a token based on the authorization code and sends it to the target client. The target client sends the token to the login center. The login center extracts the user information corresponding to the current user based on the token and sends it to the target client. The target client then performs self-login based on the user information.

7. A single-point interoperability device based on a multi-client independent security system scenario, applied to a login center, characterized in that, The device includes: The interoperability credential receiving module is used to receive interoperability credentials in the login center. The interoperability credential is generated by the source client in response to the current user's login request to the target client. The current user has already logged into the source client. The interoperability credential includes the source client, the token corresponding to the current user, and the target client. The authorization code generation module is used by the login center to generate an authorization code corresponding to the target client and the current user based on the interoperability credential, and send the authorization code to the source client, so that the source client sends the authorization code to the target client, and the target client sends the authorization code to the login center; The token generation module is used by the login center to receive the authorization code sent by the target client, generate a token based on the authorization code, and send it to the target client so that the target client sends the token to the login center. The first token receiving module is used to receive the token in the login center, extract the user information corresponding to the current user based on the token, and send it to the target client so that the target client can log in automatically based on the user information.

8. A single-point interoperability device based on a multi-client independent security system scenario, applicable to any target client, characterized in that, The device includes: The second authorization code receiving module is used for the target client to receive the authorization code sent by the source client. The authorization code is generated by the login center based on the interoperability certificate. The authorization code corresponds to the target client and the current user. The interoperability certificate is generated by the source client in response to the current user's login request to the target client. The current user has logged into the source client. The interoperability certificate includes the source client, the token corresponding to the current user, and the target client. The authorization code sending module is used for the target client to send the authorization code to the login center, so that the login center generates a token based on the authorization code and sends the token to the target client; The second token receiving module is used for the target client to receive the token and send the token to the login center, so that the login center can extract the user information corresponding to the current user based on the token and send it to the target client; The user information receiving module is used by the target client to receive the user information and perform self-login based on the user information.

9. A storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the single-point interoperability method in a multi-client independent security system scenario as described in any one of claims 1 to 5.

10. A computer device comprising a memory, a processor, and a computer program stored on a storage medium and executable on the processor, characterized in that, When the processor executes the program, it implements the single-point interoperability method based on a multi-client independent security system scenario as described in any one of claims 1 to 5.