Plug and play OAuth2 single sign-on authentication service system and method

Abstract

The application relates to the technical field of single sign-on, in particular to a plug-and-play OAuth2 single sign-on authentication service system and method, which comprises the following steps: redirecting to a client according to a login address carrying an authorization code preset by the client; after receiving the authorization code, automatically calling a token interface of an authentication center system to obtain an OAuth2 token, calling a token generation interface provided by an original system by a plug-in client jar package, and obtaining an original system token based on user information in the OAuth2 token; the plug-in client jar package establishes a bidirectional mapping relationship between an OAuth2 access token and an original system access token and between an OAuth2 refresh token and an original system refresh token, and stores the tokens in Redis; and when the OAuth2 token state changes, synchronously updating the original system token state based on the mapping relationship in Redis. The method does not need to make large-scale modification on an existing business system, and reduces integration cost and development difficulty.

Description

Technical Field

[0001] This application relates to the field of single sign-on technology, specifically to a plug-and-play OAuth2 single sign-on authentication service system and method. Background Technology

[0002] OAuth 2, as a widely adopted open standard for authorization, plays a crucial role in the internet application ecosystem. Its core mechanism allows third-party applications to securely access user data stored in specific services without the application's direct involvement in managing these resources. This process is achieved through a delegated authentication model, where the third-party application initiates an authorization request to the user, and upon the user's permission, temporarily gains the right to read or write relevant user data. This authorization model not only ensures the security and privacy of user data but also provides third-party applications with a convenient resource access method, promoting interconnectivity and collaborative work between different applications.

[0003] In current application implementations, when an application needs to interface with an authentication center or modify an existing authentication center to support OAuth 2 authorization processes, it often faces complex code adjustments and configuration work. Due to potential differences in the implementation details of the OAuth 2 standard among different authentication centers, as well as the diversity of application architecture and business logic, developers need to thoroughly understand the authentication center's interface specifications, security mechanisms, and other aspects, and make targeted modifications and optimizations to the application code. This not only increases the workload and complexity of development but also easily leads to code redundancy and difficulty in maintenance, adversely affecting the stability and scalability of existing applications.

[0004] Traditional single sign-on (SSO) transformation methods typically require large-scale modifications to the application's code and login logic. Such extensive code modifications not only consume significant time and effort but also easily introduce new errors and vulnerabilities, posing potential risks to the normal operation of the application. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a plug-and-play OAuth2 single sign-on authentication service system and method that enables synchronous refreshing of the OAuth2 single sign-on token without altering the original system's token-related logic, allowing users to maintain their login status seamlessly.

[0006] In a first aspect, the technical solution of the present invention provides a plug-and-play OAuth2 single sign-on authentication service system, including an authentication center system and a pluggable client jar package;

[0007] The authentication center system is used for:

[0008] Receive login requests initiated by client applications, verify the validity of client credentials, and check whether there are valid single sign-on credentials in cookies;

[0009] Generate OAuth2 tokens for the OAuth2 protocol. OAuth2 tokens include access tokens and refresh tokens. When a refresh token request is received, the validity of the old refresh token is verified and a new token is issued. The expiration time of the single sign credential is extended simultaneously.

[0010] The pluggable client JAR package enables interaction with the authentication center system by importing the JAR package and YAML configuration file, specifically for:

[0011] Read the parameters from the YAML configuration file. These parameters include at least the authentication center address, client identifier, client key, login address, logout address, and token storage timeout.

[0012] Obtain an OAuth2 token through the configured authentication center address; call the token generation interface provided by the original system to which single sign-on is to be integrated to obtain the original system token;

[0013] A mapping relationship is established between the OAuth2 token and the original system token and stored in Redis. Based on the mapping relationship in Redis, the original system token is refreshed synchronously when the OAuth2 token is refreshed, and the corresponding original system token is invalidated synchronously when the OAuth2 token expires or the user logs out. The original system is the existing business system that needs to be integrated with single sign-on. When the pluggable client jar package calls the token generation interface of the original system, it passes the user information extracted from the OAuth2 token.

[0014] The client application obtains user information and permissions through a pluggable client JAR package to complete the single sign-on process, achieving OAuth2 single sign-on compatibility without changing the original system's token logic.

[0015] Using a pluggable client JAR file and YAML configuration file, applications only need to import the JAR file and configure the relevant parameters to integrate with the authentication center system, without requiring extensive modifications to existing application code. By establishing a mapping relationship between OAuth2 tokens and the original system tokens, the system can implement OAuth2 single sign-on without changing the original system token logic, ensuring system stability and compatibility. Using Redis to store the token mapping relationship ensures the security of token information and high-performance access, making it suitable for distributed systems and high-concurrency scenarios.

[0016] As a further limitation of the technical solution of the present invention, the authentication center system includes an authentication verification module and an authorization code management module;

[0017] The authentication and verification module is used to receive login requests from client applications, verify the legality of the client identifier and client key, and check whether there is a valid single sign-on credential in the cookie. If there is no valid single sign-on credential, the user is redirected to the unified login page. After the user enters authentication information through the unified login page, the user's identity is verified. After the user's identity is verified, a single sign-on credential is created and stored in the cookie and local cache. At the same time, the expiration time of the single sign-on credential is refreshed. If a valid single sign-on credential exists, the authorization code management module is triggered directly.

