Token management method based on association identifier and related device

Abstract

The invention discloses a token management method based on an association identifier and a related device, and the method comprises the steps: generating a token and a unique association identifier corresponding to the token in response to a token generation request, and building a first mapping relation between the token and the association identifier; based on the service information associated with the token, constructing an index record and establishing a second mapping relationship between the association identifier and the service dimension identifier according to a preset hierarchy rule to realize step-by-step binding of the association identifier and the service dimension index; in response to a token management request triggered by a service event, performing step-by-step screening according to the service dimension through the second mapping relationship to determine a target association identifier, and positioning a target token through the first mapping relationship; according to the application, through a two-layer mapping structure, decoupling, hierarchical management and multi-terminal independent control of the token and the service information are realized, batch efficient management is supported, and the precision, efficiency and security of token management and control are improved.

Description

Technical Field

[0001] This invention pertains to token management technology, and particularly relates to a token management method and related apparatus based on associated identifiers. Background Technology

[0002] As information systems evolve towards distributed, multi-terminal, and platform-based architectures, token-based authentication and access control mechanisms are widely used in various application scenarios. These mechanisms typically involve a server generating a token after the user or client completes authentication. The client then carries this token during subsequent accesses to verify identity status or access permissions. Due to its simplicity and scalability, the token mechanism has become a crucial foundational technology in multi-system, multi-service environments.

[0003] Most token protocols are designed around authentication processes, authorization models, and resource access control. Their focus is on how to securely generate, verify, and use tokens to ensure the security of access to protected resources. In this type of system, tokens typically exist as independent authentication credentials, and their association with users, clients, or other business entities is usually maintained through storage mapping relationships or embedded token information.

[0004] In practical applications, as system scale and business complexity increase, the same user may log in simultaneously on multiple terminals or devices, and the same platform may serve multiple client applications and multiple organizations or enterprise entities, resulting in a large number of tokens with different sources, purposes, and lifecycles existing in the system. In these scenarios, the platform often needs to manage or dispose of tokens based on different business conditions, such as uniformly processing relevant tokens during user logout, organizational relationship changes, or system maintenance.

[0005] However, existing token management methods typically focus on the token itself or a single business dimension as the primary management object, lacking a unified means of organizing and managing tokens across multiple business relationships. When querying, locating, or performing batch operations on tokens in complex business scenarios, it often relies on processing or parsing existing token information one by one, making it difficult to balance management efficiency and system performance. Furthermore, in the case of concurrent logins from multiple terminals, existing technologies also have limited independent control capabilities over tokens from different sources.

[0006] Therefore, without changing the existing basic token authentication mechanism, how to improve the platform's overall token management capabilities so that it can adapt to application environments with multiple terminals, multiple organizations, and multiple clients has become a technical problem that needs further research and improvement in the current technology. Summary of the Invention

[0007] Based on this, the present invention aims to propose a token management method and related apparatus based on association identifiers, which uses association identifiers as mappings of tokens to establish relationships with indexing rules, and realizes hierarchical indexing and batch management of tokens through hierarchical indexing rules.

[0008] In a first aspect, the present invention provides a token management method based on associated identifiers, comprising:

[0009] In response to a token generation request, a token and its associated identifier are generated, and a mapping relationship between the token and the associated identifier is established and recorded as the first mapping relationship;

[0010] Based on the business information associated with the token, an index relationship is established between the associated identifier and at least one business dimension identifier and denoted as the second mapping relationship. The business dimension identifier is determined based on the business information.

[0011] In response to a token management request triggered by a business event, the target associated identifier corresponding to the business event is determined through the second mapping relationship, and the target token is located based on the target associated identifier through the first mapping relationship;

[0012] Perform management operations corresponding to business events on the target token.

[0013] Furthermore, establishing the index relationship between the associated identifier and at least one business dimension identifier includes:

[0014] An index record for token management is constructed based on the business information associated with the token. The index record is formed by arranging at least two business dimension identifiers according to a preset hierarchical rule.

