Single sign-on method for heterogeneous system, heterogeneous system and computing device cluster

Abstract

The invention belongs to the technical field of distributed system security, particularly relates to a single sign-on method for a heterogeneous system, the heterogeneous system and a computing device cluster, and aims to solve the problem of improving the single sign-on operation convenience and security of the heterogeneous system. The method comprises the following steps that: a subsystem obtains a mobile phone number input by a user through primary login, associates the mobile phone number with a local account registered in the subsystem by the user, and synchronizes the mobile phone number to a single sign-on system; the single sign-on system generates a globally unique single sign-on identifier according to the mobile phone number, binds the single sign-on identifier with the mobile phone number, associates the single sign-on identifier with a local account of the subsystem and a code of the subsystem, and synchronizes the single sign-on identifier to the subsystem; and the subsystem receives the synchronized single sign-on identifier, establishes a mapping relation between the single sign-on identifier and the local account and stores the mapping relation. Therefore, decentralized authentication and unified authentication of the heterogeneous system are realized, and the user experience and security of the heterogeneous system are improved.

Description

Technical Field

[0001] This invention belongs to the field of distributed system security technology, and specifically relates to a single sign-on method for heterogeneous systems, heterogeneous systems, computing device clusters, and computer-readable storage media. Background Technology

[0002] In heterogeneous systems, subsystems typically employ independent account systems (such as differentiated account password rules, mobile phone number binding strategies, and permission management mechanisms). Users need to switch identities between different subsystems, resulting in users having to remember multiple sets of authentication information, significantly increasing operational complexity, and easily leading to problems such as password leakage or incorrect input.

[0003] In existing technologies, traditional single sign-on (SSO) solutions, used to address the cumbersome issue of logging into multiple systems, achieve cross-system login state sharing through a centralized authentication center. However, traditional solutions have the following key drawbacks:

[0004] Traditional solutions require subsystems to expose sensitive user data (such as passwords and permission status) to the authentication center, while in real-world scenarios, subsystems often need to comply with strict privacy compliance requirements, creating a conflict between privacy protection and system autonomy.

[0005] Traditional solutions rely on specific communication protocols and standardized interfaces, but heterogeneous systems (such as legacy systems and third-party closed systems) often cannot be adapted due to differences in technology stacks, requiring deep modification of the original login logic of subsystems, which is costly to implement.

[0006] Traditional solutions typically require the subsystem to completely replace the original authentication process, making it impossible to retain an independent login entry point. The intrusive architecture lacks flexibility and is difficult to meet the needs of phased system migration or hybrid deployment.

[0007] If the centralized authentication center of a traditional solution fails, all systems will become unavailable, and the centralized storage of passwords also makes the system vulnerable to attacks, resulting in low system security.

[0008] Therefore, how to achieve single sign-on for heterogeneous systems while ensuring data privacy of subsystems and avoiding protocol intrusion, and thus improve user experience and system security, has become an urgent problem to be solved. Summary of the Invention

[0009] To address the aforementioned problems in the prior art, namely, improving the convenience and security of single sign-on (SSO) operations in heterogeneous systems, this application provides a SSO method for heterogeneous systems, the method comprising:

[0010] The subsystem of the heterogeneous system receives access requests from the user terminal;

[0011] The subsystem queries whether the browser cookie corresponding to the access request contains a public login credential token. If the browser cookie does not contain a public login credential token, the subsystem initiates user login authentication and displays the user login interaction interface.

[0012] The subsystem obtains the user's entered account or mobile number, checks whether the account or mobile number already exists, and if the account or mobile number does not exist, it determines that the user is logging in for the first time.

[0013] The subsystem obtains the mobile phone number entered by the user during the initial login, performs SMS verification on the mobile phone number, and if the SMS verification is successful, associates the mobile phone number with the user's local account registered in the subsystem, and synchronizes the mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system.

[0014] The single sign-on system receives the mobile phone number, the local account, and the code of the subsystem synchronized by the subsystem, queries whether there is a single sign-on identifier corresponding to the mobile phone number, if not, generates a globally unique single sign-on identifier based on the mobile phone number, associates the single sign-on identifier with the mobile phone number, the local account, and the code of the subsystem, and synchronizes the single sign-on identifier to the subsystem;

[0015] The subsystem receives the single sign-on identifier synchronized by the single sign-on system, establishes a mapping relationship between the single sign-on identifier and the local account, and stores the single sign-on identifier and the mapping relationship.

[0016] Optionally, in the method, the subsystem generates a first Kafka task to synchronize the mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system; the single sign-on system generates a second Kafka task to synchronize the single sign-on identifier to the subsystem.

[0017] Optionally, the method further includes:

[0018] The subsystem of the heterogeneous system receives access requests from the user terminal;

[0019] The subsystem queries whether the browser cookie corresponding to the access request contains a public login credential token. If the browser cookie does not contain a public login credential token, the subsystem initiates user login authentication.

[0020] If the user login authentication is successful, the user has successfully logged into the subsystem. The subsystem generates a temporary token request information based on the subsystem's code and the user's local account in the subsystem, and sends the temporary token request information to the single sign-on system of the heterogeneous system.

[0021] The single sign-on system receives the temporary token request information, decrypts the temporary token request information to obtain the code of the subsystem and the local account, generates the corresponding temporary authorization token, and returns the temporary authorization token to the subsystem;

[0022] The subsystem receives the temporary authorization token, transmits the temporary authorization token to the user terminal, and the user terminal uses the temporary authorization token to log in to the single sign-on system;

[0023] The single sign-on system generates a unique private credential token based on the user information corresponding to the temporary authorization token used for login, and caches the user information in Redis. The user information includes the local account and the single sign-on identifier corresponding to the code of the subsystem.

[0024] The single sign-on system encrypts the private credential token to generate a public login credential token, and writes the public login credential token into the browser cookie.

[0025] Optionally, the method further includes:

[0026] The subsystem of the heterogeneous system receives access requests from the user terminal;