[0018] The authorization code management module is used to generate authorization codes based on single-point credentials and client identifiers and store them in a local cache. It redirects the authorization code to the client according to the client's preset login address. When receiving a token request, it verifies the legality of the authorization code and its matching with the client identifier. After the verification is successful, the authorization code is invalidated to ensure one-time use.

[0019] The authentication and verification module receives login requests from client applications, rigorously verifies the legitimacy of the client identifier and client key, and checks for the existence of a valid single sign-on credential in the cookie. This process ensures that only legitimate clients can initiate login requests, effectively preventing unauthorized access. If a valid single sign-on credential does not exist, the module redirects the user to a unified login page for identity verification. Upon successful verification, a single sign-on credential is created, providing users with a convenient login method. The authorization code management module generates and stores authorization codes based on the single sign-on credential and client identifier. It then redirects the user to the client with the authorization code at the client's preset login address. When receiving a token request, the module rigorously verifies the legitimacy of the authorization code and its match with the client identifier, ensuring that the authorization code is for one-time use and effectively preventing the abuse of authorization codes and security risks.

[0020] As a further limitation of the technical solution of the present invention, the authentication center system also includes a token issuance module, which is used to receive a token request from a client carrying an authorization code, and after verifying the legality of the client identifier and the authorization code and the validity of the single sign credential, generate an OAuth2 token containing an access token, a refresh token and user information, establish an association between the single sign credential and the OAuth2 token and store it in a cache; when receiving a refresh token request, after verifying the legality of the old refresh token, issue a new token and simultaneously extend the expiration time of the single sign credential.

[0021] When receiving a token request from a client carrying an authorization code, this module not only verifies the validity of the client identifier and authorization code but also checks the validity of the single sign-on credential, ensuring the security and reliability of the generated OAuth2 token. The generated OAuth2 token contains an access token, a refresh token, and user information, providing the necessary credentials for users to access protected resources. Simultaneously, the module establishes an association between the single sign-on credential and the OAuth2 token and stores it in a cache for convenient subsequent token management and retrieval. Upon receiving a refresh token request, it promptly verifies the validity of the old refresh token before issuing a new token and simultaneously extends the expiration time of the single sign-on credential, ensuring the continuity and security of user sessions.

[0022] As a further limitation of the technical solution of the present invention, the authentication center system also includes a logout synchronization module, which is used to delete all associated token information in the cache based on the single sign credential when receiving a logout request, traverse and call the client's preset logout address to synchronize the logout status, and clear the single sign credential in the cookie.

[0023] When the authentication center system receives a logout request, this module deletes all associated token information from the cache based on the single sign-on credential, ensuring that all tokens for the user in the current session are invalid, preventing user information leakage and unauthorized access. Simultaneously, the module iterates through and calls the client's preset logout addresses to synchronize the logout status, ensuring that all systems connected to single sign-on can update the user's status in a timely manner, guaranteeing consistent logout across different systems. Finally, it clears the single sign-on credential from the cookie, completely ending the user session and providing a secure and reliable logout experience.

[0024] As a further limitation of the technical solution of the present invention, the pluggable client jar package includes a configuration parsing module and a token acquisition module;

[0025] Configure the parsing module to read parameters from the YAML configuration file;

[0026] The token acquisition module is specifically used to automatically assemble the login URL based on configuration parameters and initiate a login request. After receiving the authorization code returned by the authorization code management module through redirection, it automatically calls the token interface of the authentication center system to obtain the OAuth2 token and stores it in the cache.

[0027] The configuration parsing module and token acquisition module in the pluggable client JAR package work together to achieve efficient interaction with the authentication center system. The configuration parsing module reads parameters from the YAML configuration file, providing the necessary configuration information for the pluggable client JAR package to connect with the authentication center system, enabling the pluggable client JAR package to quickly adapt to different network environments and system requirements. The token acquisition module automatically assembles the login URL based on the configuration parameters and initiates a login request. After receiving the authorization code returned by the authorization code management module through redirection, it automatically calls the authentication center system's token interface to obtain the OAuth2 token and stores it in the cache, simplifying the client's token acquisition process and improving development efficiency and system usability.

[0028] As a further limitation of the technical solution of the present invention, the pluggable client jar package also includes the original system interaction module, the token mapping module and the token synchronization module;

[0029] The original system interaction module is used to call the token generation interface provided by the original system to be connected to the single sign-on, trigger the creation of the original system token based on the user information returned by the authentication center system, and obtain the original system access token and refresh token.

[0030] The token mapping module is used to establish a mapping relationship between the original system refresh token and the OAuth2 refresh token and store it in Redis; and to establish a mapping relationship between the OAuth2 access token and the original system access token and store it in Redis.

[0031] The token synchronization module is used to synchronously trigger the original system token refresh when the OAuth2 token is refreshed, based on the mapping relationship in Redis, and synchronously invalidate the corresponding original system token when the OAuth2 token expires or the user logs out.

[0032] The introduction of the original system interaction module and the token mapping module enables the pluggable client JAR package to better integrate with the original system to which single sign-on is to be integrated. The original system interaction module is responsible for calling the token generation interface provided by the original system, triggering the creation of the original system token based on the user information returned by the authentication center system, and obtaining the original system access token and refresh token, thus realizing the transfer of user information and token generation between different systems. The token mapping module establishes the mapping relationship between the original system refresh token and the OAuth2 refresh token, and between the OAuth2 access token and the original system access token, and stores it in Redis. This provides the foundation for token management and synchronization between different systems, ensuring the consistency and accuracy of token status throughout the single sign-on environment.