[0015] Establish a mapping relationship between index records and associated identifiers and record it as the second mapping relationship.

[0016] Furthermore, the index records for token management, constructed based on the business information associated with the token, include:

[0017] Determine at least two business dimension identifiers for token management based on the business information associated with the token;

[0018] Index records are constructed by arranging at least two business dimension identifiers according to preset hierarchical rules. The preset hierarchical rules are constructed based on preset business requirements and are used to indicate the order in which business dimension identifiers are arranged in the index records.

[0019] Furthermore, in response to a token management request triggered by a business event, the target associated identifier corresponding to the business event is determined through the second mapping relationship, and the target token is located based on the target associated identifier through the first mapping relationship, including:

[0020] Based on the business event that triggers the token management request, the target business dimension identifier and the filtering level rules of the target business dimension identifier are determined. The filtering level rules represent the filtering order of the target business dimension identifier in the index record.

[0021] Determine the target index record corresponding to the business event based on the filtering hierarchy rules;

[0022] At least one target association identifier is determined based on the target index record using the second mapping relationship;

[0023] At least one target token is located based on at least one target associated identifier through a first mapping relationship, thereby triggering a batch management operation on at least one target token.

[0024] Furthermore, before establishing the first mapping relationship, the following steps are included:

[0025] Determine the token type corresponding to the token. The token type is used to represent the category of the token in the preset token system. The mapping relationship between the token and the token type is recorded as the third mapping relationship.

[0026] Furthermore, in response to a token management request triggered by a business event, the target associated identifier corresponding to the business event is determined through the second mapping relationship, and the target token is located based on the target associated identifier through the first mapping relationship, including:

[0027] The target token type corresponding to the token management request is determined based on the business event that triggered the token management request.

[0028] The target business dimension identifier and the filtering hierarchy rules for the target business dimension identifier are determined based on the target token type. The filtering hierarchy rules represent the filtering order of the target business dimension identifier in the index record.

[0029] Determine the target index record corresponding to the business event based on the filtering hierarchy rules;

[0030] At least one target association identifier is determined based on the target index record using the second mapping relationship;

[0031] At least one target token is located based on at least one target associated identifier through a first mapping relationship, thereby triggering a batch management operation on at least one target token.

[0032] Furthermore, the token type includes one or more of user-level token types, organization-level token types, and application-level token types, and a first mapping relationship is established for different token types.

[0033] Furthermore, the business dimension identifier includes at least one of the following: user identifier, client identifier, organization identifier, terminal source identifier, and terminal source type.

[0034] Secondly, the present invention provides a token management device based on associated identifiers, comprising:

[0035] The first mapping establishment module is used to generate a token and an associated identifier corresponding to the token in response to a token generation request, and to establish and record the mapping relationship between the token and the associated identifier as the first mapping relationship;

[0036] The second mapping establishment module is used to establish an index relationship between the associated identifier and at least one business dimension identifier based on the business information associated with the token, and record it as the second mapping relationship. The business dimension identifier is determined based on the business information.

[0037] The token location module is used to respond to a token management request triggered by a business event, determine the target association identifier corresponding to the business event through a second mapping relationship, and locate the target token according to the target association identifier through a first mapping relationship;

[0038] The token management module is used to perform management operations on the target token corresponding to business events.

[0039] Thirdly, the present invention provides an electronic device including a memory storing computer-executable instructions and a processor, wherein when the computer-executable instructions are executed by the processor, the device performs the steps of the token management method based on associated identifiers provided in the first aspect.

[0040] Fourthly, the present invention provides a readable storage medium storing a computer-executable program that, when executed, implements the various steps of the token management method based on associated identifiers provided in the first aspect.

[0041] Compared with the prior art, the present invention has the following beneficial effects:

[0042] This invention proposes a token management method and related apparatus based on association identifiers. By introducing association identifiers as an intermediate hub between tokens and business entities, multi-level mapping relationships are established between tokens and association identifiers, and between association identifiers and business dimension identifiers. This achieves decoupled management of tokens and specific business entities, enabling direct binding relationships between tokens and multi-dimensional business information such as users, organizations, clients, or terminals without storing them. This reduces the complexity of the token storage structure, minimizes index redundancy, and improves storage efficiency and system scalability. A further embodiment utilizes hierarchical index records built based on preset business requirements, allowing business events to locate association identifiers level by level according to clear hierarchical rules. This enables efficient and accurate batch location and management of target tokens, avoiding traversal of all tokens. Furthermore, this invention supports combined filtering based on token type and business dimension, enabling hierarchical, isolated, and unified management of tokens at different levels and with different semantics within the same token system. This is suitable for complex business scenarios involving multiple users, organizations, clients, and terminals, significantly improving the flexibility, maintainability, and response efficiency and consistency of token management in scenarios involving business changes, organizational operations, and security controls. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0044] Figure 1 A flowchart illustrating the implementation of the token management method based on associated identifiers provided in this embodiment of the invention;

[0045] Figure 2 This is a schematic diagram of the structure of a token management device based on associated identifiers provided in an embodiment of the present invention;

[0046] Figure 3 This is an electronic device architecture diagram provided for an embodiment of the present invention. Detailed Implementation

[0047] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] See Figure 1One embodiment of the present invention proposes a token management method based on associated identifiers, comprising the following steps:

[0049] Step S110. In response to the token generation request, generate a token and an associated identifier corresponding to the token, and establish and record the mapping relationship between the token and the associated identifier as the first mapping relationship.

[0050] This step introduces an association identifier during the token generation phase to address the issues of index complexity, storage redundancy, and low management efficiency caused by the direct coupling of tokens and business entities in the token management process. Specifically, since tokens typically exist as random or encrypted strings and lack inherent business semantics, directly associating multi-dimensional business information such as users, organizations, clients, or terminals within the token storage structure can easily lead to a bloated token index structure. Furthermore, in business change or batch management scenarios, it is necessary to frequently maintain a large number of mapping relationships between tokens and business information. By introducing an independent association identifier as an intermediate hub, decoupling management of tokens and business information can be achieved without altering the token's inherent structure, providing a unified index entry point for subsequent batch location and management based on business dimensions.

[0051] The associated identifier generated in this step is used to uniquely identify the token instance and remains stable throughout the token's lifecycle, serving as an indirect location for the token during token management. In some embodiments, the associated identifier can be generated using a Universally Unique Identifier (UUID); a more preferred implementation may also use a random number identifier, serial number, or other identifier that guarantees uniqueness.

[0052] In some embodiments, the token may be an access token for accessing protected resources, a refresh token for refreshing the access token, or a session token, credential token, etc., for other business scenarios, and its specific form is not limited.

[0053] After generating the token and associated identifier, the platform establishes and records the mapping relationship between the token and the associated identifier as the first mapping relationship. This mapping relationship is used to support the quick location of the corresponding token content through the associated identifier, thereby avoiding the direct use of the token value as a search condition in subsequent token management operations.

[0054] In a further embodiment, before establishing the first mapping relationship, the token type corresponding to the generated token can be determined. The token type is used to characterize the category of the token in the preset token system, such as user-level token, organization-level token, or application-level token. In this way, the mapping relationship between the token and the token type is further established so that different types of tokens can be stored and managed independently under a unified management framework, but without affecting the role of the associated identifier as a unified index hub.

[0055] In some embodiments, the first mapping relationship can use an association identifier as an index key to store the specific content of the token or its serialization result. More preferred embodiments can also employ reverse mapping or bidirectional mapping, as long as it supports locating the token based on the association identifier; this invention does not limit this approach.

[0056] Step S120. Based on the business information associated with the token, establish an index relationship between the associated identifier and at least one business dimension identifier and record it as the second mapping relationship. The business dimension identifier is determined based on the business information.