[0027] The subsystem queries the browser cookie corresponding to the access request. If the browser cookie contains a public login credential token, it encrypts and generates a user information request based on the public login credential token and the subsystem's code, and sends the user information request to the single sign-on system.

[0028] The single sign-on system of the heterogeneous system receives the user information request, decrypts the user information request to obtain the code of the subsystem and the public login credential token, decrypts the public login credential token to obtain the private credential token, retrieves the corresponding user information from Redis based on the private credential token, and returns the user information to the subsystem.

[0029] The subsystem receives the user information and completes the passwordless login for the user based on the single sign-on identifier in the user information and the mapping relationship between the single sign-on identifier and the local account in the subsystem.

[0030] Optionally, the method further includes:

[0031] The subsystem of the heterogeneous system receives the user's request to change the mobile phone number and obtains the new mobile phone number entered by the user;

[0032] The new mobile phone number is verified via SMS. If the SMS verification is successful, the new mobile phone number is associated with the user's local account registered in the subsystem, and the new mobile phone number, the local account, and the code of the subsystem are synchronized to the single sign-on system of the heterogeneous system.

[0033] The single sign-on system queries whether a single sign-on identifier corresponding to the new mobile number exists. If not, it generates a globally unique new single sign-on identifier based on the new mobile number, replaces the original mobile number with the new mobile number, and replaces the original single sign-on identifier with the new single sign-on identifier. The original mobile number is the mobile number associated with the code of the local account and the subsystem before the generation of the new single sign-on identifier, and the original single sign-on identifier is the single sign-on identifier associated with the code of the local account and the subsystem before the generation of the new single sign-on identifier.

[0034] The system notifies all subsystems of the heterogeneous system to replace the original single sign-on identifier with the new single sign-on identifier and to replace the original mobile phone number with the new mobile phone number.

[0035] Another aspect of this application proposes a heterogeneous system, the heterogeneous system comprising a single sign-on system and at least one subsystem, the subsystem comprising:

[0036] The cookie query module is used to receive access requests from users and query whether the browser cookie corresponding to the access request contains a public login credential token.

[0037] The subsystem login module is used to initiate user login authentication of the subsystem, display the user login interaction interface, obtain the user's entered account or mobile phone number, query whether the account or mobile phone number already exists, and determine that the user is logging in for the first time if the account or mobile phone number does not exist.

[0038] The mobile phone number verification module is used to obtain the mobile phone number entered by the user during the initial login and to verify the mobile phone number via SMS.

[0039] The first association module is used to associate the mobile phone number with the user's local account registered in the subsystem if the SMS verification is successful.

[0040] The first synchronization module is used to synchronize the mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system.

[0041] The single sign-on system includes:

[0042] The single sign-on identifier generation module is used to receive the mobile phone number, the local account and the code of the subsystem synchronized by the subsystem, query whether there is a single sign-on identifier corresponding to the mobile phone number, and if not, generate a globally unique single sign-on identifier based on the mobile phone number;

[0043] The second association module is used to associate the single sign-on identifier with the mobile phone number, the local account, and the code of the subsystem;

[0044] The second synchronization module is used to synchronize the single sign-on identifier to the subsystem;

[0045] The subsystem also includes:

[0046] The mapping module is used to receive the single sign-on identifier synchronized by the single sign-on system, establish a mapping relationship between the single sign-on identifier and the local account, and store the single sign-on identifier and the mapping relationship.

[0047] Optionally, in the heterogeneous system, the cookie query module is used to receive an access request from the user and query whether the browser cookie corresponding to the access request contains a public login credential token; the subsystem login module is used to initiate user login authentication of the subsystem if the browser cookie does not contain a public login credential token.

[0048] The subsystem also includes:

[0049] The temporary authorization request module is used to generate a temporary token request information by encrypting the code of the subsystem and the user's local account in the subsystem if the user login authentication is successful, and send the temporary token request information to the single sign-on system of the heterogeneous system.

[0050] The single sign-on system also includes:

[0051] The temporary authorization module is used to receive the temporary token request information, decrypt the temporary token request information to obtain the code of the subsystem and the local account, generate the corresponding temporary authorization token, and return the temporary authorization token to the subsystem;

[0052] The subsystem also includes:

[0053] The temporary authorization login module is used to receive the temporary authorization token and transmit the temporary authorization token to the user terminal so that the user terminal can use the temporary authorization token to log in to the single sign-on system.

[0054] The single sign-on system also includes:

[0055] The private token generation module is used to generate a unique private credential token based on the user information corresponding to the temporary authorization token used for login.

[0056] The user information caching module is used to cache the user information in Redis. The user information includes the local account and the single sign-on identifier corresponding to the code of the subsystem.

[0057] A public token generation module is used to encrypt the private credential token to generate a public login credential token;

[0058] The public token adding module is used to write the public login credential token into the browser cookie.

[0059] Optionally, in the heterogeneous system, the subsystem includes: a cookie query module, used to receive an access request from a user and query whether the browser cookie corresponding to the access request contains a public login credential token;

[0060] The subsystem also includes:

[0061] The user information request module is used to generate a user information request by encrypting the public login credential token and the code of the subsystem if the browser cookie contains a public login credential token, and then send the user information request to the single sign-on system.

[0062] The single sign-on system also includes:

[0063] The user information request module is used to receive the user information request, decrypt the user information request to obtain the code of the subsystem and the public login credential token, decrypt the public login credential token to obtain the private credential token, retrieve the corresponding user information from Redis according to the private credential token, and return the user information to the subsystem.

[0064] The subsystem also includes:

[0065] The shared login module is used to receive the user information and complete the passwordless login of the user based on the single sign-on identifier in the user information and the mapping relationship between the single sign-on identifier and the local account in the subsystem.

[0066] A third aspect of this application provides a computing device cluster including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the method described above.

[0067] In a fourth aspect, this application provides a computer-readable storage medium storing computer instructions for execution by the computer to implement the method described above.