[0033] As a further limitation of the technical solution of the present invention, the mapping relationship includes:

[0034] The first key-value pair: uses the original system refresh token as the key and the OAuth2 refresh token as the value;

[0035] The second key-value pair: uses the OAuth2 access token as the key and the original system access token as the value.

[0036] The system defines a first key-value pair with the OAuth2 refresh token as the value, and a second key-value pair with the OAuth2 access token as the key and the original system access token as the value. This clear mapping allows the pluggable client JAR package to quickly and accurately locate the corresponding token when handling token synchronization and update operations between different systems, improving system processing efficiency and reliability. It also facilitates system maintenance and expansion, making it easier for developers to understand and operate.

[0037] Secondly, the present invention also provides a plug-and-play OAuth2 single sign-on authentication service method applicable to the system described in the first aspect, comprising the following steps:

[0038] S1. The client application initiates a login request through a pluggable client jar package. The pluggable client jar package reads parameters from the YAML configuration file. The parameters include at least the authentication center address, client identifier, client key, login address, logout address, and token storage timeout.

[0039] S2. The authentication center system receives the login request, verifies the validity of the client identifier and client key, and checks whether there is a valid single sign credential in the cookie;

[0040] If no valid single sign-on credential exists, the user will be redirected to the unified login page. After entering authentication information on the unified login page, the authentication center system will verify the user's identity. If the verification is successful, a single sign-on credential will be created and stored in a cookie and local cache.

[0041] If a valid single sign-on credential exists, an authorization code will be generated directly based on that single sign-on credential.

[0042] S3. The authentication center system redirects the client with the authorization code based on the client's preset login address;

[0043] S4. After receiving the authorization code, the pluggable client jar package automatically calls the token interface of the authentication center system to obtain the OAuth2 token, which includes an access token and a refresh token.

[0044] S5. The pluggable client jar package calls the token generation interface provided by the original system to obtain the original system token based on the user information in the OAuth2 token;

[0045] S6. The pluggable client jar package establishes a two-way mapping relationship between the OAuth2 access token and the original system access token, and between the OAuth2 refresh token and the original system refresh token, and stores it in Redis;

[0046] S7. When the OAuth2 token status changes, the pluggable client JAR package synchronously updates the original system token status based on the mapping relationship in Redis.

[0047] The client application initiates a login request via a pluggable client JAR package, reads configuration parameters, and prepares for subsequent interaction with the authentication center system. The authentication center system verifies and processes the login request, guiding the user to perform appropriate actions based on the existence of a valid single sign-on credential, ensuring the security and legitimacy of the login process. After generating an authorization code and redirecting it to the client, the pluggable client JAR package automatically obtains an OAuth2 token, calls the original system's interface to obtain the original system's token, and finally establishes a two-way mapping relationship and stores it in Redis. The entire method is clear and logically rigorous, enabling seamless login between different systems and improving user experience and work efficiency.

[0048] As a further limitation of the technical solution of the present invention, in S7, the OAuth2 token state change includes:

[0049] When an OAuth2 access token expires, the pluggable client JAR package invalidates the corresponding original system access token based on the mapping relationship.

[0050] When the OAuth2 refresh token is refreshed, the pluggable client JAR package triggers the original system refresh token update based on the mapping relationship.

[0051] When the OAuth2 token state changes, this method can synchronously update the original system token state according to the mapping relationship. When the OAuth2 access token expires, the pluggable client JAR package can invalidate the corresponding original system access token according to the mapping relationship, avoiding the security risks caused by users accessing the system with expired tokens. When the OAuth2 refresh token is refreshed, the pluggable client JAR package can trigger the original system refresh token update according to the mapping relationship, ensuring that the original system token and the OAuth2 token are consistent in state, providing users with continuous and stable access services. This synchronous update mechanism ensures the consistency and accuracy of the token state throughout the single sign-on environment, improving the security and reliability of the system.

[0052] As a further limitation of the technical solution of the present invention, the method also includes a logout synchronization step:

[0053] After receiving a logout request, the authentication center system deletes all associated token information from the cache based on the single sign-on credential.

[0054] Iterate through and call the client's preset logout addresses to synchronize the logout status;

[0055] Clear single sign-on credentials from cookies.

[0056] Upon receiving a logout request, the authentication center system deletes all associated token information from the cache based on the single sign-on credential to prevent user information leakage and unauthorized access. It then iterates through and calls the client's preset logout addresses to synchronize the logout status, enabling the original system to promptly recognize that the user has logged out and terminate the user session. Finally, it clears the single sign-on credential from the cookie, completely ending the user's login state in the current session. This series of operations ensures the thoroughness and consistency of user logout, improving system security and user experience.

[0057] As a further limitation of the technical solution of the present invention, the mapping relationship established in S6 includes:

[0058] The first key-value pair: uses the original system refresh token as the key and the OAuth2 refresh token as the value;

[0059] The second key-value pair: uses the OAuth2 access token as the key and the original system access token as the value.

[0060] As can be seen from the above technical solutions, this application has the following advantages: The authentication center system is responsible for uniformly processing login requests, verifying client credentials, generating and managing OAuth2 tokens, and other core authentication and authorization operations, providing stable and reliable backend support for the entire single sign-on process. The pluggable client JAR package achieves seamless interaction with the authentication center system through simple import and configuration, without requiring large-scale modifications to existing business systems, thus reducing integration costs and development difficulty.

