A method and system for multi-system single sign-on and custom token under microservice

Abstract

The application discloses a method and system for single sign-on and custom token under microservices, and belongs to the technical field of development framework, which comprises the following steps: a client application module initiates a request; a gateway module verifies whether the request carries a token, if not, redirects to a unified login address of an authentication and authorization module, when a user completes single sign-on through an existing session identifier and a credential code of the unified login address domain, the authentication and authorization module distributes a token to the client application, and the token supports custom configuration; if the request carries a token, a resource service module verifies the token according to an encryption algorithm, and further verifies whether the token contains access permission of the current resource service, and returns a requested resource after verification; when the client initiates a logout request, all tokens are discarded, and single sign-out is completed; various business scenarios are covered, and various security and performance requirements are met.

Description

Technical Field

[0001] This application belongs to the field of development framework technology, and specifically relates to a method and system for single sign-on and custom tokens for multiple systems under microservices. Background Technology

[0002] In the early stages of enterprise development, the number of systems used by enterprises is small, and the management of accounts by maintenance personnel is relatively simple. As the organization expands and business needs are upgraded, the enterprise's information architecture gradually integrates multiple types of business systems, including but not limited to office automation platforms, human resource management platforms, enterprise resource planning systems, and internal communication platforms. These systems have independent user authentication modules and mechanisms, requiring users to remember multiple authentication credentials and frequently perform repeated login operations. At the same time, user data maintenance forms data silos, significantly increasing the complexity of IT governance and the security risk factor. Summary of the Invention

[0003] To address the aforementioned issues, this application provides a method for single sign-on and custom tokens across multiple systems in a microservices environment, including: The request is initiated by the client application module; The gateway module verifies whether the request carries a token. If no token is carried, the request is redirected to the unified login address of the authentication and authorization module. After the user completes single sign-on using the session identifier and credential code already existing in the unified login address domain, the authentication and authorization module distributes a token to the client application. The token supports custom configuration. If the request includes a token, the resource service module will verify the token using an encryption algorithm and further verify whether the token contains access permissions for the current resource service. Once the verification is successful, the requested resource will be returned. When the client initiates a logout request, all tokens are discarded, and single sign-out is completed.

[0004] Optionally, the token supports custom configuration, including but not limited to: token encryption method, token storage method, token expiration time, token generation rules, and the number of times the token can be used; The token encryption methods include, but are not limited to, SHA-256, BASE64, HMAC-SHA256, JWT, and blockchain encryption algorithms; The tokens can be stored in relational databases, Redis, or in memory.

[0005] Optionally, the user completes single sign-on using an existing session identifier and credential code in the unified login address domain, including: When the client application module initiates a request without carrying a valid token, it is redirected to the unified login address domain of the authentication and authorization module. After the user completes the login, the authentication and authorization module allocates session information and credential code to the unified login address domain, and the client application obtains the token through the credential code.

[0006] Optionally, whether the verification token contains access permissions for the current resource service is based on the RBAC model for permission verification, ensuring that users can only access the resources and services they are authorized to access.

[0007] Optionally, the step of revoking all tokens and completing single sign-out after the client initiates a logout request includes: When a client application module initiates a logout request, the authentication and authorization module clears all tokens of the current user, clears the session information and credential code on the unified login address domain, and changes the user's login status to logout status to ensure that the user is logged out in all client application modules.

[0008] Optionally, after the client application module initiates the request but before the gateway module verifies whether the request carries a token, the following steps are also included: The authentication and authorization module receives the system access application submitted by the client application module and solidifies the third-party application application information, which includes: application code, application access password, application application resource service scope, resource service specified domain scope, unified login address, and client application redirection address.