[0068] The single sign-on (SSO) method and system for heterogeneous systems proposed in this application achieve distributed authentication. Subsystems can retain independent login authentication, and SSO system failures do not affect the independent operation of subsystems. Sensitive information (such as passwords) is not centrally stored, ensuring data privacy for subsystems and reducing the risk of data leakage and attacks. A globally unique SSO identifier is generated based on the user's mobile phone number, and this identifier is mapped to the local account of each subsystem, thereby achieving unified identity authentication for heterogeneous systems. This solves the "account silo" problem caused by independent account systems in multiple subsystems. A user logs in once, and associated subsystems can achieve seamless login. Cross-domain login state sharing does not require modification of subsystems, making it easy to integrate new systems, flexible in architecture, and cost-effective. Moreover, sensitive information is transmitted encrypted. Through private token (private credential token) and public token (public login credential token) mechanisms and layered encryption, threats such as man-in-the-middle attacks and token replay are effectively defended, ensuring high security for heterogeneous systems. Attached Figure Description

[0069] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0070] Figure 1 This is a flowchart of one implementation of the single sign-on method for heterogeneous systems in this application;

[0071] Figure 2 This is a complete flowchart of the single sign-on method for heterogeneous systems in this application, in which the public login credential token is added to the client browser cookie;

[0072] Figure 3 This is a flowchart illustrating the sharing of login state in the single sign-on method for heterogeneous systems in this application;

[0073] Figure 4 This is a flowchart illustrating the method for modifying a mobile phone number in the single sign-on approach for heterogeneous systems, as described in this application.

[0074] Figure 5 This is a schematic diagram of the structure of a heterogeneous system according to this application;

[0075] Figure 6 This is a schematic diagram of the structure of a computer system used to implement the methods, systems, and devices of this application. Detailed Implementation

[0076] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0077] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0078] This application provides a single sign-on method for heterogeneous systems. The method is applied to heterogeneous systems, which include a single sign-on system and at least one subsystem. The single sign-on system acts as a unified login management mechanism, and the subsystems are business systems. The single sign-on system interacts with the subsystems. Figure 1 As shown, the method includes:

[0079] Step S1011: The subsystem receives the access request from the user and queries whether the browser cookie corresponding to the access request contains a public login credential token.

[0080] Step S1012: If the browser cookie does not contain a public login credential token, the subsystem initiates user login authentication and displays the user login interaction interface.

[0081] Step S1013: The subsystem obtains the account or mobile phone number entered by the user and checks whether the account or mobile phone number already exists.

[0082] Step S1014: If the account or mobile number does not exist, it is determined that the user is logging in for the first time. The subsystem obtains the mobile number entered by the user during the first login and performs SMS verification on the mobile number.

[0083] Step S1015: If the SMS verification is successful, the subsystem associates the mobile phone number with the user's local account registered in the subsystem, and synchronizes the mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system.

[0084] Step S1021: The single sign-on system receives the mobile phone number, the local account, and the code of the subsystem synchronized by the subsystem, and queries whether there is a single sign-on identifier corresponding to the mobile phone number;

[0085] Step S1022: If it does not exist, the single sign-on system generates a globally unique single sign-on identifier based on the mobile phone number, and associates the single sign-on identifier with the mobile phone number, the local account, and the code of the subsystem;

[0086] Step S1023: If it exists, the single sign-on identifier obtained from the single sign-on system query is associated with the mobile phone number, the local account, and the code of the subsystem.

[0087] Step S1024: The single sign-on system synchronizes the single sign-on identifier to the subsystem;

[0088] In step S1016, the subsystem receives the single sign-on identifier synchronized by the single sign-on system, establishes a mapping relationship between the single sign-on identifier and the local account, and stores the single sign-on identifier and the mapping relationship.

[0089] Specifically, when a user accesses the subsystem using a browser on their client side, the subsystem receives the access request and checks if the browser cookie contains a public login credential token. If it does, the user is already logged in to the single sign-on system; otherwise, the user is not yet logged in. The subsystem then initiates its own user login authentication and displays the user login interface. The user logs in by entering their account (or mobile number) and password through the user login interface. The subsystem retrieves the entered account or mobile number and checks if it is already stored locally. If the account (or mobile number) already exists, the user has already registered with the subsystem. The subsystem matches and verifies the entered account (or mobile number) and password to complete the user login authentication. If the matching and verification pass, the user login authentication is successful, and the user logs in to the subsystem. If the account (or phone number) does not exist, indicating the user is logging in for the first time (i.e., a new user), the subsystem can prompt the user to register and display the registration interface. Alternatively, it can use the user's login page as the registration interface, and the username and password entered during the initial login will be the registered username and password. If the subsystem uses the phone number as the account, the user's entered account is the same as their phone number, and the subsystem obtains the user's phone number by retrieving the username entered during the initial login. If the subsystem separates the phone number and account, it prompts the user to enter their phone number during the initial login and retrieves the entered phone number.

[0090] After obtaining the mobile phone number entered by the user during initial login, the subsystem verifies the number via SMS to ensure its accuracy and authenticity. If the SMS verification passes, the subsystem associates the mobile phone number with the user's local account registered in the subsystem. If the mobile phone number is also the local account, no association is required; it is essentially associated with the subsystem itself. The subsystem then synchronizes the mobile phone number, the associated local account, and the corresponding subsystem code to the single sign-on system.

[0091] After receiving the mobile phone number, associated local account, and corresponding subsystem code synchronized by the subsystem, the single sign-on system queries whether a single sign-on identifier corresponding to the mobile phone number exists locally in the single sign-on system.

[0092] If it exists, it means that the mobile phone number has been logged into the single sign-on system before. For example, other subsystems have synchronized the mobile phone number to the single sign-on system. The single sign-on system will associate the queried single sign-on identifier with the local account associated with the received mobile phone number and the code of the corresponding subsystem, and synchronize the single sign-on identifier to the subsystem.