[0061] This system generates OAuth2 tokens containing access and refresh tokens, and simultaneously extends the expiration time of single sign-on credentials when refreshing the token, ensuring the continuity and security of user sessions. Meanwhile, a pluggable client JAR package can establish a mapping relationship between OAuth2 tokens and the original system tokens and store them in Redis, enabling effective management and synchronization of tokens across different systems. When an OAuth2 token is refreshed or expires, the corresponding operation on the original system token is triggered synchronously, ensuring the consistency of token status throughout the single sign-on environment and providing users with a smooth and secure single sign-on experience. Attached Figure Description

[0062] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 This is a system block diagram of the system according to an embodiment of the present invention.

[0064] Figure 2 This is a flowchart illustrating the method provided in an embodiment of the present invention. Detailed Implementation

[0065] To make the purpose, features, and advantages of this application more apparent and understandable, specific embodiments and accompanying drawings will be used to clearly and completely describe the technical solution protected by this application. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0066] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this application and in the specification of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0067] like Figure 1 As shown, this embodiment of the invention provides a plug-and-play OAuth2 single sign-on authentication service system, including an authentication center system and a pluggable client JAR package;

[0068] The authentication center system is used for:

[0069] Receive login requests initiated by client applications, verify the validity of client credentials, and check whether there are valid single sign-on credentials in cookies;

[0070] The client application sends a login request to the authentication center system, carrying the following information in the request:

[0071] Client ID (client_id): Uniquely identifies the client application.

[0072] Client secret: A secret key used by the client application to verify the client's identity.

[0073] Redirect address (redirect_uri): The address to which you are redirected after successful login.

[0074] Authorization type (grant_type): such as authorization_code, refresh_token, etc.

[0075] After receiving the request, the authentication center system parses the request parameters and extracts the client identifier (client_id) and client key. The system then queries the database or configuration file for the client information corresponding to the client identifier. For example, it queries the `clients` table in the database to check if a record matching the `client_id` in the request exists. The system retrieves the client key from the database or configuration file and compares it with the `client_secret` carried in the request. If the keys do not match, an exception is thrown. The system ensures that the `redirect_uri` in the request matches the redirect address provided during client registration. It also ensures that the `grant_type` in the request is an authorization type supported by the authentication center system. If the client identifier and key verification succeed, the subsequent authentication process continues. If verification fails, an error message is returned indicating that the client credentials are invalid.

[0076] Generate OAuth2 tokens for the OAuth2 protocol, including access tokens and refresh tokens. When a refresh token request is received, verify the validity of the old refresh token and issue a new token, and simultaneously extend the expiration time of the single sign credential.

[0077] It should be noted here that the client sends a request containing a refresh token to the authorization server. This request typically includes the following parameters:

[0078] grant_type: The fixed value refresh_token indicates that the request type is a refresh token.

[0079] refresh_token: The old refresh token.

[0080] client_id: Client identifier.

[0081] client_secret: Client key (if needed).

[0082] First, verify the validity of the `client_id` and `client_secret` in the request. This step ensures the request was initiated by a legitimate client. Check if the `refresh_token` in the request exists in the cache. If the refresh token does not exist, return an error immediately. Refresh tokens typically have a long validity period, but they can still expire. It's necessary to check if the refresh token has expired. Even if the refresh token has not expired, it may be revoked for security reasons. It's necessary to check if the refresh token has been revoked. Refresh tokens are usually associated with a specific client. It's necessary to verify that the `client_id` in the request matches the client associated with the refresh token. If the refresh token is valid, generate a new access token (`access_token`) and possibly a new refresh token (`refresh_token`). If the refresh token is invalid (expired, revoked, or does not match the client), return an error message informing the client that the refresh token is invalid.

[0083] The pluggable client JAR package enables interaction with the authentication center system by importing the JAR package and YAML configuration file, specifically for:

[0084] Read the parameters from the YAML configuration file. These parameters include at least the authentication center address, client identifier, client key, login address, logout address, and token storage timeout.

[0085] Obtain an OAuth2 token through the configured authentication center address; call the token generation interface provided by the original system to which single sign-on is to be integrated to obtain the original system token;

[0086] A mapping relationship is established between the OAuth2 token and the original system token and stored in Redis. Based on the mapping relationship in Redis, the original system token is refreshed synchronously when the OAuth2 token is refreshed, and the corresponding original system token is invalidated synchronously when the OAuth2 token expires or the user logs out. The original system is the existing business system that needs to be integrated with single sign-on. When the pluggable client jar package calls the token generation interface of the original system, it passes the user information extracted from the OAuth2 token.

[0087] The client application obtains user information and permissions through a pluggable client JAR package to complete the single sign-on process, achieving OAuth2 single sign-on compatibility without changing the original system's token logic.

[0088] In some embodiments, the certification center system includes an authentication verification module and an authorization code management module;

[0089] The authentication and verification module is used to receive login requests from client applications, verify the legality of the client identifier and client key, and check whether there is a valid single sign-on credential in the cookie. If there is no valid single sign-on credential, the user is redirected to the unified login page. After the user enters authentication information through the unified login page, the user's identity is verified. After the user's identity is verified, a single sign-on credential is created and stored in the cookie and local cache. At the same time, the expiration time of the single sign-on credential is refreshed. If a valid single sign-on credential exists, the authorization code management module is triggered directly.