[0057] This step establishes a mapping relationship between the associated identifier of each token and its corresponding business information, so as to efficiently and accurately locate the target token when triggered by subsequent business events. Based on the business information associated with the token, at least one business dimension identifier is identified, and an index relationship is established between the associated identifier and these business dimension identifiers, which is denoted as the second mapping relationship.

[0058] Specifically, business information describes the business context corresponding to the token, such as the user, client, organization, terminal source, or authorization scope to which the token belongs. Business dimension identifiers represent the specific attributes or dimensions of the token within the business environment. For example, user identifiers uniquely identify the user to whom the token belongs, client identifiers distinguish different application terminals, organization identifiers distinguish different organizations or enterprises, terminal source identifiers and terminal source types distinguish different terminal devices or device types, and other identifiers that can be used for business grouping and management. Through business dimension identifiers, token management can logically group and filter tokens from a business requirement perspective, providing a basis for batch management.

[0059] In a further embodiment, the mapping relationship between the association identifier and the business dimension identifier can be established by constructing an index record. The index record binds at least one business dimension identifier with the association identifier to form a key-value structure that can be directly retrieved, so that when performing token management operations, the target association identifier and the corresponding token can be quickly located through the index.

[0060] Specifically, the platform obtains relevant business information from the token generation request or business context, including but not limited to user identifier, client identifier, organization identifier, terminal source identifier, and terminal source type. Each piece of business information can correspond to one or more business dimension identifiers, which are used to indicate the business affiliation of the token in the index record. Subsequently, the order of the business dimension identifiers in the index record is determined according to preset business requirements. This hierarchical rule is used to indicate the order of different business dimension identifiers in the index record, thereby providing a path basis for subsequent step-by-step filtering.

[0061] In a further embodiment, to support complex business needs, the index records are constructed using a hierarchical structure. A hierarchical index record refers to an index record containing multiple business dimension identifiers, which are arranged according to preset hierarchical rules to reflect the priority or filtering order among business dimensions.

[0062] Specifically, index records can be arranged in the order of client identifier, user identifier, organization identifier, terminal source identifier, etc., with each level corresponding to a business dimension identifier, forming an index path that can be filtered level by level. Preset hierarchical rules can be determined based on business requirements, indicating the order in which different business dimension identifiers are arranged in the index records. For example, in some business scenarios, token management typically uses the client as the first level and the organization as the second level; in this case, the order of business dimension identifiers in the index records could be client identifier first, followed by organization identifier. Different ordering can be used in other business scenarios.

[0063] For example, in the scenario of organizational dissolution, the client dimension is prioritized over the organization dimension for filtering; while in the scenario of user logout, the user dimension may be prioritized over the terminal dimension for filtering. Through hierarchical indexing records, the platform can locate the target association identifier step by step according to the business logic when different business events are triggered, thereby improving the efficiency of batch operations and reducing traversal costs.

[0064] In some further embodiments, the index record can adopt a key-value storage format, with hierarchical business dimension identifiers forming the index key and the associated identifiers serving as the index value; in other embodiments, a bidirectional mapping or multi-level mapping structure can also be adopted, so that the index record can both support locating associated identifiers from the business dimension and supporting reverse retrieval of business dimension information from associated identifiers, thereby enhancing the system's flexibility and scalability.

[0065] In some embodiments, the platform provides multiple optional values ​​for each business dimension identifier, such as simultaneously recording device type and device ID in the terminal source dimension, thereby allowing index records to support finer-grained positioning during filtering. A more preferred implementation allows index records to be stored as a hash structure or a dictionary structure, making querying, updating, and batch deleting operations on index records more efficient.

[0066] Step S130. In response to a token management request triggered by a business event, determine the target association identifier corresponding to the business event through the second mapping relationship, and locate the target token based on the target association identifier through the first mapping relationship.