[0009] Based on the same inventive concept, this application also provides a system for single sign-on and custom tokens across multiple systems in a microservices environment, including: The request initiation unit is used by the client application module to initiate a request. The login authentication unit is used by the gateway module to verify whether the request carries a token. If no token is carried, the request is redirected to the unified login address of the authentication and authorization module. After the user completes single sign-on using the session identifier and credential code that already exist in the unified login address domain, the authentication and authorization module distributes a token to the client application. The token supports custom configuration. The resource access unit is used to verify the token by the resource service module according to the encryption algorithm if the request carries a token, and further verify whether the token contains the access permissions of the current resource service. After successful verification, the requested resource is returned. The logout processing unit is used to discard all tokens and complete single sign-out when a client initiates a logout request.

[0010] Optionally, the system further includes a solidified application unit, used to receive the system access application submitted by the client application module and solidify the third-party application application information, the application information including: application code, application access password, application application resource service scope, resource service specified domain scope, unified login address and client application redirection address.

[0011] Furthermore, this application also provides an electronic device, comprising: at least one processor and a memory; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, a method for single sign-on and custom tokens for multiple systems under a microservice architecture, as described above, is implemented.

[0012] Furthermore, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements the method for single sign-on and custom tokens for multiple systems under a microservice architecture as described above.

[0013] Compared with the prior art, this application has the following advantages: This application provides a method and system for single sign-on and custom tokens in a microservices-based multi-system architecture, comprising: a client application module initiating a request; a gateway module verifying whether the request carries a token; if not, redirecting to the unified login address of the authentication and authorization module; after the user completes single sign-on using an existing session identifier and credential code in the unified login address domain, the authentication and authorization module distributes a token to the client application, the token supporting custom configuration; if the request carries a token, the resource service module verifying the token according to an encryption algorithm, and further verifying whether the token contains access permissions for the current resource service; after successful verification, returning the requested resource; when the client initiates a logout request, all tokens are discarded, completing the single sign-out.

[0014] The business scenarios covered in this application include essential functions for daily applications such as single sign-on for multiple systems, single sign-out, automatic logout upon token expiration, expiration redirection, token refresh, token renewal, and custom tokens. It provides granular permission control functions such as resource service permission control, resource service domain access permission control, menu access permission control, interface access permission control, and button permission control; It provides token customization functionality, allowing users to select appropriate storage methods, encryption methods, verification methods, and token composition structures according to application scenarios, thereby better meeting various security and performance requirements.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

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

[0017] Figure 1 This paper illustrates the implementation flowchart of the method for single sign-on and custom tokens for multiple systems under microservices provided in this application. Figure 2 This application illustrates the overall architecture diagram of a microservice multi-system. Figure 3 A diagram illustrating the custom token functionality provided in this application is shown. Figure 4 The flowchart of the permission verification provided in this application is shown; Figure 5 This application provides a sequence diagram of the single sign-on login process. Figure 6 The system block diagram of single sign-on for multiple systems and custom tokens under microservices provided in this application is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] Example 1 This application provides a method for single sign-on and custom tokens across multiple systems in a microservices environment, such as... Figure 1 ,include: The request is initiated by the client application module; The gateway module verifies whether the request carries a token. If no token is carried, the request is redirected to the unified login address of the authentication and authorization module. After the user completes single sign-on using the session identifier and credential code already existing in the unified login address domain, the authentication and authorization module distributes a token to the client application. The token supports custom configuration. If the request includes a token, the resource service module will verify the token using an encryption algorithm and further verify whether the token contains access permissions for the current resource service. Once the verification is successful, the requested resource will be returned. When the client initiates a logout request, all tokens are discarded, and single sign-out is completed.

[0020] This solution uses a microservices architecture as its overall framework, and categorizes microservices according to their functions into the following types: Figure 2 : 1. Authentication and Authorization Service: This is the core service of the system, providing functions such as login verification, token distribution, token verification, token refresh, token renewal, and custom tokens, and providing a unified login address for all client applications. The authentication and authorization service supports centralized and decentralized verification. When the user selects a traditional encryption algorithm, the resource service forwards the request to the authentication and authorization service to verify the token; when the user selects JWT or blockchain encryption algorithms, the system adopts a decentralized structure, and the resource service itself can verify the token.