[0090] It should be noted here that users enter the following authentication information on the unified login page:

[0091] Username, password, and other optional information (such as verification codes, two-factor authentication, etc.); The authentication center system receives the form data submitted by the user and parses out the username and password. The authentication center system queries the user database to see if a user record matching the username exists. It compares the user's entered password with the password stored in the database. Passwords are usually stored in encrypted form (e.g., using BCrypt encryption). It ensures the user account is active and not disabled or locked. It ensures the user account has not expired. It ensures the user's password or other credentials have not expired. If user authentication is successful, it generates user context information, including user ID, username, role information, etc. It creates a single sign-on credential (TGT) and stores it in the local cache and cookies. If user authentication is successful, it returns an authentication success message and redirects the user to the authorization page or returns an authorization code. If user authentication fails, it returns an authentication failure message.

[0092] The authorization code management module is used to generate authorization codes based on single-point credentials and client identifiers and store them in a local cache. It redirects the authorization code to the client according to the client's preset login address. When receiving a token request, it verifies the legality of the authorization code and its matching with the client identifier. After the verification is successful, the authorization code is invalidated to ensure one-time use.

[0093] In some embodiments, the authentication center system further includes a token issuance module, which receives a token request from a client carrying an authorization code, and after verifying the legality of the client identifier and authorization code and the validity of the single sign credential, generates an OAuth2 token containing an access token, a refresh token and user information, establishes an association between the single sign credential and the OAuth2 token and stores it in a cache; when receiving a refresh token request, it verifies the legality of the old refresh token and issues a new token, and simultaneously extends the expiration time of the single sign credential.

[0094] In some embodiments, the authentication center system further includes a logout synchronization module, which, upon receiving a logout request, deletes all associated token information in the cache based on the single sign credential, iterates through and calls the client's preset logout address to synchronize the logout status, and clears the single sign credential in the cookie.

[0095] In some embodiments, the pluggable client JAR package includes a configuration parsing module and a token acquisition module;

[0096] Configure the parsing module to read parameters from the YAML configuration file;

[0097] The token acquisition module is specifically used to automatically assemble the login URL based on configuration parameters and initiate a login request. After receiving the authorization code returned by the authorization code management module through redirection, it automatically calls the token interface of the authentication center system to obtain the OAuth2 token and stores it in the cache.

[0098] The configuration parsing module and token acquisition module in the pluggable client JAR package work together to achieve efficient interaction with the authentication center system. The configuration parsing module reads parameters from the YAML configuration file, providing the necessary configuration information for the pluggable client JAR package to connect with the authentication center system, enabling the pluggable client JAR package to quickly adapt to different network environments and system requirements. The token acquisition module automatically assembles the login URL based on the configuration parameters and initiates a login request. After receiving the authorization code returned by the authorization code management module through redirection, it automatically calls the authentication center system's token interface to obtain the OAuth2 token and stores it in the cache, simplifying the client's token acquisition process and improving development efficiency and system usability.

[0099] In some embodiments, the pluggable client jar package also includes the original system interaction module and the token mapping module;

[0100] The original system interaction module is used to call the token generation interface provided by the original system to be connected to the single sign-on, trigger the creation of the original system token based on the user information returned by the authentication center system, and obtain the original system access token and refresh token.

[0101] The token mapping module is used to establish a mapping relationship between the original system refresh token and the OAuth2 refresh token and store it in Redis; it also establishes a mapping relationship between the OAuth2 access token and the original system access token and stores it in Redis.

[0102] The pluggable client JAR package seamlessly integrates with the original business system that needs to implement single sign-on, through the original system's interaction module. Simultaneously, it utilizes Redis to store the mapping between OAuth2 tokens and the original system's tokens, ensuring the security and efficient access of token information.

[0103] In some embodiments, the pluggable client jar package also includes a token synchronization module, which is used to synchronously trigger the original system token refresh when the OAuth2 token is refreshed based on the mapping relationship in Redis, and synchronously invalidate the corresponding original system token when the OAuth2 token expires or logs out.

[0104] In some embodiments, the mapping relationship includes:

[0105] The first key-value pair: uses the original system refresh token as the key and the OAuth2 refresh token as the value;

[0106] The second key-value pair: uses the OAuth2 access token as the key and the original system access token as the value.

[0107] The two-way mapping relationship ensures synchronized updates between OAuth2 tokens and the original system tokens, improving system flexibility and compatibility. The explicit key-value pair relationship ensures the security and consistency of token information.

[0108] like Figure 2 As shown, this embodiment of the invention also provides a plug-and-play OAuth2 single sign-on authentication service method applied to the system described in the above embodiments, including the following steps:

[0109] S1. The client application initiates a login request through a pluggable client jar package. The pluggable client jar package reads parameters from the YAML configuration file. The parameters include at least the authentication center address, client identifier, client key, login address, logout address, and token storage timeout.

[0110] In this step, the client application includes the pluggable client JAR dependency in its project's pom.xml file. This allows for functional integration without modifying the original business code, simply by including the dependency.

[0111] The client application fills in the single sign-on parameters in the application.yaml configuration file, specifically including: server_url:http: / / server.com:8080#authentication center address;

[0112] client_id:xoox8# Client identifier (a unique identifier registered with the certification center);