[0067] Specifically, the platform receives business events and parses the business information they contain. By parsing the business events, it determines the target business dimension identifiers and the filtering hierarchy rules for each business dimension identifier. The filtering hierarchy rules are used to indicate the step-by-step filtering order of the target business dimension identifiers in the index records. For example, filtering can be performed first based on the client dimension, then on the organization dimension, and finally on the user dimension or terminal dimension, thus forming a filtering path that conforms to business logic. The business events can be any business behavior that requires the management of a set of tokens, such as user logout, organization dissolution, client offline, terminal failure, or permission change.

[0068] Subsequently, based on the established filtering hierarchy rules, index records are filtered level by level in the second mapping relationship. Specifically, filtering begins with the highest-level business dimension identifier of the index record, matching the business information provided by the business event, and then matching other dimension identifiers layer by layer downwards until the filtering is complete and the target index record is locked. Through the target index record, the platform can obtain at least one target associated identifier, and then locate at least one target token based on the at least one target associated identifier through the first mapping relationship, thereby triggering batch management operations on at least one target token.

[0069] It should be noted that in the embodiments of the present invention, there is a one-to-one correspondence between index records and associated identifiers, and each index record has a unique combination of business dimensions, which facilitates accurate location of target associated identifiers based on business events.

[0070] In a further embodiment, before locating the associated identifier, the target token type can be determined based on the business event. The token type is used to constrain the business dimension identifiers and hierarchical rules required for subsequent filtering. For example, the index record corresponding to an organization-level token must contain an organization identifier, while the index record for a user-level token may not contain an organization identifier. By determining the token type in advance, the platform can achieve hierarchical positioning of different types of tokens under a unified index structure, avoiding confusion between different types of tokens and improving management accuracy.

[0071] In a further embodiment, the determined target association identifier is mapped to the corresponding target token through the first mapping relationship. This can be achieved by key-value query, hash retrieval, or bidirectional mapping to ensure that the target token set can still be located efficiently in a large-scale token storage environment.

[0072] In other embodiments, the platform can optimize batch location operations triggered by business events, for example by querying index records at different levels in parallel, caching or preloading index records, or adopting a partition management strategy for index records, thereby maintaining high performance and low latency when processing a large number of business events.

[0073] The embodiments of the present invention can accurately and quickly locate target associated identifiers and their corresponding tokens in batches according to business events and preset hierarchical rules in complex business scenarios, providing a precise basis for subsequent token management operations, while ensuring hierarchical isolation management of different types of tokens.

[0074] Step S140. Perform the management operation corresponding to the business event on the target token.

[0075] The management operations performed in this step include, but are not limited to, deleting, updating, or adjusting permissions of tokens to meet different business needs.

[0076] In a further embodiment, since each index record and its associated identifier have a one-to-one correspondence, the platform can maintain high-precision positioning when managing target tokens in batches, avoiding erroneous operations. For example, in a batch deletion operation, each target associated identifier is parsed sequentially according to the hierarchical order of the index records, and the corresponding target token is obtained through the first mapping relationship. Deletion or invalidation operations are then performed individually or in groups. This ensures both the efficiency of batch management operations and avoids token misprocessing caused by duplicate or mixed indexes.

[0077] In some embodiments, differentiated operations can be performed in conjunction with token type constraints. For example, for user-level tokens, logs can be logged or terminals can be notified before expiration; for organization-level tokens, business processes related to the management of organization members can be triggered; and for application-level tokens, permission adjustments or access scope restrictions can be implemented.

[0078] For example, for a user account cancellation event, step S130 locates the client or terminal where the user's account to be cancelled is located, thereby locating the target token set corresponding to the terminal or client, and performing a cancellation operation on the target token so that it cannot be accepted by the authentication server the next time it is used; for an organization dissolution event, the application to be dissolved can be determined according to the event, and then all associated identifiers corresponding to the organization-level token under the application can be located, and all target tokens can be invalidated or deleted to achieve organization-level cascading management; for a terminal failure or device offline event, the target token can be accurately located according to the terminal source dimension, and an independent logout operation can be performed to achieve independent control of multiple terminals.