[0021] The authentication and authorization service needs to provide APIs for client application access to the system, user authentication, custom tokens, token acquisition, token verification, and logout. The service also needs to establish an RBAC (Restricted Access Control) model to provide data support for access control functions. After a client application submits its access application, the authentication and authorization service needs to embed the third-party application's application information. The specific details of this application information are as follows: Application Encoding: A unique encoding for the client application.

[0022] Application access password: This password is required when a user logs in. The authentication and authorization service verifies whether the current client application is connected to the system by using the application code and the access password.

[0023] Application request for resource services: Resource services that the client application can access.

[0024] The resource service specifies the domain range: The resource service defines an important resource as a domain and tags the domain. Only client applications with this tag can access the custom domain.

[0025] Unified login redirect address: The unified login address provided by the authentication and authorization service is used by all client applications to log in.

[0026] Client application redirect address: After logging in, the page will redirect to this client application redirect address with the credentials code.

[0027] After the above data is solidified, the application is successfully connected.

[0028] The authentication and authorization service provides a custom token function, such as Figure 3 The client application can edit the configuration of token encryption method, token storage method, token expiration time, token generation rules, token renewal time, and token validity count. The authentication and authorization service offers multiple encryption methods such as SHA-256, BASE64, HMAC-SHA256, JWT, and blockchain. When users choose to use JWT or blockchain encryption, the system has a decentralized structure and does not rely on a single authentication service. The resource service can complete token verification, and the system can still operate normally even if some nodes fail. Token verification only requires proving hash matching without exposing the user's original identity data, resulting in extremely high user data security and trustworthiness. Users can choose traditional encryption algorithms, such as the simple BASE64 encryption algorithm, the irreversible SHA-256 encryption algorithm, and the tamper-proof HMAC-SHA256 encryption algorithm. When the client application accesses the resource service, the resource service needs to call the authentication and authorization service to verify the token.

[0029] The system offers multiple token storage options, including relational database storage, Redis storage, and in-memory storage. If token retention is required, relational database storage is recommended due to its high security and resistance to loss. If token persistence is not required, Redis storage is suggested to improve token response speed. For small systems requiring only simple verification, in-memory storage is recommended to reduce system complexity.

[0030] The system offers a custom token rule feature, allowing users to configure the token structure. The authentication and authorization service retrieves the custom configuration, assembles the token, encrypts it, and distributes it. Client applications decrypt the token to obtain the configuration information. Where security requirements permit, this feature avoids frequent API calls to retrieve general information, reducing resource waste. In highly sensitive scenarios, users can customize the number of times a token is valid to prevent theft. In extreme cases, the number of valid tokens can be configured to be only one, minimizing information loss even if the token is leaked. Users can also specify the token expiration time according to security levels, with expiration time in minutes. The default expiration time is 30 minutes, which can be freely set according to the use case. In extreme cases, the token can be set to never expire. If the token is not used within the specified time, all applications will be taken offline. The system supports configuring token renewal. If token renewal is configured, an asynchronous message will be sent after each use to modify the expiration time.

[0031] 2. Resource Services: Business system services are collectively referred to as resource services, which are used for business logic execution and providing external APIs, such as user resource services and historical order resource services.

[0032] 3. Gateway: As the sole external entry point for the single sign-on system, it uniformly manages the interaction between external requests and internal services.

[0033] 4. Client applications: Applications that obtain resources from resource services via APIs or require single sign-on functionality are called client applications.

[0034] The single sign-on system only exposes the gateway address. Client applications can only communicate through the gateway interface. After a client application initiates a request, the gateway verifies whether the request carries a token. If no token is carried, the page redirects to the unified login address of the authentication and authorization service. After the user completes the login, the authentication and authorization service distributes a token to the client application. If the request carries a token, the resource service selects a verification method based on the encryption algorithm. After the token is verified correctly, the resource service verifies whether the token contains the current resource service's resource access permissions, domain access permissions, and interface access permissions. Only if all of the above permissions are present can the current request be successfully responded to; otherwise, the current request is rejected.

