Methods, apparatus, devices, and storage media for implementing cross-system token access

Abstract

A method, apparatus, device, and computer-readable storage medium for implementing cross-system token access are disclosed. In this method, when a calling system interacts with the token system of a called system, a target adapter corresponding to the token system in the caller system's registry is selected and loaded. The target adapter calls the token system's interface, parses and maps the token returned by the token system corresponding to the called system into a standard token object defined by the token operation interface. This method enables the calling system to access token information from various called systems in a unified manner. When adding other token authentication protocols, only the same interface needs to be implemented, solving the problems of lack of uniformity and insufficient scalability in existing technologies.

Description

Technical Field

[0001] This application relates to the field of software technology, and specifically to a method, apparatus, device, and computer-readable storage medium for implementing cross-system token access. Background Technology

[0002] With the deepening application of software technology in the field of enterprise digitalization, the popularization of microservice architecture and open APIs has led to increasingly frequent cross-system interactions. Token-based authentication and authorization mechanisms have become a core requirement for ensuring secure system interactions.

[0003] Among the relevant technologies, the following solutions exist: each system independently manages token generation, storage, and verification; a centralized authentication and authorization center manages all system tokens uniformly; and cache-based token management.

[0004] However, these solutions have significant drawbacks. Due to the different token management standards of each system, the integration complexity is high, there is a lack of uniformity, and a lot of adaptation work is required when adding a new token system, resulting in insufficient scalability. Summary of the Invention

[0005] This application provides a method, apparatus, device, and computer-readable storage medium for implementing cross-system token access, which can solve the technical problems of lack of uniformity and insufficient scalability in the token access process in the prior art.

[0006] In a first aspect, embodiments of this application provide a method for implementing cross-system token access, the method comprising:

[0007] When the calling system interacts with the token system of the called system, the target adapter corresponding to the token system in the registrar of the calling system is selected and loaded. The calling system implements a unified token access interface so that the calling system can call the token system in a unified way. The called system can be any one of the calling systems. Each adapter implements a unified token operation interface, which includes the core operations that all token systems need to support.

[0008] The target adapter calls the token system's interface, parses the token returned by the token system corresponding to the called system, and maps it to a standard token object defined by the token operation interface.

[0009] In conjunction with the first aspect, in one implementation, before selecting and loading the target adapter corresponding to the token system in the caller system's registrar when the caller system interacts with the token system of the callee system, the method further includes:

[0010] During the initialization phase of the calling system, an adapter registration management mechanism is established and maintained to associate and register the adapters corresponding to the token system in the calling system with a unique identifier into the registrar of the calling system.

[0011] The target adapter corresponding to the token system in the registrar of the calling system that is selected and loaded includes:

[0012] When the calling system interacts with the token system of the called system, the calling system obtains the corresponding adapter from the registrar based on the token type field in the request of the called system, and uses it as the target adapter.

[0013] In conjunction with the first aspect, in one implementation, the core operations that all token systems need to support include:

[0014] Verify token: Verify the validity of the token, including its expiration time and signature correctness;

[0015] Extract token information: Parse key information such as user ID, permission scope, and expiration time from the token;

[0016] Refresh Token: When the token supports refreshing, a new token is obtained through the corresponding mechanism;

[0017] Revoke token: Invalidate the token in response to user logout or permission change.

[0018] In conjunction with the first aspect, in one implementation, after the target adapter calls the token system's interface to parse and map the token returned by the token system corresponding to the called system into a standard token object defined by the token operation interface, the implementation further includes:

[0019] Check if the standard token object exists in the cache component;

[0020] If it does not exist, the standard token object is stored in the cache component.

[0021] In conjunction with the first aspect, in one implementation, the method for implementing cross-system token access further includes:

[0022] When the calling system interacts with the token system of the calling system, check whether the corresponding standard token object exists in the cache component;

[0023] If it exists, the corresponding standard token object is retrieved from the cache component.

[0024] In conjunction with the first aspect, in one implementation, after detecting whether a corresponding standard token object exists in the cache component, the method further includes:

[0025] If it does not exist, then the selection is performed and the target adapter corresponding to the token system is loaded from the caller system's registrar.

[0026] In conjunction with the first aspect, in one implementation, after storing the standard token object to the cache component, the method further includes:

[0027] When the remaining validity period of the standard token object is detected to be lower than the threshold, the caching component sends a refresh request to the token system;

[0028] When a valid response based on the refresh request is received, the remaining validity period of the standard token object is updated.

[0029] Secondly, embodiments of this application provide an apparatus for implementing cross-system token access, the apparatus comprising:

[0030] Selection Module: When the calling system interacts with the token system of the called system, the target adapter corresponding to the token system in the registrar of the calling system is selected and loaded. The calling system implements a unified token access interface so that the calling system can call the token system in a unified way. The called system can be any one of the calling systems. Each adapter implements a unified token operation interface, which includes the core operations that all token systems need to support.

[0031] Mapping module: The target adapter calls the token system's interface, parses the token returned by the token system corresponding to the called system, and maps it to a standard token object defined by the token operation interface.

[0032] Thirdly, embodiments of this application provide an apparatus for implementing cross-system token access. The apparatus for implementing cross-system token access includes a processor, a memory, and a program for implementing cross-system token access stored in the memory and executable by the processor. When the program for implementing cross-system token access is executed by the processor, it implements the steps of the method for implementing cross-system token access as described in the first aspect.

[0033] Fourthly, embodiments of this application provide a computer-readable storage medium storing a program for implementing cross-system token access, wherein when the program for implementing cross-system token access is executed by a processor, it implements the steps of the method for implementing cross-system token access as described in the first aspect.

[0034] The beneficial effects of the technical solutions provided in this application include:

[0035] When the calling system interacts with the token system of the called system, a target adapter corresponding to the token system in the caller system's registry is selected and loaded. The calling system implements a unified token access interface, allowing it to invoke the token system in a consistent manner. The called system can be any of the systems to be invoked. Each adapter implements a unified token operation interface, which includes the core operations that all token systems need to support. The target adapter calls the token system's interface, parses and maps the token returned by the token system corresponding to the called system to a standard token object defined by the token operation interface. This method enables the calling system to invoke token information from each called system in a unified way. Furthermore, when adding other token authentication protocols, only the same interface needs to be implemented, solving the problems of lack of uniformity and scalability in existing technologies. Attached Figure Description

[0036] Figure 1 This is a flowchart illustrating an embodiment of the method for implementing cross-system token access in this application;

[0037] Figure 2 A schematic diagram of functional modules of an embodiment of the apparatus for implementing cross-system token access in this application;

[0038] Figure 3 This is a schematic diagram of the hardware structure of the device for implementing cross-system token access involved in the embodiments of this application. Detailed Implementation

[0039] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0041] In a first aspect, embodiments of this application provide a method for implementing cross-system token access.

[0042] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for implementing cross-system token access in this application. Figure 1 As shown, methods for implementing cross-system token access include:

[0043] Step S10: When the calling system interacts with the token system of the called system, select and load the target adapter corresponding to the token system in the registrar of the calling system. The calling system implements a unified token access interface so that the calling system can call the token system in a unified way. The called system is any one of the calling systems. Each adapter implements a unified token operation interface. The unified token operation interface contains the core operations that all token systems need to support.

[0044] Furthermore, in one embodiment, before selecting and loading the target adapter corresponding to the token system in the caller system's registrar when the caller system interacts with the token system of the callee system, the method further includes:

[0045] During the initialization phase of the calling system, an adapter registration management mechanism is established and maintained to associate and register adapters corresponding to the token system in the calling system with unique identifiers into the caller system's registry. The selection and loading of the target adapter corresponding to the token system in the caller system's registry includes: when the calling system interacts with the token system of the called system, the calling system obtains the corresponding adapter from the registry based on the token type field in the called system's request, and uses it as the target adapter.

[0046] Furthermore, in one embodiment, the core operations that all token systems need to support include:

[0047] Verify token: Verify the validity of the token, including its expiration time and signature correctness;

[0048] Extract token information: Parse key information such as user ID, permission scope, and expiration time from the token;