[0093] If it does not exist, it means that the mobile number has never logged into the single sign-on system. The single sign-on system generates a globally unique single sign-on identifier based on the mobile number, binds the single sign-on identifier to the mobile number, associates the single sign-on identifier with the local account associated with the mobile number and the code of the corresponding subsystem, and synchronizes the single sign-on identifier to the subsystem.

[0094] After receiving the single sign-on identifier synchronized from the single sign-on system, the subsystem maps the single sign-on identifier to the local account corresponding to the mobile phone number in the subsystem and stores the single sign-on identifier and the mapping relationship. The subsystem also associates the single sign-on identifier with the mobile phone number stored in the subsystem.

[0095] The subsystem and the single sign-on system can be synchronized using Kafka. The subsystem generates a first Kafka task, which synchronizes the mobile phone number, the local account, and the subsystem's code to the single sign-on system. The single sign-on system generates a second Kafka task, which synchronizes the single sign-on identifier to the subsystem. Using Kafka message queues for synchronization can support second-level excessive logins and shorten response latency.

[0096] The single sign-on method for heterogeneous systems provided in this application generates a globally unique single sign-on identifier based on the user's mobile phone number. The single sign-on identifier is mapped to the local account of each subsystem, thereby achieving unified identity authentication for heterogeneous systems and solving the "account silo" problem caused by the independent account system of multiple subsystems. Meanwhile, the subsystems retain independent login authentication, and the subsystems do not need to replace their original authentication processes, making the architecture more flexible. Furthermore, the single sign-on system does not store sensitive information such as subsystem passwords, ensuring the data privacy and security of the subsystems and reducing the threat of data leakage.

[0097] In the above-described single sign-on method for heterogeneous systems, the public login credential token is added to the user's browser cookie by the single sign-on system. Specifically, as follows: Figure 2As shown, in another embodiment, the single sign-on method for heterogeneous systems in this application further includes:

[0098] Step S2011: The subsystem receives the access request from the user and queries whether the browser cookie corresponding to the access request contains a public login credential token.

[0099] Step S2012: If the browser cookie does not contain a public login credential token, the subsystem initiates user login authentication for the subsystem.

[0100] Step S2013: If the user login authentication is successful, the user has successfully logged into the subsystem. The subsystem generates a temporary token request information by encrypting the subsystem code and the user's local account in the subsystem, and sends the temporary token request information to the single sign-on system of the heterogeneous system.

[0101] Specifically, the subsystem user login authentication can be referred to in steps S1013 and S1014. When the subsystem initiates user login authentication, it displays the user login interaction interface. After obtaining the username and password entered by the user, it checks whether the username entered by the user already exists locally. If a local account exists, it matches and verifies the username and password entered by the user to complete the authentication. If the authentication is successful, the user successfully logs into the subsystem; if no local account exists, it is determined that the user is logging in for the first time, and the aforementioned steps are executed. Figure 1 The process of steps S1015 to S1016 and steps S1021 to S1024.

[0102] After a user successfully logs into the subsystem, the subsystem encrypts and generates a temporary token request based on its own code and the user's local account registered within the subsystem, and then sends the temporary token request to the single sign-on system. In one implementation, the subsystem encrypts and generates the temporary token request based on the code, the local account, and a dynamic salt value, which further enhances the salt value defense system and ensures transmission security.

[0103] Step S2021: The single sign-on system receives the temporary token request information, decrypts the temporary token request information to obtain the code of the subsystem and the local account, generates the corresponding temporary authorization token, and returns the temporary authorization token to the subsystem.

[0104] Specifically, the single sign-on system decrypts the temporary token request information to obtain the subsystem's code and local account. It can further verify the code and local account, checking whether the subsystem's code and corresponding local account are recorded and valid in the single sign-on system. If not recorded or invalid, an error message is returned to the subsystem. If recorded and valid, a temporary authorization token is generated and returned to the subsystem. The temporary authorization token can be a random number generated based on the code and local account, or it can be a random number generated based on the single sign-on identifier in the single sign-on system corresponding to the code and local account. Furthermore, the temporary authorization token corresponds to user information in the single sign-on system. This user information can be the single sign-on identifier, or it can include the single sign-on identifier and the code and local account of the subsystem associated with it.

[0105] In step S2014, the subsystem receives the temporary authorization token, transmits the temporary authorization token to the user terminal, and the user terminal uses the temporary authorization token to log in to the single sign-on system.

[0106] Specifically, after receiving a temporary authorization token, the subsystem transmits it to the user terminal. Upon receiving the temporary authorization token, the user terminal initiates a login request to the single sign-on system based on the token. This request includes the temporary authorization token. Upon receiving the login request, in one implementation, the single sign-on system verifies the validity of the temporary authorization token. If the verification is successful, the user terminal is marked as authorized, and the user terminal completes the login process. Simultaneously, the single sign-on system obtains the user information corresponding to the temporary authorization token, and based on this information, obtains the subsystem's code and local account, as well as the single sign-on identifier associated with the code and local account; or it directly obtains the single sign-on identifier contained in the user information.

[0107] Step S2022: The single sign-on system generates a unique private credential token based on the user information corresponding to the temporary authorization token used for login, and caches the user information in Redis. The user information includes the local account and the single sign-on identifier corresponding to the code of the subsystem.

[0108] In step S2023, the single sign-on system encrypts the private credential token to generate a public login credential token and writes the public login credential token into the browser cookie.

[0109] Specifically, the single sign-on system obtains a corresponding single sign-on identifier based on a temporary authorization token, which is the user information. It can further obtain the subsystem code and local account associated with the single sign-on identifier. The user information includes the single sign-on identifier and the associated subsystem code and local account. The single sign-on system generates a unique private credential token based on the user information, which corresponds to the user information, and caches the user information in Redis. Using Redis caching effectively reduces response latency and supports high-concurrency scenarios. After generating the private credential token, the single sign-on system encrypts it to generate a public login credential token and writes the public login credential token into the user's browser cookie.