[0035] This system provides granular access control authentication, such as... Figure 4 When a client application obtains a token, the authentication and authorization service verifies whether the current application belongs to the system member through the application code and access password. When the client application accesses the resource service with the token, the resource service needs to verify whether the current client has service access permissions and custom domain permissions. Finally, the menu permissions and interface permissions are verified through the RBAC model. Only after all the above verifications are completed can the information be successfully obtained from the resource service.

[0036] The system supports cross-domain single sign-on. The authentication and authorization service provides a unified login address for all client applications. When a client application requests a login without a token or the token expires, the page will redirect to the unified login address domain. After the client application successfully logs in, the authentication and authorization service will assign a session identifier and credential code to the login address domain. Multiple client applications can maintain consistent login status by relying on the session and credential code.

[0037] Single sign-on process as follows Figure 5The browser client initiates a request to access client application A. If the client application request does not carry a token, it will be redirected to the unified login address provided by the authentication and authorization service. After the user completes the login process, the page carries the credential code and redirects to the client application's redirect address. Then, the client application uses the credential code to apply for a token at the redirect address. After successfully obtaining the token, the client application stores the token. Finally, the client application carries the token to initiate a resource acquisition request. The resource service calls the authentication and authorization service to verify the token. After successful verification, the resource information is returned. The browser client initiates a request to access client application B. After logging in, the non-domain client application cannot obtain the distributed token due to cross-domain issues. Therefore, the request to access the resource service without the token will redirect to the unified login address of the authentication and authorization service. Since the application is already logged in, the unified login address domain can obtain the distributed session and credential code, confirm the login is complete, and the page will redirect to the client application's redirect address again with the credential code. The client application obtains and stores the token at the redirect address, and can then access the resource to display data. From this point on, the token exists under all domains, completing the single sign-on process.

[0038] The system supports cross-domain single sign-out. When a user initiates the logout process in client application A, the authentication and authorization service clears all tokens of the current user, and the browser clears the session and credential code on the unified login address domain, thus completing the single sign-out.

[0039] The single sign-out process is as follows: When a client application chooses to log out, it first discards all tokens assigned to the current user, clears the Session and credential codes distributed under the unified login address, and finally changes the current user's login status to offline. From this point on, all system applications for the user are offline, completing the logout process.

[0040] The current system provides single sign-on and logout functionality across multiple devices. When one client application completes login, the returned information will include a credential code, which other clients can use to complete single sign-on.

[0041] If the authentication and authorization center verifies that the token has expired, the authentication and authorization service will clear the token and the Session and credential code distributed under the unified login address. Then, the authentication and authorization service will modify the user's login status. Finally, the client application will redirect to the unified login address with the current route address. If the user completes the login authorization process, the route address will be returned to the client application along with the token when the token expires. The client application will then jump to that route again, thus completing the route redirection process after the token expires.

[0042] Example 2 Based on the same inventive concept, this application also provides a system for single sign-on and custom tokens across multiple systems in a microservices environment, such as... Figure 6 ,include: The request initiation unit is used by the client application module to initiate a request. The login authentication unit is used by the gateway module to verify whether the request carries a token. If no token is carried, the request is redirected to the unified login address of the authentication and authorization module. After the user completes single sign-on using the session identifier and credential code that already exist in the unified login address domain, the authentication and authorization module distributes a token to the client application. The token supports custom configuration. The resource access unit is used to verify the token by the resource service module according to the encryption algorithm if the request carries a token, and further verify whether the token contains the access permissions of the current resource service. After successful verification, the requested resource is returned. The logout processing unit is used to discard all tokens and complete single sign-out when a client initiates a logout request.

[0043] Optionally, the system further includes a solidified application unit, used to receive the system access application submitted by the client application module and solidify the third-party application application information, the application information including: application code, application access password, application application resource service scope, resource service specified domain scope, unified login address and client application redirection address.