[0049] Refresh Token: When the token supports refreshing, a new token is obtained through the corresponding mechanism;

[0050] Revoke token: Invalidate the token in response to user logout or permission change.

[0051] In one embodiment of this application, for example, when system A interacts with the token system of system B, system A needs to call system B's token system to verify its identity or obtain permissions. In this case, system A is the caller and system B is the callee. Since system A may need to interact with the token systems of multiple different callee systems (such as system B and system C), and each token system may use different token types or formats (such as OAuth 2.0, JWT, etc.), direct interaction would result in communication failure due to incompatibility. Therefore, system A uses a unified token access interface, so that system A can access and use the token in a unified way regardless of the token format of the callee system.

[0052] During the initialization phase of System A, an adapter registration management mechanism is established to associate and register the token system adapters (such as the OAuth 2.0 adapter of System B or the JWT adapter of System C) corresponding to each called system (such as System B or System C) with unique identifiers (such as "oauth2" or "jwt") with the registrar A of System A. When System A interacts with System B, System A retrieves the adapter associated with the unique identifier corresponding to the token type (i.e., the OAuth 2.0 adapter of System B) from the registrar A based on the token type field (such as "oauth2") in System B's request, and uses it as the target adapter for processing System B's token.

[0053] Since different callee systems' token systems (such as OAuth 2.0 and JWT) have their own technical characteristics and operating methods (for example, OAuth 2.0 requires calling the authorization server's Introspection interface to verify the token, while JWT can verify the signature locally), by defining a unified token operation interface for the adapter, the unique operations of different token systems can be converted into a standardized calling method, enabling system A to call the token systems of all callees in a unified way;

[0054] Step S20: The target adapter calls the token system's interface to parse and map the token returned by the token system to the standard token object defined by the token operation interface.

[0055] In one embodiment, after system A selects and loads the target adapter, the target adapter calls the token system's interface to obtain the unique token returned by it. The target adapter parses the unique token and converts it into a standard token object defined by the unified interface, so that system A can directly call the standard token object without caring about the differences in the underlying protocol of the token system.

[0056] The following examples illustrate how the adapter maps token system-specific operations to standard token operations defined by the token operation interface, specifically for OAuth 2.0 and JWT token systems:

[0057] OAuth 2.0 adapter:

[0058] First, define a standardized token operation interface, which includes two core functions:

[0059] The token validity verification method (validateToken) determines the validity of a token by returning a boolean value upon input.

[0060] User identifier extraction method (getUserIdFromToken): Returns the corresponding unique user identifier by parsing the token;

[0061] This token operation interface abstracts the basic operations for interacting with the authentication system, providing a unified interface standard for different protocols.

[0062] The OAuth 2.0 adapter then implements the standardized interface using the following method:

[0063] Component initialization:

[0064] Integrate the OAuth 2.0 client library as a basic component, and inject the OAuth 2.0 client instance through the constructor to establish communication capability with the authorization server;

[0065] Token verification implementation:

[0066] The standard validateToken method is mapped to the token introspection mechanism of OAuth 2.0. The introspectToken method of the client library is called to access the Introspection Endpoint of the authorization server, process the verification result, and return a valid token when successful and an invalid or expired token when an exception occurs.

[0067] User identifier extraction implementation:

[0068] The standard getUserIdFromToken method is mapped to the OAuth 2.0 token resolution process. The complete token information is obtained through the getTokenInfo method of the client library. According to the OAuth 2.0 specification, the user's unique identifier is extracted from the "sub" (subject) field of the token information. The user ID string is returned when the resolution is successful. When an OAuth2Exception is caught, null is returned or a business exception is thrown.

[0069] In this way, the adapter achieves technical alignment between OAuth 2.0 protocol features and standardized interfaces:

[0070] The protocol differences for token verification are encapsulated, exposing a unified verification method to the outside world; the naming differences of user identification fields (such as sub fields) are handled internally by the adapter, providing a standard return value to the outside world; the implementation details of different OAuth 2.0 service providers are isolated by the client library, and the adapter maintains the universality at the protocol level.