[0113] client_secret:E-PCvq5Fa3pkt4SbPH8tdXsSDd#Client key;

[0114] login_url: http: / / demo.com / auth / login#client login address;

[0115] logout_url: http: / / demo.com / oauth / logout# Client logout callback address;

[0116] token_timeout:2400 # Token storage timeout (seconds);

[0117] When a user enters a URL in the client application frontend, the client frontend detects that there is no valid access_token in localStorage, calls the SSOUtils.buildLoginUrl(redirect_uri) method in the pluggable client JAR package, automatically assembles the login URL based on parameters such as server_url and client_id configured in YAML, and initiates a login request.

[0118] S2. The authentication center system receives the login request, verifies the validity of the client identifier and client key, and checks whether there is a valid single sign credential in the cookie;

[0119] If no valid single sign-on credential exists, the user will be redirected to the unified login page. After entering authentication information on the unified login page, the authentication center system will verify the user's identity. If the verification is successful, a single sign-on credential will be created and stored in a cookie and local cache.

[0120] If a valid single sign-on credential exists, an authorization code will be generated directly based on that single sign-on credential.

[0121] In this step, after receiving the login request, the authentication verification module of the authentication center system first queries the database for registered client information using applicationMapper.selectOne("app_code",client_id) to verify whether the client_secret corresponding to client_id is consistent with the key carried in the request, thus ensuring the legitimacy of the client.

[0122] The authentication center checks the request cookie for a valid single sign-on credential (TGT) using the `AbstractTicketGrantingTicketManager.get(request)` method.

[0123] If no valid TGT is found, the user is redirected to the unified login page of the authentication center (e.g., http: / / server.com:8080 / sso / loginPage). After the user enters their username, password, and other authentication information, the authentication center calls userService.validateLogin(loginVO) to verify the user's identity. If the verification is successful, a TGT is generated using AbstractTicketGrantingTicketManager.create(token_user). The TGT is stored in a cookie (with the configured cookieName as the key) and a local cache (e.g., Redis), and an expiration time is set (specified by the timeout parameter configured by the authentication center, e.g., 43800 seconds).

[0124] If a valid TGT exists, it can be reused directly without requiring the user to log in again, and the authorization code generation process can begin.

[0125] S3. The authentication center system redirects the client with the authorization code based on the client's preset login address;

[0126] The authorization code management module of the authentication center generates an authorization code (e.g., Code-123e4567e89b12d3a456) based on the currently valid TGT and client_id, using the "Code- + UUID string extraction" format. The associated information (CodeContent) of the code, TGT, and client_id is stored in a local cache with an expiration time (e.g., 5 minutes) to ensure timeliness. The authentication center queries the preset front-end callback address (e.g., http: / / demo.com / callback) for the client_id using applicationMapper, appends the generated code to the callback address, and redirects the application to the client application.

[0127] S4. After receiving the authorization code, the pluggable client jar package automatically calls the token interface of the authentication center system to obtain the OAuth2 token, which includes an access token and a refresh token.

[0128] After receiving the code, the callback interface of the pluggable client JAR package automatically calls the `SSOUtils.getHttpAccessToken(code)` method. Based on the `server_url`, `client_id`, and `client_secret` configured in the YAML file, it assembles a token request URL and sends a token request to the authentication center. Upon receiving the request, the authentication center's token issuing module performs triple verification:

[0129] Verify the match between client_id and client_secret;

[0130] Verify that the CodeContent corresponding to the code exists and that the client_id matches. After verification, delete the code to ensure it is used only once.

[0131] Verify that the TGT is valid (not expired and associated user information exists).

[0132] After successful verification, an OAuth2 token object is generated, containing an access token (formatted as server_at_ + random string), a refresh token (formatted as server_rt_ + random string), and detailed user information (token_user, including userId, userName, and nickname). This object is then stored in Redis using the RedisTokenManager.create() method.

[0133] The access_token key format is: server_at_ + access_token value, associated with the refresh_token storage;

[0134] The refresh_token key format is: server_rt_ + refresh_token value, associated with the storage token_content (including TGT, user information, and logout_url);

[0135] Establish the association between TGT and refresh_token, with the key format: server_tgt_rt_+TGT value, for batch management of tokens.

[0136] The authentication center returns the generated OAuth2 token to the client's JAR file, and the client stores the token in its local cache using tokenStorage.create(token).

[0137] S5. The pluggable client jar package calls the token generation interface provided by the original system to obtain the original system token based on the user information in the OAuth2 token;

[0138] The original system interaction module of the pluggable client JAR package calls the token generation interface provided by the original system (such as adminAuthService.createTokenAfterOauthCallback), extracts user information such as userId and userName from the token_user of the OAuth2 token, and passes it to the interface, triggering the original system's own token generation process. The original system generates its own token (including the original system access_token and refresh_token) based on its own authentication logic and returns it to the pluggable client JAR package through the interface, for example, returning an AuthLoginRespVO object containing the original system token information.

[0139] S6. The pluggable client jar package establishes a two-way mapping relationship between the OAuth2 access token and the original system access token, and between the OAuth2 refresh token and the original system refresh token, and stores it in Redis;

[0140] The token mapping module of the pluggable client JAR package establishes and stores a two-way mapping relationship in Redis through stringRedisTemplate, specifically including:

[0141] First key-value pair (original system refresh token → OAuth2 refresh token):