[0079] In addition, to improve batch management efficiency, parallel processing strategies, index record caching, or partitioned storage methods can be used to perform management operations. A more preferred implementation can be combined with security policies, such as verifying the source of business event triggering, device information, or IP address, to ensure that the source of operation requests is trustworthy and to prevent misoperation or malicious operation.

[0080] The disclosed method can be implemented using various types of devices. Therefore, the present invention also discloses an apparatus corresponding to the above method, and specific embodiments are given below for detailed description.

[0081] like Figure 2 As shown, one embodiment of the present invention provides a token management device based on associated identifiers, comprising:

[0082] The first mapping establishment module 202 is used to generate a token and an associated identifier corresponding to the token in response to a token generation request, and to establish and record the mapping relationship between the token and the associated identifier as the first mapping relationship;

[0083] The second mapping establishment module 204 is used to establish an index relationship between an associated identifier and at least one business dimension identifier based on business information associated with the token and record it as the second mapping relationship. The business dimension identifier is determined based on the business information.

[0084] The token location module 206 is used to respond to a token management request triggered by a business event, determine the target association identifier corresponding to the business event through a second mapping relationship, and locate the target token according to the target association identifier through a first mapping relationship;

[0085] The token management module 208 is used to perform management operations on the target token corresponding to the business event.

[0086] The device provided in this application embodiment has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0087] The methods and related apparatuses mentioned in the above embodiments are described with reference to the method flowcharts and / or structural diagrams provided in the embodiments of this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0088] The following embodiments illustrate the application of this method to a computer device. It is understood that the computer device can be any device with computing and processing capabilities, including but not limited to servers or personal laptops. In one embodiment, the computer device can be an application server, which can be a server used to run the application under test.

[0089] See Figure 3 This document illustrates a hardware block diagram of an electronic device intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.

[0090] like Figure 3 As shown, the electronic device includes: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0091] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;

[0092] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0093] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0094] The memory stores a program, which the processor can call. The program is used to implement the various processing flows of the aforementioned token management scheme based on association identifier.

[0095] This invention also provides a readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements various processing flows of the token management scheme based on associated identifiers provided in any possible implementation of the above embodiments and / or in combination with the embodiments.

[0096] The invention has been described in particular detail above with respect to possible scenarios, and those skilled in the art will recognize that the invention can be practiced through other embodiments. Specific naming of components, capitalization of terms, attributes, data structures, or any other programming or structural aspects are not mandatory or important, and the mechanisms or features of implementing the invention may have different names, forms, or procedures. The system can be implemented through a combination of hardware and software (as described), entirely through hardware elements, or entirely through software elements. The specific division of functions among the various system components described herein is merely exemplary and not mandatory; rather, the functions performed by a single system component can be performed by multiple components, or the functions performed by multiple components can be performed by a single component.

[0097] Those skilled in the art should understand that the various steps of the disclosed methods can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using device-executable program code, which can then be stored in a storage device for execution by the computing device. Alternatively, they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Therefore, the embodiments disclosed in this invention are not limited to any specific hardware and software combination.

[0098] The programs (also referred to as programs, software, software applications, or code) executable by these computing devices include machine instructions of a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0099] Certain aspects of this invention include the process steps and instructions described herein in algorithmic form. It should be noted that the process steps and instructions of this invention can be implemented in software, firmware, and / or hardware, and when implemented in software, they can be downloaded, stored on various operating systems and operated from said platforms.

[0100] Those skilled in the art will understand that the structures shown in the figures are merely block diagrams of some structures related to the present application and do not constitute a limitation on the terminal device to which the present application is applied. Specific terminal devices may include more or fewer components than those shown in the figures, or combine certain components, or have different component arrangements.

[0101] In the description of this specification, the use of terms such as "one embodiment," "some embodiments," "example," "specific example," or "possible design," etc., refers to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0102] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0103] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention 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. Such 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 the present invention.

Claims