[0071] JWT adapter:

[0072] Suppose a generic token adapter interface TokenAdapterInterface has been defined, which includes methods such as verifying token validity and retrieving user identity from the token. Create an adapter to handle systems that use JWT (JSON Web Token) as tokens, making it conform to the requirements of this generic interface. This adapter is named JWTAdapter and implements the TokenAdapterInterface interface.

[0073] Component initialization:

[0074] During initialization, JWTAdapter depends on two main external components:

[0075] A dedicated library for handling JWTs (e.g., jjwt, jose4j, etc. in Java) is responsible for parsing, validating, and generating JWTs; a public key is used to verify the digital signature of the incoming JWT, ensuring the integrity of the token and the trustworthiness of its origin.

[0076] The adapter internally holds references to this JWT library instance and its public key.

[0077] Next, we will describe how JWTAdapter implements the key methods in TokenAdapterInterface:

[0078] Token verification implementation:

[0079] Implement the validateToken(String token) method. The goal of this method is to check whether the passed string (representing a JWT token) is valid. JWTAdapter will translate this general verification request into a specific operation for JWT. It will call the functions of the internally dependent JWT processing library and use the public key provided during adapter initialization to verify the digital signature of the passed JWT string. This is the first step in JWT verification, ensuring that the token has not been tampered with since it was issued.

[0080] Next, or as part of the library, the adapter will also use the functionality of the JWT library to validate other important claims contained in the JWT, such as checking whether the token has expired, whether the issuer is correct, and whether the audience is correct. These are validation items defined in the JWT specification or agreed upon at the application level.

[0081] If no errors occur during signature verification and all necessary claim verification (e.g., signature mismatch, expired token, incorrect claim), then the method determines that the JWT is valid and returns true.

[0082] If any JWT-specific errors occur during the verification process (such as invalid signature, expired token, parsing failure, or claim verification failure), the adapter will catch these errors, determine that the JWT verification has failed, and return false.

[0083] User identifier extraction implementation:

[0084] The goal of this method is to extract user identity information (such as a user ID) from a valid token string. The JWTAdapter transforms this general extraction request into an operation of parsing the JWT and retrieving specific claims. It calls the functions of its internally dependent JWT processing library to parse the incoming JWT string. The parsing process breaks down the JWT's structure, particularly retrieving its payload, which contains various claims. Upon successful parsing, the adapter searches the parsed set of claims for the pre-defined claim field used to store user identity information (such as the user ID). In this example, assuming that according to application conventions, the user ID is stored in a claim named "userId", the adapter attempts to retrieve the value of this "userId" claim and returns it as the user ID. However, the JWT standard itself does not have a standard claim named "userId". In practice, the name of the claim storing the user ID or other identity identifier is determined by the specific system design and conventions. The adapter must know this conventional claim name to extract correctly; if an error occurs during JWT parsing or retrieving the conventional claim (such as an incorrect JWT format or parsing failure), the adapter typically returns null or throws an exception indicating that it could not retrieve the user ID.

[0085] In this embodiment, by aligning the token system protocol features with the standardized interface, the calling system does not need to be aware of the specific implementation details of the underlying token operation. When adding other authentication protocols, it only needs to implement the same interface, maintaining the consistency of the system architecture. This solves the problems of lack of uniformity and insufficient scalability when accessing tokens across systems in related technologies.

[0086] Furthermore, in one embodiment, after the target adapter calls the token system's interface to parse and map the token returned by the token system corresponding to the called system into a standard token object defined by the token operation interface, the method further includes:

[0087] Check if the standard token object exists in the cache component;

[0088] If it does not exist, the standard token object is stored in the cache component;

[0089] Furthermore, in one embodiment, the method for implementing cross-system token access further includes:

[0090] When the calling system interacts with the token system of the called system, it checks whether a corresponding standard token object exists in the cache; if it does, it retrieves the corresponding standard token object from the cache.

[0091] Furthermore, in one embodiment, after detecting whether a corresponding standard token object exists in the cache, the method further includes:

[0092] If it does not exist, then perform the selection and load the target adapter corresponding to the token system from the caller system's registrar;

[0093] In one embodiment, the caching component is a standalone token caching component responsible for token storage and management. Its core lies in defining an abstract interface to standardize token storage and management operations, then implementing this interface for different caching media (such as memory and distributed cache), and flexibly selecting specific implementation strategies and setting expiration times through a configuration mechanism. The constructed caching component includes the following key parts: a core interface defining the caching operation specifications; various specific caching strategy classes implementing this interface (e.g., memory caching implementation, Redis-based distributed caching implementation, etc.); a configuration structure or class for configuring which strategy to select and related parameters (such as connection information, default expiration time); and a unified manager or service class as the sole entry point for external applications to interact with the cache, responsible for instantiating and using specific strategies according to the configuration, jointly implementing the functions of token storage, retrieval, removal, and expiration management.

[0094] For example, when System A interacts with System B for the first time, if the cache component does not yet store System B's token information, the system enters the adapter selection and loading process. After obtaining the mapped standard token object, the standard token object is stored in the cache component. When System A requests the token information again within the token's validity period, System A checks the cache component and finds that a record already exists. The cache component quickly finds the standard token object through the unique identifier associated with the token, discovers that it has not expired, and directly retrieves the token information from the cache without the need for the adapter.

[0095] Furthermore, in one embodiment, after storing the standard token object in the cache, the method further includes:

[0096] When the remaining validity period of the standard token object is detected to be lower than the threshold, the caching component sends a refresh request to the token system;

[0097] When a valid response based on the refresh request is received, the remaining validity period of the standard token object is updated;

[0098] Specifically, the caching component can adopt various caching strategies (such as memory-based caching, distributed caching, etc.) and supports configuring different cache expiration times. When the token is about to expire, the caching component will automatically request a new token from the corresponding token system and update the cache.

[0099] In one embodiment, automatic Access Token refresh based on OAuth 2.0

[0100] Suppose you are accessing an API service protected by OAuth 2.0.

[0101] (1) Initial Token Acquisition and Caching: After the application successfully completes the OAuth 2.0 authorization process for the first time, it obtains an Access Token and a Refresh Token from the authorization server. The caching component stores the Access Token in the cache and records its expiration time (e.g., the Access Token is valid for 1 hour). Meanwhile, the Refresh Token is usually securely stored in the backend and is not directly cached in the fast cache, but is used to obtain a new Access Token when needed.

[0102] (2) Accessing protected resources: The application uses the cached Access Token to access protected API resources. During the validity period of the Access Token, subsequent API requests can directly use the cached Access Token without having to request the token from the authorization server again, thus improving performance.

[0103] (3) Token expiration detection: The caching component checks the remaining validity period of the Access Token periodically or before each use. It should be noted that the refresh is usually not triggered when the Access Token has completely expired, but when the token is about to expire (for example, when there are 5 minutes left on the validity period). This avoids the application failing to make a request because of the use of an expired token when the token has just expired.

[0104] (4) Automatic refresh trigger: When the cache component detects that the Access Token is about to expire, the automatic refresh mechanism is triggered.

[0105] (5) Request a new Access Token using a Refresh Token: The caching component runs in the background and uses the previously stored Refresh Token to send a Refresh Token Grant request to the OAuth 2.0 authorization server. This request is usually completed without requiring further user interaction.