[0110] Therefore, the subsystem can determine whether a user has logged into the single sign-on system based on the user's browser cookie, that is, whether the user has logged into any subsystem in the heterogeneous system. Login state sharing can be further achieved through the public login credential token in the browser cookie. Furthermore, the heterogeneous single sign-on method provided in this application adopts a dual-token separation approach, using both private and public login credential tokens, which effectively defends against man-in-the-middle attacks and token replay attacks, achieving high security for heterogeneous systems.

[0111] If there is no single sign-on identifier corresponding to the user's mobile phone number in the single sign-on system, it means that the user has never logged into any subsystem of the heterogeneous system, and the heterogeneous system will execute... Figure 1 The process is shown below. If a single sign-on identifier corresponding to a user's mobile phone number exists in the single sign-on system, it indicates that the user has previously logged into a subsystem of the heterogeneous system. When the user first accesses the heterogeneous system (i.e., accesses any subsystem of the heterogeneous system), the heterogeneous system executes... Figure 1 The process shown is executed simultaneously. Figure 2 The process is shown below. After a user ends their access to the heterogeneous system, when they subsequently access any subsystem of the heterogeneous system again, the heterogeneous system executes... Figure 2 The process is shown below. It should be noted that the public login credential token in the user's browser cookie can be set to retain for a period of time. After the retention period expires, the public login credential token is deleted from the browser cookie. When the user accesses the heterogeneous system again, the heterogeneous system executes... Figure 2 The process is shown below.

[0112] When a user has already logged into one subsystem of a heterogeneous system and then accesses other subsystems within the same heterogeneous system, the single sign-on method for heterogeneous systems provided in this application can achieve login state sharing, such as... Figure 3 As shown, the method further includes:

[0113] Step S3011: The subsystem of the heterogeneous system receives the access request from the user and queries whether the browser cookie corresponding to the access request contains public login credentials.

[0114] Step S3012: If the browser cookie contains a public login credential, the subsystem generates a user information request based on the public login credential token and the subsystem's code encryption.

[0115] Step S3013: The subsystem sends the user information request to the single sign-on system;

[0116] Step S3021: The single sign-on system of the heterogeneous system receives the user information request, decrypts the user information request to obtain the code of the subsystem and the public login credential token;

[0117] Step S3022: The single sign-on system decrypts the public login credential token to obtain the private credential token;

[0118] Step S3023: The single sign-on system retrieves the corresponding user information from Redis based on the private credential token and returns the user information to the subsystem.

[0119] In step S3014, the subsystem receives the user information and completes the passwordless login for the user based on the single sign-on identifier in the user information and the mapping relationship between the single sign-on identifier and the local account in the subsystem.

[0120] Specifically, upon receiving a user access request, the subsystem queries the user's browser cookie. If the browser cookie contains a public login credential token, it indicates that the user has already logged into another subsystem within the heterogeneous system. The subsystem does not need to initiate its own user login authentication, does not display a user login interface, and the user does not need to enter their username and password. Instead, the subsystem encrypts and generates a user information request based on the public login credential token and its own code, and sends this request to the single sign-on system. Furthermore, the subsystem can encrypt and generate the user information request using the public login credential token, its own code, and a dynamic salt value to ensure secure transmission.

[0121] After receiving a user information request from a subsystem, the single sign-on system decrypts the request to obtain the subsystem's code and a public login credential token. The subsystem's code indicates the subsystem the user is logging into. Upon receiving the user information request, the single sign-on system can also verify the validity of the public login credential token before decrypting it to obtain a private credential token. By using the public login credential token in visible browser cookies and the private credential token in the single sign-on system, multi-layered encryption and dual tokens effectively prevent data leakage and improve the security of heterogeneous systems.

[0122] After decrypting the private credential token, the single sign-on system retrieves the corresponding user information from Redis based on the token and returns the user information to the subsystem. Upon receiving the user information from the single sign-on system, the subsystem retrieves the single sign-on identifier, or the single sign-on identifier and the subsystem's local account. In one implementation, the subsystem verifies the correctness of the single sign-on identifier, the existence of a local account associated with the single sign-on identifier, and the correctness of the association with the subsystem's local account, based on the mapping relationship between the single sign-on identifier and the local account. If the verification passes, the local account status is changed to "logged in," meaning the user is logged into the subsystem, thus completing the passwordless login for the user.

[0123] The single sign-on method for heterogeneous systems provided in this application eliminates the need for users to log in to one subsystem within a heterogeneous system when accessing other subsystems. Instead, the login status is shared across the heterogeneous systems via the subsystem backend, enabling seamless cross-system login and "one-time authentication for access across the entire system." This significantly simplifies user operations, enhances user convenience, and improves the user experience.

[0124] When a user needs to change their mobile phone number, the single sign-on method for heterogeneous systems provided in this application, such as... Figure 4 As shown, it also includes:

[0125] Step S4011: The subsystem of the heterogeneous system receives the user's request to change the mobile phone number and obtains the new mobile phone number entered by the user.

[0126] In step S4012, the subsystem verifies the new mobile phone number via SMS. If the SMS verification is successful, the new mobile phone number is associated with the user's local account registered in the subsystem.

[0127] Step S4013: The subsystem synchronizes the new mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system;

[0128] Step S4021: The single sign-on system receives the new mobile phone number synchronized by the subsystem, the local account, and the code of the subsystem, and queries whether there is a single sign-on identifier corresponding to the new mobile phone number;

[0129] Step S4022: If it does not exist, the single sign-on system generates a globally unique new single sign-on identifier based on the new mobile phone number, replaces the original mobile phone number with the new mobile phone number, and replaces the original single sign-on identifier with the new single sign-on identifier.

[0130] Wherein, the original mobile phone number is the mobile phone number associated with the code of the local account and the subsystem before the new single sign-on identifier is generated, and the original single sign-on identifier is the single sign-on identifier associated with the code of the local account and the subsystem before the new single sign-on identifier is generated;