1. A token management method based on associated identifiers, characterized in that, include: In response to a token generation request, a token and its associated identifier are generated, and a mapping relationship between the token and the associated identifier is established and recorded as the first mapping relationship; Based on the business information associated with the token, an index relationship is established between the associated identifier and at least one business dimension identifier and denoted as the second mapping relationship, wherein the business dimension identifier is determined based on the business information; In response to a token management request triggered by a business event, the target associated identifier corresponding to the business event is determined through the second mapping relationship, and the target token is located according to the target associated identifier through the first mapping relationship; Perform management operations corresponding to the business event on the target token.

2. The method according to claim 1, characterized in that, The step of establishing an index relationship between the associated identifier and at least one business dimension identifier, and recording it as a second mapping relationship, includes: An index record for token management is constructed based on business information associated with the token. The index record is formed by arranging at least two business dimension identifiers according to a preset hierarchical rule. Establish a mapping relationship between the index records and the associated identifiers, and denot it as the second mapping relationship.

3. The method according to claim 2, characterized in that, The index records for token management constructed based on business information associated with the token include: Determine at least two business dimension identifiers for token management based on the business information associated with the token; An index record is constructed by arranging at least two business dimension identifiers according to a preset hierarchical rule. The preset hierarchical rule is constructed based on preset business requirements and is used to indicate the order in which the business dimension identifiers are arranged in the index record.

4. The method according to claim 1, characterized in that, The step of responding to a token management request triggered by a business event, determining the target association identifier corresponding to the business event through the second mapping relationship, and locating the target token based on the target association identifier through the first mapping relationship includes: The target business dimension identifier and the filtering hierarchy rules for the target business dimension identifier are determined based on business events. The filtering hierarchy rules represent the filtering order of the target business dimension identifier in the index records. The target index record corresponding to the business event is determined according to the filtering hierarchy rules; At least one target association identifier is determined based on the target index record using the second mapping relationship; At least one target token is located based on at least one target associated identifier through the first mapping relationship, thereby triggering a batch management operation on at least one target token.

5. The method according to claim 1, characterized in that, Before establishing the first mapping relationship, the following steps are included: Determine the token type corresponding to the token. The token type is used to represent the category of the token in the preset token system. The mapping relationship between the token and the token type is recorded as the third mapping relationship.

6. The method according to claim 5, characterized in that, The token types include one or more of user-level token types, organization-level token types, and application-level token types, and a first mapping relationship is established for different token types.

7. The method according to claim 5, characterized in that, The step of responding to a token management request triggered by a business event, determining the target association identifier corresponding to the business event through the second mapping relationship, and locating the target token based on the target association identifier through the first mapping relationship includes: Determine the target token type corresponding to the token management request based on the business event; The target business dimension identifier and the filtering hierarchy rules for the target business dimension identifier are determined based on the target token type. The filtering hierarchy rules represent the filtering order of the target business dimension identifier in the index record. The target index record corresponding to the business event is determined according to the filtering hierarchy rules; At least one target association identifier is determined based on the target index record using the second mapping relationship; At least one target token is located based on at least one target associated identifier through the first mapping relationship, thereby triggering a batch management operation on at least one target token.

8. A token management device based on associated identifiers, characterized in that, include: The first mapping establishment module is used to generate a token and an associated identifier corresponding to the token in response to a token generation request, and to establish and record the mapping relationship between the token and the associated identifier as the first mapping relationship; The second mapping establishment module is used to establish an index relationship between the associated identifier and at least one business dimension identifier based on the business information associated with the token, and record it as the second mapping relationship. The business dimension identifier is determined based on the business information. The token location module is used to respond to a token management request triggered by a business event, determine the target association identifier corresponding to the business event through a second mapping relationship, and locate the target token according to the target association identifier through a first mapping relationship; The token management module is used to perform management operations on the target token corresponding to business events.

9. An electronic device, characterized in that, It includes a memory storing computer-executable instructions and a processor, which, when executed by the processor, causes the device to perform the token management method based on an associated identifier as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, It stores a computer-executable program that, when executed, implements the token management method based on associated identifiers as described in any one of claims 1 to 7.

Images