[0106] Update Cache: Upon receiving a new Access Token, the caching component immediately updates the existing Access Token in the cache and changes its expiration time to the new validity period (e.g., the new Access Token's validity period remains 1 hour). If the authorization server returns a new Refresh Token, the caching component also needs to securely update the stored Refresh Token for use on the next refresh.

[0107] Application-unaware: The entire automatic refresh process is completed in the background, and the application can continue to use the cached Access Token for API requests without service interruption or the need for re-authentication due to token expiration. The next time the application uses the Access Token, it will already be the latest valid token.

[0108] In another embodiment, the main purpose of configuring different cache expiration times is to achieve the best balance between performance, security, and data freshness, and to flexibly adapt to the needs of different token types and application scenarios. The caching component can employ various caching strategies (e.g., memory-based caching, distributed caching, etc.) and supports configuring different cache expiration times. Specifically, this has the following key objectives:

[0109] Optimize performance and reduce authentication service load: The core purpose of caching tokens is to reduce duplicate token verification requests, thereby improving system performance and reducing the load on the backend authentication service. By caching tokens, it is possible to avoid sending a verification request to the authentication service every time a protected resource is accessed. Especially in high-concurrency scenarios, the performance improvement brought by caching is very significant.

[0110] Adapting to different token lifecycles: Different token systems or token types may have different default lifecycles. For example:

[0111] OAuth 2.0 Access Token: Typically has a short lifespan, such as a few minutes to a few hours, and is designed to improve security;

[0112] JWT Access Token: The lifecycle can be flexibly configured according to application needs, but it is usually relatively short.

[0113] Refresh Token (OAuth 2.0): It typically has a longer lifespan and is used to obtain a new Access Token after the original Access Token has expired.

[0114] Session tokens (such as cookie-based sessions): may have a longer lifespan, depending on the duration of the user session or application configuration.

[0115] Meets the needs of different application scenarios: Different application scenarios have different requirements for performance, security and data freshness.

[0116] In high-security scenarios (such as financial transaction systems), shorter cache expiration times may be required to ensure that permission changes and token revocations take effect promptly, reducing security risks, even at the cost of some performance.

[0117] In high-performance scenarios (such as content delivery networks (CDNs) or high-concurrency API gateways), a longer cache expiration time may be preferred to maximize cache hit rate, improve performance, and reduce latency. However, this requires a trade-off in potential security risks and may need to be compensated for by combining it with other mechanisms (such as token revocation mechanisms).

[0118] In scenarios where permissions change frequently (such as role-based access control systems), a relatively short cache expiration time may be necessary to ensure that permission updates are reflected in the system in a timely manner, thus avoiding inconsistencies in user permissions.

[0119] For low-sensitivity data access scenarios (such as public information queries): the cache expiration time can be appropriately extended to improve performance.

[0120] For example, in a financial transaction system with high security requirements, users need strict access control and real-time processing when making bank transfers.

[0121] Token type: OAuth 2.0 Access Token, with a lifespan typically set to a short time (e.g., 5-15 minutes).

[0122] Cache configuration: The cache expiration time can be set to be slightly shorter than the validity period of the Access Token, such as 3-10 minutes.

[0123] Objective: To prioritize security and ensure that even if the Access Token is compromised, the impact will be limited in duration. Simultaneously, if user permissions are frozen or revoked, the changes will take effect quickly. This sacrifices some cache hit rate in exchange for enhanced security.

[0124] For example, a high-performance API gateway needs to handle a large number of user requests and is very sensitive to performance and latency.

[0125] Token type: JWT Access Token, with a lifespan that can be set to a longer duration (e.g., 1-2 hours).

[0126] Cache configuration: The cache expiration time can be set to be close to or slightly less than the validity period of the Access Token, such as 45-90 minutes.

[0127] Objective: Prioritize performance, maximize cache hit rate, reduce API gateway latency, and increase throughput. Potential security risks can be mitigated through monitoring and alerting mechanisms, as well as token revocation mechanisms.

[0128] For example, in a dynamic access control system, or an internal role-based access control system within an enterprise, user roles and permissions change frequently.

[0129] Token type: Custom Session Token or JWT Access Token, with lifecycle adjustable as needed.

[0130] Cache configuration: The cache expiration time needs to be adjusted according to the frequency of permission changes. It may need to be set to a shorter time, such as 5-30 minutes, or even shorter if permission changes are very frequent.

[0131] Objective: To ensure that permission updates take effect promptly, preventing users from retaining old permissions after the change, which could lead to operational errors or security risks.

[0132] In this embodiment, the caching component actively monitors the remaining validity period of the token (e.g., by setting a threshold to trigger a refresh) to ensure that the status of the locally cached token is consistent with its actual validity, thereby reducing the frequent authentication failures caused by token expiration and improving system security and stability.

[0133] Secondly, embodiments of this application also provide an apparatus for implementing cross-system token access.

[0134] In one embodiment, reference is made to Figure 2 , Figure 2 This is a functional module diagram of an embodiment of the apparatus for implementing cross-system token access according to this application. Figure 2 As shown, the apparatus for implementing cross-system token access includes:

[0135] Selection Module 10: When the calling system interacts with the token system of the called system, the target adapter corresponding to the token system in the registrar of the calling system is selected and loaded. The calling system implements a unified token access interface so that the calling system can call the token system in a unified way. The called system is any one of the calling systems. Each adapter implements a unified token operation interface, which includes the core operations that all token systems need to support.

[0136] Mapping Module 20: The target adapter calls the token system's interface to parse and map the token returned by the token system to the standard token object defined by the token operation interface.

[0137] Furthermore, in one embodiment, a registration module is included before the selection module 10, for:

[0138] During the initialization phase of the calling system, an adapter registration management mechanism is established and maintained to associate and register the adapters corresponding to the token system in the calling system with a unique identifier into the registrar of the calling system.

[0139] The target adapter corresponding to the token system in the registrar of the calling system that is selected and loaded includes:

[0140] When the calling system interacts with the token system of the called system, the calling system obtains the corresponding adapter from the registrar based on the token type field in the request of the called system, and uses it as the target adapter.

[0141] Furthermore, in one embodiment, the core operations that all token systems need to support include:

[0142] Verify token: Verify the validity of the token, including its expiration time and signature correctness;

[0143] Extract token information: Parse key information such as user ID, permission scope, and expiration time from the token;

[0144] Refresh Token: When the token supports refreshing, a new token is obtained through the corresponding mechanism;

[0145] Revoke token: Invalidate the token in response to user logout or permission change.

[0146] Furthermore, in one embodiment, the apparatus for implementing cross-system token access further includes a caching module, used for:

[0147] After the target adapter calls the token system's interface, parses and maps the token returned by the token system corresponding to the called system to a standard token object defined by the token operation interface, the following is also included:

[0148] Check if the standard token object exists in the cache component;

[0149] If it does not exist, the standard token object is stored in the cache component.

[0150] Furthermore, in one embodiment, the caching module is also used for:

[0151] When the calling system interacts with the token system of the calling system, check whether the corresponding standard token object exists in the cache component;

[0152] If it exists, the corresponding standard token object is retrieved from the cache component.

[0153] Furthermore, in one embodiment, the selection module is also used for:

[0154] After detecting whether a corresponding standard token object exists in the cache component, the method further includes:

[0155] If it does not exist, then the selection is performed and the target adapter corresponding to the token system is loaded from the caller system's registrar.

[0156] Furthermore, in one embodiment, the apparatus for implementing cross-system token access further includes an update module, used for:

[0157] After storing the standard token object in the cache, the process further includes:

[0158] When the remaining validity period of the standard token object is detected to be lower than the threshold, the caching component sends a refresh request to the token system;

[0159] When a valid response based on the refresh request is received, the remaining validity period of the standard token object is updated.

[0160] The functions of each module in the device for implementing cross-system token access correspond to the steps in the method embodiment for implementing cross-system token access, and their functions and implementation processes will not be described in detail here.

[0161] Thirdly, embodiments of this application provide a device for implementing cross-system token access. The device for implementing cross-system token access can be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0162] Reference Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of a device for implementing cross-system token access, as described in an embodiment of this application. In this embodiment, the device for implementing cross-system token access may include a processor, memory, a communication interface, and a communication bus.