[0131] In step S4023, the single sign-on system notifies all subsystems of the heterogeneous system to replace the original single sign-on identifier with the new single sign-on identifier and to replace the original mobile phone number with the new mobile phone number.

[0132] Specifically, when a user needs to change their mobile number, they send a request to a subsystem via their client, entering the new mobile number. Upon receiving the request and the new mobile number, the subsystem first verifies the new number via SMS to ensure its accuracy and authenticity. Then, it establishes a local association between the new mobile number and the local account, and synchronizes the new mobile number, the associated local account, and the corresponding subsystem code to the single sign-on system.

[0133] After receiving the synchronization information from the subsystem, the Single Sign-On (SSO) system first checks if a SSO identifier corresponding to the new mobile number already exists. If it does, it means the user has already changed their mobile number in a subsystem of the heterogeneous system, and the system can return information that the new mobile number already exists to the subsystem without needing to perform any further actions. If it does not exist, the system generates a globally unique new SSO identifier based on the new mobile number, then replaces the original mobile number (i.e., the old mobile number) with the new mobile number, replaces the original SSO identifier (i.e., the old SSO identifier) ​​with the new SSO identifier, and sends a modification notification to all subsystems in the heterogeneous system. The modification notification includes the new SSO identifier and the new mobile number. This notification instructs all subsystems to replace their locally saved original SSO identifiers with the new SSO identifier. If a subsystem has already saved the original mobile number locally, it will replace it with the new mobile number. After receiving the modification notification from the SSO system, the subsystem replaces its locally saved original SSO identifier with the new SSO identifier and the original mobile number with the new mobile number. This completes the modification of the user's mobile phone number and the update of the corresponding single sign-on identifier.

[0134] Although the steps in the above embodiments are described in the above order, those skilled in the art will understand that in order to achieve the effect of this embodiment, different steps do not need to be executed in such an order. They can be executed simultaneously (in parallel) or in a reverse order. These simple variations are all within the protection scope of this invention.

[0135] A second aspect of this application provides a heterogeneous system for executing the aforementioned single sign-on method. The heterogeneous system includes a subsystem and a single sign-on system, specifically, as follows: Figure 5 As shown, the heterogeneous system includes:

[0136] Subsystem, the subsystem comprising:

[0137] The cookie query module is used to receive access requests from users and query whether the browser cookie corresponding to the access request contains a public login credential token.

[0138] The subsystem login module is used to initiate user login authentication of the subsystem, display the user login interaction interface, obtain the user's entered account or mobile phone number, query whether the account or mobile phone number already exists, and determine that the user is logging in for the first time if the account or mobile phone number does not exist.

[0139] The mobile phone number verification module is used to obtain the mobile phone number entered by the user during the initial login and to verify the mobile phone number via SMS.

[0140] The first association module is used to associate the mobile phone number with the user's local account registered in the subsystem if the SMS verification is successful.

[0141] The first synchronization module is used to synchronize the mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system.

[0142] A single sign-on system, the single sign-on system comprising:

[0143] The single sign-on identifier generation module is used to receive the mobile phone number, the local account and the code of the subsystem synchronized by the subsystem, query whether there is a single sign-on identifier corresponding to the mobile phone number, and if not, generate a globally unique single sign-on identifier based on the mobile phone number;

[0144] The second association module is used to associate the single sign-on identifier with the mobile phone number, the local account, and the code of the subsystem;

[0145] The second synchronization module is used to synchronize the single sign-on identifier to the subsystem;

[0146] The subsystem also includes:

[0147] The mapping module is used to receive the single sign-on identifier synchronized by the single sign-on system, establish a mapping relationship between the single sign-on identifier and the local account, and store the single sign-on identifier and the mapping relationship.

[0148] Furthermore, the subsystem shown also includes:

[0149] The temporary authorization request module is used to generate a temporary token request information by encrypting the code of the subsystem and the user's local account in the subsystem if the user login authentication is successful, and send the temporary token request information to the single sign-on system of the heterogeneous system.

[0150] The single sign-on system also includes:

[0151] The temporary authorization module is used to receive the temporary token request information, decrypt the temporary token request information to obtain the code of the subsystem and the local account, generate the corresponding temporary authorization token, and return the temporary authorization token to the subsystem;

[0152] The subsystem also includes:

[0153] The temporary authorization login module is used to receive the temporary authorization token and transmit the temporary authorization token to the user terminal so that the user terminal can use the temporary authorization token to log in to the single sign-on system.

[0154] The single sign-on system also includes:

[0155] The private token generation module is used to generate a unique private credential token based on the user information corresponding to the temporary authorization token used for login.

[0156] The user information caching module is used to cache the user information in Redis. The user information includes the local account and the single sign-on identifier corresponding to the code of the subsystem.

[0157] A public token generation module is used to encrypt the private credential token to generate a public login credential token;

[0158] A public token adding module is used to write the public login credential token into the browser cookie;

[0159] Furthermore, the subsystem also includes:

[0160] The user information request module is used to generate a user information request by encrypting the public login credential token and the code of the subsystem if the browser cookie contains a public login credential token, and then send the user information request to the single sign-on system.

[0161] The single sign-on system also includes:

[0162] The user information request module is used to receive the user information request, decrypt the user information request to obtain the code of the subsystem and the public login credential token, decrypt the public login credential token to obtain the private credential token, retrieve the corresponding user information from Redis according to the private credential token, and return the user information to the subsystem.

[0163] The subsystem also includes:

[0164] The shared login module is used to receive the user information and complete the passwordless login of the user based on the single sign-on identifier in the user information and the mapping relationship between the single sign-on identifier and the local account in the subsystem.