[0142] Key format: refresh_token_mapping:+original system refresh_token, the value is the OAuth2 refresh_token returned by the authentication center; for example: refresh_token_mapping:sys_rt_123→oauth_rt_456, used to refresh the OAuth2 token synchronously when the original system refreshes the token.

[0143] Second key-value pair (OAuth2 access token → original system access token):

[0144] Key format: access_token_mapping:+OAuth2 access_token, value is the original system access_token; for example: access_token_mapping:oauth_at_789→sys_at_012, used to synchronize the invalidation of the original system token when the OAuth2 token expires.

[0145] The storage duration of the mapping relationship is consistent with the expiration time of the corresponding token (e.g., refresh_token expiration time + 600-second buffer) to ensure that the mapping relationship expires synchronously with the token.

[0146] S7. When the OAuth2 token status changes, the pluggable client JAR package synchronously updates the original system token status based on the mapping relationship in Redis.

[0147] When the client application detects that the OAuth2 access_token has expired (e.g., the business request returns a 401 status code), the client JAR package obtains the current access_token through SSOUtils.getAccessToken(), and queries the corresponding original system access_token based on the second key-value pair access_token_mapping:+OAuth2 access_token; it then calls the original system's token invalidation interface to make the original system token expire synchronously, preventing users from accessing the system with expired tokens.

[0148] When an OAuth2 access token expires and needs to be refreshed, the client JAR file calls the `SSOUtils.getHttpRefreshToken(refresh_token)` method to send a refresh request to the certification authority using the locally stored OAuth2 refresh token. After verifying the validity of the old refresh token, the certification authority generates a new access token and refresh token and returns them, while extending the TGT expiration time. After receiving the new token, the client JAR file queries the corresponding old OAuth2 refresh token based on the first key-value pair `refresh_token_mapping:+original system refresh_token`, deletes the old mapping relationship, calls the original system's token refresh interface, passes in the original system refresh token to obtain the new original system token, and updates the mapping relationship in Redis to the new token's corresponding relationship, ensuring that the original system and the OAuth2 token state are consistent.

[0149] In some embodiments, the method further includes a logout synchronization step:

[0150] After receiving a logout request, the authentication center system deletes all associated token information from the cache based on the single sign-on credential.

[0151] Iterate through and call the client's preset logout addresses to synchronize the logout status;

[0152] Clear single sign-on credentials from cookies.

[0153] When a user initiates a logout request in the client application, the pluggable client JAR package calls the SSOUtils.buildLogoutUrl(redirect_uri) method to assemble the logout URL based on the server_url and redirect_uri configured in the YAML file, and then requests the authentication center.

[0154] After receiving the request, the authentication center's logout synchronization module uses the `AbstractTicketGrantingTicketManager.invalidate(request, response)` method:

[0155] Retrieve the TGT from the cookie and delete the list of all token_content associated with that TGT from the cache;

[0156] Iterate through the token_content list and call the stored logout_url (client logout callback address) in turn to notify the client to log out synchronously;

[0157] Clear the TGT credentials in the cookie and delete all refresh_tokens and access_tokens associated with the TGT in the cache.

[0158] After receiving the logout notification, the client JAR package queries the original system access token corresponding to the OAuth2 access token based on the second key-value pair, deletes the mapping relationship in Redis and the original system token cache, and completely terminates the user session.

[0159] Client applications only need to import the JAR file and configure the YAML file to integrate single sign-on, without significant modifications to the original code, achieving zero code intrusion; the original system token system remains unchanged, and the state synchronization of the dual token system is achieved through Redis mapping, reducing the complexity of transformation; the standardization and compatibility of the single sign-on process are ensured; and token state synchronization throughout the login, refresh, and logout process improves system security and user experience.

[0160] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A plug-and-play OAuth2 single sign-on authentication service system, characterized in that, Includes the authentication center system and pluggable client JAR files; The certification center system is used for: Receive login requests initiated by client applications, verify the validity of client credentials, and check whether there are valid single sign-on credentials in cookies; Generate OAuth2 tokens for the OAuth2 protocol. OAuth2 tokens include access tokens and refresh tokens. When a refresh token request is received, the validity of the old refresh token is verified and a new token is issued. The expiration time of the single sign credential is extended simultaneously. The pluggable client JAR package enables interaction with the authentication center system by importing the JAR package and YAML configuration file, specifically for: Read the parameters from the YAML configuration file. These parameters include at least the authentication center address, client identifier, client key, login address, logout address, and token storage timeout. Obtain an OAuth2 token via the configured authentication center address; Call the token generation interface provided by the original system to which single sign-on is to be integrated to obtain the original system token; A mapping relationship is established between the OAuth2 token and the original system token and stored in Redis. Based on the mapping relationship in Redis, the original system token is refreshed synchronously when the OAuth2 token is refreshed, and the corresponding original system token is invalidated synchronously when the OAuth2 token expires or the user logs out. The original system is the existing business system that needs to be integrated with single sign-on. When the pluggable client jar package calls the token generation interface of the original system, it passes the user information extracted from the OAuth2 token. The client application obtains user information and permissions through a pluggable client JAR package to complete the single sign-on process, achieving OAuth2 single sign-on compatibility without changing the original system's token logic.