[0163] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0164] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces for interconnecting internal devices within the device implementing cross-system token access, as well as interfaces for interconnecting the device implementing cross-system token access with other devices (e.g., other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0165] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0166] The processor can be a general-purpose processor, which can call a program stored in memory to implement cross-system token access and execute the method for implementing cross-system token access provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the program for implementing cross-system token access is called can be referred to in the various embodiments of the method for implementing cross-system token access in this application, and will not be repeated here.

[0167] Those skilled in the art will understand that Figure 3 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0168] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0169] The present application provides a computer-readable storage medium storing a program for implementing cross-system token access, wherein when the program for implementing cross-system token access is executed by a processor, it implements the steps of the method for implementing cross-system token access as described above.

[0170] The method implemented when the program for implementing cross-system token access is executed can be referred to in various embodiments of the method for implementing cross-system token access in this application, and will not be repeated here.

[0171] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0172] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0173] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0174] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0175] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0176] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0177] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for implementing cross-system token access, characterized in that, The method for implementing cross-system token access includes: When the calling system interacts with the token system of the called system, the target adapter corresponding to the token system in the registrar of the calling system is selected and loaded. The calling system implements a unified token access interface so that the calling system can call the token system in a unified way. The called system can be any one of the calling systems. Each adapter implements a unified token operation interface, which includes the core operations that all token systems need to support. The target adapter calls the token system's interface, parses the token returned by the token system corresponding to the called system, and maps it to a standard token object defined by the token operation interface. Check if the standard token object exists in the cache component; If it does not exist, the standard token object is stored in the cache component; When the remaining validity period of the standard token object is detected to be lower than the threshold, the caching component sends a refresh request to the token system; When a valid response based on the refresh request is received, the remaining validity period of the standard token object is updated.