[0165] The heterogeneous system provided in this application implements distributed authentication. Subsystems can retain independent login authentication, and the failure of the single sign-on system does not affect the independent operation of the subsystems. A globally unique single sign-on identifier is mapped to the local account of each subsystem. Users can log in to any subsystem of the heterogeneous system and achieve seamless and unobtrusive login to other subsystems, avoiding the "account silo" problem of subsystems. The architecture is flexible and low-cost. Furthermore, the single sign-on system does not store sensitive information such as subsystem passwords. Layered encryption and a dual-token mechanism between subsystems and the single sign-on system effectively prevent data leakage and defend against network attacks. This achieves single sign-on for heterogeneous systems while ensuring subsystem data privacy and preventing protocol intrusion, effectively improving user experience and system security.

[0166] In one implementation, to enable user phone number modification, the subsystem of the heterogeneous system may further include:

[0167] The mobile number modification module is used to receive the user's request to modify the mobile number and obtain the new mobile number entered by the user;

[0168] The mobile phone number change module is used for the heterogeneous system to verify the new mobile phone number via SMS. If the SMS verification is successful, the new mobile phone number is associated with the user's local account registered in the subsystem, and the new mobile phone number, the local account, and the code of the subsystem are synchronized to the single sign-on system of the heterogeneous system.

[0169] The single sign-on system for heterogeneous systems also includes:

[0170] The query module is modified to receive the new mobile phone number synchronized by the subsystem, the local account, and the code of the subsystem, and to query whether there is a single sign-on identifier corresponding to the new mobile phone number;

[0171] The update module is used to generate a globally unique new single sign-on identifier based on the new mobile number if no single sign-on identifier corresponding to the new mobile number exists, replace the original mobile number with the new mobile number, and replace the original single sign-on identifier with the new single sign-on identifier. The original mobile number is the mobile number associated with the code of the local account and the subsystem before the generation of the new single sign-on identifier, and the original single sign-on identifier is the single sign-on identifier associated with the code of the local account and the subsystem before the generation of the new single sign-on identifier.

[0172] The notification module is used to notify all subsystems of the heterogeneous system to replace the original single sign-on identifier with the new single sign-on identifier and to replace the original mobile phone number with the new mobile phone number.

[0173] The subsystems of the heterogeneous system may further include:

[0174] The synchronization update module is used to replace the original single sign-on identifier stored locally with the new single sign-on identifier and the original mobile phone number with the new mobile phone number after receiving a modification notification from the single sign-on system.

[0175] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the system described above can be found in the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0176] It should be noted that the heterogeneous system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are only for distinguishing the various modules or steps and are not considered as an improper limitation of this application.

[0177] A third aspect of this application also provides a computing device cluster, the computing device cluster including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the method described above.

[0178] A fourth aspect of this application also provides a computer-readable storage medium storing computer instructions for execution by the computer to implement the method described above.

[0179] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the storage device and processing device described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0180] Those skilled in the art will recognize that the modules and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. The programs corresponding to the software modules and method steps can be placed in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art. To clearly illustrate the interchangeability of electronic hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in electronic hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the invention.

[0181] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system for implementing the methods, systems, and devices of this application. Figure 6 The server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0182] like Figure 6 As shown, the computer system includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in Read Only Memory (ROM) 602 or programs loaded from storage section 608 into Random Access Memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An Input / Output (I / O) interface 605 is also connected to the bus 604.

[0183] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0184] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0185] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0186] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0187] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0188] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0189] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A single sign-on method for heterogeneous systems, characterized in that, include: The subsystem of the heterogeneous system receives access requests from the user terminal; The subsystem queries whether the browser cookie corresponding to the access request contains a public login credential token. If the browser cookie does not contain a public login credential token, the subsystem initiates user login authentication and displays the user login interaction interface. The subsystem obtains the user's entered account or mobile number, checks whether the account or mobile number already exists, and if the account or mobile number does not exist, it determines that the user is logging in for the first time. The subsystem obtains the mobile phone number entered by the user during the initial login, performs SMS verification on the mobile phone number, and if the SMS verification is successful, associates the mobile phone number with the user's local account registered in the subsystem, and synchronizes the mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system. The single sign-on system receives the mobile phone number, the local account, and the code of the subsystem synchronized by the subsystem, queries whether there is a single sign-on identifier corresponding to the mobile phone number, if not, generates a globally unique single sign-on identifier based on the mobile phone number, associates the single sign-on identifier with the mobile phone number, the local account, and the code of the subsystem, and synchronizes the single sign-on identifier to the subsystem; If it exists, associate the single sign-on identifier with the local account and the code of the subsystem, and synchronize the single sign-on identifier to the subsystem; The subsystem receives the single sign-on identifier synchronized by the single sign-on system, establishes a mapping relationship between the single sign-on identifier and the local account, and stores the single sign-on identifier and the mapping relationship.

2. The method according to claim 1, characterized in that, The subsystem generates a first Kafka task, and through the first Kafka task, synchronizes the mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system; The single sign-on system generates a second Kafka task, which synchronizes the single sign-on identifier to the subsystem.

3. The method according to claim 1, characterized in that, Also includes: The subsystem of the heterogeneous system receives access requests from the user terminal; The subsystem queries whether the browser cookie corresponding to the access request contains a public login credential token. If the browser cookie does not contain a public login credential token, the subsystem initiates user login authentication. If the user login authentication is successful, the user has successfully logged into the subsystem. The subsystem generates a temporary token request information based on the subsystem's code and the user's local account in the subsystem, and sends the temporary token request information to the single sign-on system of the heterogeneous system. The single sign-on system receives the temporary token request information, decrypts the temporary token request information to obtain the code of the subsystem and the local account, generates the corresponding temporary authorization token, and returns the temporary authorization token to the subsystem; The subsystem receives the temporary authorization token, transmits the temporary authorization token to the user terminal, and the user terminal uses the temporary authorization token to log in to the single sign-on system; The single sign-on system generates a unique private credential token based on the user information corresponding to the temporary authorization token used for login, and caches the user information in Redis. The user information includes the local account and the single sign-on identifier corresponding to the code of the subsystem. The single sign-on system encrypts the private credential token to generate a public login credential token, and writes the public login credential token into the browser cookie.