[0044] Example 3 Based on the same inventive concept, this application also provides an electronic device. The electronic device of this application includes at least one processor and at least one storage medium electrically connected to each other. The storage medium is electrically connected to the processor, wherein the storage medium stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described above.

[0045] Example 4 Based on the same inventive concept, this application also provides a storage medium storing instructions executable by at least one processor, the instructions being executed by at least one processor to enable at least one processor to perform the method described above.

[0046] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for single sign-on and custom tokens across multiple systems in a microservices environment, characterized in that, include: The request is initiated by the client application module; The gateway module verifies whether the request carries a token. If no token is carried, the request is redirected to the unified login address of the authentication and authorization module. After the user completes single sign-on using the session identifier and credential code already existing in the unified login address domain, the authentication and authorization module distributes a token to the client application. The token supports custom configuration. If the request includes a token, the resource service module will verify the token using an encryption algorithm and further verify whether the token contains access permissions for the current resource service. Once the verification is successful, the requested resource will be returned. When the client initiates a logout request, all tokens are discarded, and single sign-out is completed.

2. The method according to claim 1, characterized in that, The token supports custom configuration, including but not limited to: token encryption method, token storage method, token expiration time, token generation rules, and the number of times the token can be used. The token encryption methods include, but are not limited to, SHA-256, BASE64, HMAC-SHA256, JWT, and blockchain encryption algorithms; The tokens can be stored in relational databases, Redis, or in memory.

3. The method according to claim 1, characterized in that, The user completes single sign-on using an existing session identifier and credential code in the unified login address domain, including: When the client application module initiates a request without carrying a valid token, it is redirected to the unified login address domain of the authentication and authorization module. After the user completes the login, the authentication and authorization module allocates session information and credential code to the unified login address domain, and the client application obtains the token through the credential code.

4. The method according to claim 1, characterized in that, The verification token is used to verify whether it contains access permissions for the current resource service. This is based on the RBAC model to ensure that users can only access the resources and services they are authorized to access.

5. The method according to claim 1, characterized in that, When a client initiates a logout request, all tokens are revoked to complete single sign-out, including: When a client application module initiates a logout request, the authentication and authorization module clears all tokens of the current user, clears the session information and credential code on the unified login address domain, and changes the user's login status to logout status to ensure that the user is logged out in all client application modules.

6. The method according to claim 1, characterized in that, After the client application module initiates the request but before the gateway module verifies whether the request carries a token, the following steps are also included: The authentication and authorization module receives the system access application submitted by the client application module and solidifies the third-party application application information, which includes: application code, application access password, application application resource service scope, resource service specified domain scope, unified login address, and client application redirection address.

7. A system for single sign-on and custom tokens across multiple systems in a microservices architecture, characterized in that, include: The request initiation unit is used by the client application module to initiate a request. The login authentication unit is used by the gateway module to verify whether the request carries a token. If no token is carried, the request is redirected to the unified login address of the authentication and authorization module. After the user completes single sign-on using the session identifier and credential code that already exist in the unified login address domain, the authentication and authorization module distributes a token to the client application. The token supports custom configuration. The resource access unit is used to verify the token by the resource service module according to the encryption algorithm if the request carries a token, and further verify whether the token contains the access permissions of the current resource service. After successful verification, the requested resource is returned. The logout processing unit is used to discard all tokens and complete single sign-out when a client initiates a logout request.

8. The system according to claim 1, characterized in that, The system also includes a solidified application unit, which is used to receive the system access application submitted by the client application module and solidify the third-party application application information. The application information includes: application code, application access password, application application resource service scope, resource service specified domain scope, unified login address and client application redirection address.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method for single sign-on and custom tokens for multiple systems under microservices as described in claims 1-6.

10. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the method for multi-system single sign-on and custom tokens under microservices as described in claims 1-6.

Images