2. The method for implementing cross-system token access as described in claim 1, characterized in that, Before selecting and loading the target adapter corresponding to the token system in the caller system's registrar when the caller system interacts with the callee system's token system, the method further includes: During the initialization phase of the calling system, an adapter registration management mechanism is established and maintained to associate and register adapters corresponding to the token system in the calling system with unique identifiers into the caller system's registry. The target adapter corresponding to the token system in the registrar of the calling system that is selected and loaded includes: When the calling system interacts with the token system of the called system, the calling system obtains the corresponding adapter from the registrar based on the token type field in the request from the called system, and uses it as the target adapter.

3. The method for implementing cross-system token access as described in claim 1, characterized in that, The core operations that all token systems need to support include: Verify token: Verify the validity of the token, including its expiration time and signature correctness; Extract token information: Parse the user ID, permission scope, and expiration time information from the token; Refresh Token: When the token supports refreshing, a new token is obtained through the corresponding mechanism; Revoke token: Invalidate the token in response to user logout or permission change.

4. The method for implementing cross-system token access as described in claim 1, characterized in that, The method further includes: When the calling system interacts with the token system of the calling system, check whether the corresponding standard token object exists in the cache component; If it exists, the corresponding standard token object is retrieved from the cache component.

5. The method for implementing cross-system token access as described in claim 4, characterized in that, After detecting whether a corresponding standard token object exists in the cache component, the method further includes: If it does not exist, then the selection is performed and the target adapter corresponding to the token system is loaded from the caller system's registrar.

6. An apparatus for implementing cross-system token access, characterized in that, The apparatus for enabling cross-system token access includes: Selection Module: When the calling system interacts with the token system of the called system, it selects and loads the target adapter corresponding to the token system in the registrar of the calling system. The calling system implements a unified token access interface so that the calling system can call the token system in a unified way. The called system can be any one of the calling systems. Each adapter implements a unified token operation interface, which includes the core operations that all token systems need to support. Cache module: Used to detect whether a standard token object exists in the cache component; if not, the standard token object is stored in the cache component. Update module: When the remaining validity period of the standard token object is detected to be lower than a threshold, the cache component sends a refresh request to the token system; when a valid response based on the refresh request is received, the remaining validity period of the standard token object is updated. Mapping module: Used by the target adapter to call the token system's interface, it parses and maps the token returned by the token system to the standard token object defined by the token operation interface.

7. A device for implementing cross-system token access, characterized in that, The device for implementing cross-system token access includes a processor, a memory, and a program for implementing cross-system token access stored in the memory and executable by the processor, wherein when the program for implementing cross-system token access is executed by the processor, it implements the steps of the method for implementing cross-system token access as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program for implementing cross-system token access, wherein when the program for implementing cross-system token access is executed by a processor, it implements the steps of the method for implementing cross-system token access as described in any one of claims 1 to 5.

Images