4. The method according to claim 3, characterized in that, Also includes: The subsystem of the heterogeneous system receives access requests from the user terminal; The subsystem queries the browser cookie corresponding to the access request. If the browser cookie contains a public login credential token, it encrypts and generates a user information request based on the public login credential token and the subsystem's code, and sends the user information request to the single sign-on system. The single sign-on system of the heterogeneous system receives the user information request, decrypts the user information request to obtain the code of the subsystem and the public login credential token, decrypts the public login credential token to obtain the private credential token, retrieves the corresponding user information from Redis based on the private credential token, and returns the user information to the subsystem. The subsystem receives the user information and completes the passwordless login for the user based on the single sign-on identifier in the user information and the mapping relationship between the single sign-on identifier and the local account in the subsystem.

5. The method according to any one of claims 1-4, characterized in that, Also includes: The subsystem of the heterogeneous system receives the user's request to change the mobile phone number and obtains the new mobile phone number entered by the user; The subsystem verifies the new mobile number via SMS. If the SMS verification is successful, the new mobile number is associated with the user's local account registered in the subsystem, and the new mobile number, the local account, and the code of the subsystem are synchronized to the single sign-on system of the heterogeneous system. The single sign-on system receives a new mobile phone number synchronized by the subsystem, the local account, and the code of the subsystem. It queries whether there is a single sign-on identifier corresponding to the new mobile phone number. If not, it generates a globally unique new single sign-on identifier based on the new mobile phone number, replaces the original mobile phone number with the new mobile phone number, and replaces the original single sign-on identifier with the new single sign-on identifier. The original mobile phone number is the mobile phone number associated with the local account and the code of the subsystem before the generation of the new single sign-on identifier. The original single sign-on identifier is the single sign-on identifier associated with the local account and the code of the subsystem before the generation of the new single sign-on identifier. The single sign-on system notifies all subsystems of the heterogeneous system to replace the original single sign-on identifier with the new single sign-on identifier and to replace the original mobile phone number with the new mobile phone number.

6. A heterogeneous system, characterized in that, Includes a single sign-on system and at least one subsystem: The subsystem includes: The cookie query module is used to receive access requests from users and query whether the browser cookie corresponding to the access request contains a public login credential token. The subsystem login module is used to initiate user login authentication of the subsystem, display the user login interaction interface, obtain the user's entered account or mobile phone number, query whether the account or mobile phone number already exists, and determine that the user is logging in for the first time if the account or mobile phone number does not exist. The mobile phone number verification module is used to obtain the mobile phone number entered by the user during the initial login and to verify the mobile phone number via SMS. The first association module is used to associate the mobile phone number with the user's local account registered in the subsystem if the SMS verification is successful. The first synchronization module is used to synchronize the mobile phone number, the local account, and the code of the subsystem to the single sign-on system of the heterogeneous system. The single sign-on system includes: The single sign-on identifier generation module is used to receive the mobile phone number, the local account and the code of the subsystem synchronized by the subsystem, query whether there is a single sign-on identifier corresponding to the mobile phone number, and if not, generate a globally unique single sign-on identifier based on the mobile phone number; The second association module is used to associate the single sign-on identifier with the mobile phone number, the local account, and the code of the subsystem; The second synchronization module is used to synchronize the single sign-on identifier to the subsystem; The subsystem also includes: The mapping module is used to receive the single sign-on identifier synchronized by the single sign-on system, establish a mapping relationship between the single sign-on identifier and the local account, and store the single sign-on identifier and the mapping relationship.

7. The heterogeneous system according to claim 6, characterized in that, The cookie query module is used to receive access requests from users and query whether the browser cookie corresponding to the access request contains a public login credential token. The subsystem login module is used to initiate user login authentication of the subsystem if the browser cookie does not contain a public login credential token. The subsystem also includes: The temporary authorization request module is used to generate a temporary token request information by encrypting the code of the subsystem and the user's local account in the subsystem if the user login authentication is successful, and send the temporary token request information to the single sign-on system of the heterogeneous system. The single sign-on system also includes: The temporary authorization module is used to receive the temporary token request information, decrypt the temporary token request information to obtain the code of the subsystem and the local account, generate the corresponding temporary authorization token, and return the temporary authorization token to the subsystem; The subsystem also includes: The temporary authorization login module is used to receive the temporary authorization token and transmit the temporary authorization token to the user terminal so that the user terminal can use the temporary authorization token to log in to the single sign-on system. The single sign-on system also includes: The private token generation module is used to generate a unique private credential token based on the user information corresponding to the temporary authorization token used for login. The user information caching module is used to cache the user information in Redis. The user information includes the local account and the single sign-on identifier corresponding to the code of the subsystem. A public token generation module is used to encrypt the private credential token to generate a public login credential token; The public token adding module is used to write the public login credential token into the browser cookie.

8. The heterogeneous system according to claim 7, characterized in that, The subsystem includes: a cookie query module, used to receive access requests from users and query whether the browser cookie corresponding to the access request contains a public login credential token; The subsystem also includes: The user information request module is used to generate a user information request by encrypting the public login credential token and the code of the subsystem if the browser cookie contains a public login credential token, and then send the user information request to the single sign-on system. The single sign-on system also includes: The user information request module is used to receive the user information request, decrypt the user information request to obtain the code of the subsystem and the public login credential token, decrypt the public login credential token to obtain the private credential token, retrieve the corresponding user information from Redis according to the private credential token, and return the user information to the subsystem. The subsystem also includes: The shared login module is used to receive the user information and complete the passwordless login of the user based on the single sign-on identifier in the user information and the mapping relationship between the single sign-on identifier and the local account in the subsystem.

9. A computing device cluster, characterized in that, The system includes at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-5.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are executed by the computer to implement the method as described in any one of claims 1-5.

Images