2. The plug-and-play OAuth2 single sign-on authentication service system according to claim 1, characterized in that, The certification center system includes an authentication verification module and an authorization code management module; The authentication and verification module is used to receive login requests from client applications, verify the legality of the client identifier and client key, and check whether there is a valid single sign-on credential in the cookie. If there is no valid single sign-on credential, the user is redirected to the unified login page. After the user enters authentication information through the unified login page, the user's identity is verified. After the user's identity is verified, a single sign-on credential is created and stored in the cookie and local cache. At the same time, the expiration time of the single sign-on credential is refreshed. If a valid single sign-on credential exists, the authorization code management module is triggered directly. The authorization code management module is used to generate authorization codes based on single-point credentials and client identifiers and store them in a local cache. It redirects the authorization code to the client according to the client's preset login address. When receiving a token request, it verifies the legality of the authorization code and its matching with the client identifier. After the verification is successful, the authorization code is invalidated to ensure one-time use.

3. The plug-and-play OAuth2 single sign-on authentication service system according to claim 2, characterized in that, The authentication center system also includes a token issuance module, which receives token requests from clients carrying authorization codes. After verifying the legality of the client identifier and authorization code and the validity of the single sign credential, it generates an OAuth2 token containing an access token, a refresh token, and user information, establishes an association between the single sign credential and the OAuth2 token, and stores it in a cache. When a refresh token request is received, it verifies the legality of the old refresh token, issues a new token, and simultaneously extends the expiration time of the single sign credential.

4. The plug-and-play OAuth2 single sign-on authentication service system according to claim 3, characterized in that, The authentication center system also includes a logout synchronization module, which, upon receiving a logout request, deletes all associated token information in the cache based on the single sign credential, iterates through and calls the client's preset logout address to synchronize the logout status, and clears the single sign credential in the cookie.

5. The plug-and-play OAuth2 single sign-on authentication service system according to claim 4, characterized in that, The pluggable client JAR package includes a configuration parsing module and a token acquisition module; Configure the parsing module to read parameters from the YAML configuration file; The token acquisition module is specifically used to automatically assemble the login URL based on configuration parameters and initiate a login request. After receiving the authorization code returned by the authorization code management module through redirection, it automatically calls the token interface of the authentication center system to obtain the OAuth2 token and stores it in the cache.

6. The plug-and-play OAuth2 single sign-on authentication service system according to claim 5, characterized in that, The pluggable client JAR package also includes the original system interaction module, token mapping module, and token synchronization module; The original system interaction module is used to call the token generation interface provided by the original system to be connected to the single sign-on, trigger the creation of the original system token based on the user information returned by the authentication center system, and obtain the original system access token and refresh token. The token mapping module is used to establish a mapping relationship between the original system refresh token and the OAuth2 refresh token and store it in Redis; and to establish a mapping relationship between the OAuth2 access token and the original system access token and store it in Redis. The token synchronization module is used to synchronously trigger the original system token refresh when the OAuth2 token is refreshed, based on the mapping relationship in Redis, and synchronously invalidate the corresponding original system token when the OAuth2 token expires or the user logs out.

7. The plug-and-play OAuth2 single sign-on authentication service system according to claim 6, characterized in that, The mapping relationship includes: The first key-value pair: uses the original system refresh token as the key and the OAuth2 refresh token as the value; The second key-value pair uses the OAuth2 access token as the key and the original system access token as the value.

8. A plug-and-play OAuth2 single sign-on authentication service method applied to the system described in any one of claims 1-7, characterized in that, Includes the following steps: S1. The client application initiates a login request through a pluggable client jar package. The pluggable client jar package reads parameters from the YAML configuration file. The parameters include at least the authentication center address, client identifier, client key, login address, logout address, and token storage timeout. S2. The authentication center system receives the login request, verifies the validity of the client identifier and client key, and checks whether there is a valid single sign credential in the cookie; If no valid single sign-on credential exists, the user will be redirected to the unified login page. After entering authentication information on the unified login page, the authentication center system will verify the user's identity. If the verification is successful, a single sign-on credential will be created and stored in a cookie and local cache. If a valid single sign-on credential exists, an authorization code will be generated directly based on that single sign-on credential. S3. The authentication center system redirects the client with the authorization code based on the client's preset login address; S4. After receiving the authorization code, the pluggable client jar package automatically calls the token interface of the authentication center system to obtain the OAuth2 token, which includes an access token and a refresh token. S5. The pluggable client jar package calls the token generation interface provided by the original system to obtain the original system token based on the user information in the OAuth2 token; S6. The pluggable client jar package establishes a two-way mapping relationship between the OAuth2 access token and the original system access token, and between the OAuth2 refresh token and the original system refresh token, and stores it in Redis; S7. When the OAuth2 token status changes, the pluggable client JAR package synchronously updates the original system token status based on the mapping relationship in Redis.

9. The plug-and-play OAuth2 single sign-on authentication service method according to claim 8, characterized in that, The OAuth2 token state changes described in S7 include: When an OAuth2 access token expires, the pluggable client JAR package invalidates the corresponding original system access token based on the mapping relationship. When the OAuth2 refresh token is refreshed, the pluggable client JAR package triggers the original system refresh token update based on the mapping relationship.

10. The plug-and-play OAuth2 single sign-on authentication service method according to claim 9, characterized in that, The method also includes a logout synchronization step: After receiving a logout request, the authentication center system deletes all associated token information from the cache based on the single sign-on credential. Iterate through and call the client's preset logout addresses to synchronize the logout status; Clear single sign-on credentials from cookies.

Images