Storage method and device of access token, equipment and storage medium

Abstract

The invention discloses an access token storage method and device, equipment and a storage medium, and relates to the technical field of computers. The method comprises the following steps: receiving an authentication authorization request; generating a first access token of the first user account for the first application; token information of the first access token is stored in the first database and the second database, the token information of the first access token comprises the first access token and related information of the first access token, and the information stored in the first database is a subset of the information stored in the second database; the access efficiency of the first database is higher than the storage efficiency of the second database; and deleting the token information of the first access token from the first database based on a pre-configured deletion strategy. According to the method, cold and hot separated storage of the access token is realized, and system resources are reasonably and efficiently utilized, so that the service efficiency of an account risk control system is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for storing access tokens. Background Technology

[0002] With the development of computer technology, the number of users of various software applications is increasing daily. Account risk control systems provide convenient and secure user authentication services for various software applications.

[0003] In related technologies, after successfully verifying a user's identity, the account risk control system generates a corresponding token. Before returning the token to the user, the token information is saved in the database so that it can be verified when the user uses the token to request business services later.

[0004] In related technologies, account risk control systems store all token information in the same database, but the token information that is frequently used is relatively small, meaning that the database stores a large amount of idle token information, thus wasting storage resources. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for storing access tokens. The technical solution provided by this application is as follows:

[0006] According to one aspect of the embodiments of this application, a method for storing access tokens is provided, the method comprising:

[0007] Receive an authentication and authorization request, the authentication and authorization request being used to request authentication and authorization for the first user account to access the first application;

[0008] Generate a first access token for the first user account in the first application. The first access token is used to access the user information of the first user account in the first application.

[0009] In the first database and the second database, the token information of the first access token is stored. The token information of the first access token includes the first access token and related information of the first access token. The information stored in the first database is a subset of the information stored in the second database, and the access efficiency of the first database is higher than the storage efficiency of the second database.

[0010] Based on a pre-configured deletion policy, the token information of the first access token is deleted from the first database.

[0011] According to one aspect of the embodiments of this application, a storage device for access tokens is provided, the device comprising:

[0012] The request receiving module is used to receive authentication and authorization requests, which are used to request authentication and authorization for the first user account to access the first application.

[0013] The token generation module is used to generate a first access token for the first user account in the first application. The first access token is used to access the user information of the first user account in the first application.

[0014] An information storage module is used to store token information of the first access token in a first database and a second database. The token information of the first access token includes the first access token and related information of the first access token. The information stored in the first database is a subset of the information stored in the second database, and the access efficiency of the first database is higher than the storage efficiency of the second database.

[0015] The information deletion module is used to delete the token information of the first access token from the first database based on a pre-configured deletion policy.

[0016] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described method for storing access tokens.

[0017] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the storage medium, the computer program being loaded and executed by a processor to implement the above-described method for storing access tokens.

[0018] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the above-described method for storing access tokens.

[0019] The technical solutions provided in this application have at least the following beneficial effects:

[0020] By storing access tokens generated for user accounts of a specified application simultaneously in a first database and a second database, and then deleting the token information of the first access token from the first database based on a pre-configured deletion policy, while retaining the token information of the first access token in the second database, the access efficiency of the first database is higher than that of the second database. This method achieves cold and hot token separation storage and reasonable and efficient use of system resources by using two databases to store the token information of access tokens and using a deletion policy to remove the token information of access tokens with low access frequency from the first database, thereby improving the service efficiency of the account risk control system. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the implementation environment of a solution provided in one embodiment of this application;

[0022] Figure 2 This is a system architecture diagram of an account risk control system provided in one embodiment of this application;

[0023] Figure 3 This is a flowchart of an access token storage method provided in one embodiment of this application;

[0024] Figure 4 This is a schematic diagram of an application configuration interface provided in one embodiment of this application;

[0025] Figure 5 This is a flowchart illustrating the use of an access token to request a service, as provided in one embodiment of this application.

[0026] Figure 6 This is a timing diagram of the access token generation process provided in one embodiment of this application;

[0027] Figure 7 This is a timing diagram of a service request process provided in one embodiment of this application;

[0028] Figure 8 This is a block diagram of an access token storage device provided in one embodiment of this application;

[0029] Figure 9 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0030] 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.

[0031] Please refer to Figure 1The diagram illustrates an implementation environment provided in one embodiment of this application. This implementation environment can be implemented as a computer system, and may include: a server 10, a management terminal 20, a tenant terminal 30, and a user terminal 40.

[0032] The computer system includes an account risk control system. This system provides authentication, user management, and risk control identification services for multiple applications. The account risk control system can use at least one of the following authentication methods: password, SMS verification code, email verification code, facial recognition, etc., and other verification methods are not limited in this application. Server 10 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, but is not limited to these. Server 10 can function as an account risk control system.

[0033] Management terminal 20, tenant terminal 30, and user terminal 40 can access the account risk control system via the network to obtain services provided by the account risk control system and configure relevant information about the account risk control system, applications, and users. This network can be a wired network or a wireless network.

[0034] Management terminal 20 is a terminal device used to run the management application of the account risk control system, and is used for system configuration, management and maintenance of the account risk control system.

[0035] Tenant terminal 30 is a terminal device used to run the tenant application of the account risk control system, and is used to provide the tenant of the account risk control system with the service of configuring the basic information of the application.

[0036] User terminal 40 is a terminal device used to run an application as a client. Optionally, the user application can be an application that needs to be downloaded and installed, or it can be a webpage or an app; this embodiment of the application does not limit this.

[0037] In this application embodiment, the user application may include, but is not limited to, any one of the following: game applications, social applications, interactive entertainment applications, office applications, utility applications, health management applications, educational applications, e-commerce applications, map applications, etc.

[0038] Terminal devices include, but are not limited to, mobile phones, tablets, smart voice interaction devices, game consoles, wearable devices, multimedia playback devices, PCs (Personal Computers), in-vehicle terminals, smart home appliances, AR (Augmented Reality) devices, VR (Virtual Reality) devices, and other electronic devices.

[0039] The following is a brief introduction to the system architecture of the account risk control system.

[0040] Please refer to Figure 2 The diagram illustrates the system architecture of an account risk control system provided in one embodiment of this application. This system architecture includes three roles: administrator, tenant, and user, and implements functions including, but not limited to, system configuration, user management, application management, authentication and authorization, and business service interfaces.

[0041] The account risk control system provides authentication, user management, and risk control identification services to at least one tenant through multi-tenancy technology and the OAuth standard. Any tenant can manage at least one application (hereinafter referred to as "application") and the users within that application through the account risk control system.

[0042] Multi-tenancy technology is a software architecture technique used to enable the sharing of the same system or program components in a multi-user environment. Resources and configurations are isolated between different tenants, and each tenant can personalize the rented instance according to its own needs.

[0043] OAuth is an open standard that allows users to grant third-party applications access to their private resources (such as photos, videos, and contact lists) stored on a website without requiring them to provide their username and password. OAuth allows users to provide an access token, instead of a username and password, to access data stored with a specific service provider. Each access token authorizes a specific website (e.g., a video editing website) to access specific resources (e.g., just videos in a particular album) for a specific period of time (e.g., the next two hours). In this way, OAuth allows users to authorize third-party websites to access certain specific information, not all of their data, stored with another service provider.

[0044] (1) User Management: Tenants maintain the user attribute information in the account risk control system through user management, including but not limited to: user account, login name, login method, gender and other attribute information. The user attribute information can appear in the access token through the declaration configured by the application, so that the requester using the access token can conveniently and controllably obtain user information.

[0045] (2) Application Management: Tenants can configure basic information of applications through application management, including but not limited to: application name, application start / stop status, application access address, access token validity period, refresh access token validity period, declaration, etc. This configuration information will indicate the validity period of the access token when the user authorized by the application generates the access token, and will include the attribute information of the user specified in the declaration configuration in the access token.

[0046] (3) System configuration: The administrator of the account risk control system 30 configures the necessary information for the normal operation of the account risk control system 30 through system configuration, such as configuring the storage time of the access token in the first database.

[0047] (4) Authentication and authorization: When a user sends an authentication and authorization request to the account risk control system 30 through the client of the target application, the account risk control system 30 authenticates the authentication and authorization request. If the authentication and authorization request is successfully authenticated, the account risk control system 30 generates an access token and returns the token information of the access token to the client.

[0048] In related technologies, account risk control systems store all access tokens in a single database. However, only about 20% of all access tokens are actually actively used; the remaining 80% are never reused from creation to expiration. Therefore, this technology can cause the following problems:

[0049] (1) Waste of resources: When all access tokens are stored in a memory-based database, since the database improves access and usage performance through memory, storing restricted access tokens in the database will result in a huge waste of memory resources;

[0050] (2) Poor performance: When the number of access tokens stored in the database is huge, all the access tokens are laid out at the same level. The key-value storage of the database will have hash collision problems. It is inevitable to resolve the collisions. This also means that in the scenario of storing a large number of access tokens, the access speed for accessing the conflicting key-values ​​cannot reach O(1).

[0051] (3) Uncontrollable risks: Due to the unpredictable nature of user login or access token usage, the number of access tokens in the same period cannot be accurately predicted, and it is impossible to prepare a database of appropriate capacity in advance. In a database cluster that does not support automatic expansion, if a sudden surge in a large number of access tokens leads to insufficient database resources or failure, it will cause a service avalanche failure of the entire account risk control system.

[0052] Please refer to Figure 3The diagram illustrates a flowchart of an access token storage method according to an embodiment of this application. The execution entity for each step of this method can be... Figure 1 Server 10 in the implementation environment of the illustrated scheme. The method may include at least one of the following steps (310-340):

[0053] Step 310: Receive an authentication and authorization request, which is used to request authentication and authorization for the first user account to access the first application.

[0054] An authentication and authorization request refers to the process by which a primary application requests user authentication and authorization from the account risk control system. When a user attempts to access resources within a primary application that requires authentication or authorization, the primary application will be redirected to the account risk control system and send an authentication and authorization request to it. These resources may include, but are not limited to: web page content, multimedia files, user information, social interactions, emails, cloud storage, and application programming interfaces (APIs). The primary application is the application the user needs to access.

[0055] In some embodiments, the first client sends an authentication and authorization request to the account risk control system. Correspondingly, the account risk control system receives the authentication and authorization request sent by the first client.

[0056] In some embodiments, the authentication authorization request includes a first user account, account password, and identification information of a first application. The identification information of the first application is used to uniquely identify the first application. Optionally, the identification information may be represented in at least one of the following ways: number, label, name, etc., or other ways, which are not limited in this application.

[0057] The first user account refers to the user account used to log in to the first application. A user account is an identity identifier assigned to a user, used to identify and manage the first user's personal information, permissions, and access control. Optionally, a user account includes at least one of the following elements: username, password, personal information, permissions, and access control, and may also include other elements, which are not limited in this application. The types of user accounts include, but are not limited to, the following: local accounts, third-party accounts, enterprise accounts, and administrator accounts. A local account is an account created and managed by the user in the first application, requiring the user to provide information such as username and password during registration. For example, the first user account is a user account created by the first user in the first application. A third-party account refers to an account managed by a third-party identity provider, through which the user can log in to the first application. For example, the first user account is a third-party account, and the first user uses the third-party account to log in to the first application. An enterprise account is a user account provided by an enterprise or organization, used for authentication and access control within the enterprise or for specific services. For example, the first application is an internal enterprise application, the first user account is a user account provided by the enterprise, and the first user logs in to the first application through the first user account. An administrator account refers to a user account with special permissions and control rights, used for managing and maintaining the first application. For example, the first user account is the administrator account of the first application, which can configure, manage and maintain the first application.

[0058] In some embodiments, the authentication authorization request includes the identification information of the first application and the account password information of the first user account; before performing step 320, the validity of the first application is verified based on the identification information of the first application; if the first application is valid, the validity of the account password information of the first user account is verified; if the account password information of the first user account is valid, the step of generating a first access token for the first user account for the first application is performed.

[0059] In some embodiments, application information of the first application is obtained from a second database based on the identification information of the first application. If the application information of the first application is found in the second database, the first application is determined to be valid; if the application information of the first application is not found in the second database, the first application is determined to be invalid. The second database stores application information of at least one application and user information of at least one user. The application information may include, but is not limited to, the application's name, its on / off status, and its access address. Optionally, if the application information of the first application is found in the second database and the first application is in an on state, the first application is determined to be valid. The user information includes, but is not limited to, user account, account password, account status, username, mobile phone number, email address, and user address.

[0060] In some embodiments, user information of the first user account is obtained from the second database based on the first user account; if application information of the first application is found in the second database and the user status of the first user account is enabled, the first user account is determined to be valid; if application information of the first application is not found in the second database, or if the user status of the first user account is disabled, the first user account is determined to be invalid.

[0061] By using the above method, users who need to access the first application are authenticated. Only when the user is successfully authenticated is an access token for accessing the first application generated, thereby improving the security of the first application.

[0062] Step 320: Generate a first access token for the first user account in the first application. This first access token is used to access the user information of the first user account in the first application.

[0063] A token is a data structure used to represent identity, access permissions, or other information for authentication, authorization, and access control. Token types include, but are not limited to, access tokens, ID (Identifier) ​​tokens, refresh tokens, session tokens, and API tokens. Specifically, an access token is used for authentication and access control, requesting access to resources from a protected resource server. An ID token identifies a user and provides user information. It includes basic user information (such as username, email address, etc.) and other relevant information, used by client applications to obtain information about the user. A session token represents a user's session state. It is generated when a user logs in and expires when the user logs out or the session expires, indicating the user's current login state. An API token is used for authentication when sending requests to an API. API tokens are used for access control and authorization of APIs, allowing client applications to access protected API resources.

[0064] An access token generated by an authentication protocol based on OAuth 2.0 is a string used by the OAuth client to make requests to the resource server. The access token does not need to be in any specific format; the token type can be either "bearer tokens" or "sender-constrained" tokens. Many properties of the access token are crucial to the OAuth security model: 1) The OAuth client must not read or interpret the access token. The OAuth client is not the target audience for the access token. 2) The access token does not convey the user's identity or any other information about the user to the OAuth client. 3) The access token can only be used to make requests to the resource server. Furthermore, ID tokens must not be used to make requests to the resource server. In this embodiment, the OAuth client corresponds to the first client, and the resource server corresponds to the first application.

[0065] In some embodiments, application configuration information of a first application is obtained. This application configuration information is used to indicate information for configuring the access token of the first application. The application configuration information of the first application is configured by the tenant for the first application through the application management of the account risk control system. This application configuration information includes, but is not limited to, the validity period of the access token generated for the first application, the validity period of the refresh token, and claims. The validity period of the token refers to the time period from issuance to expiration of the token. Claims refer to certain statements or assertions about a user, used to describe the user's attributes, identity information, or other relevant information, including but not limited to username, user ID, permissions, gender, mobile phone number, address, email address, etc.

[0066] For example, please refer to Figure 4 This document illustrates a schematic diagram of an application configuration interface provided in one embodiment of this application. In the application configuration interface 40, the tenant configures the first application to verify the authentication and authorization request sent to the first client, returning an authorization code and a redirection URI (Uniform Resource Identifier) ​​address 41 for the access token. After the access token expires, the user logs out of the first application, and the tenant configures the redirection URI address 42 for the first application after the user logs out. The tenant configures the access token's validity period 43 to be 60 seconds, meaning the access token will expire if it is not refreshed within 60 seconds of being issued. A refresh token is enabled 44, and its validity period 45 is 604800 seconds, meaning the refresh token will expire 604800 seconds after being issued. The tenant configures the declaration 46 as "gender" and "username," meaning the user information returned to the caller is the user's "gender" and "username."

[0067] Step 330: In the first database and the second database, the token information of the first access token is stored. The token information of the first access token includes the first access token and related information of the first access token. The information stored in the first database is a subset of the information stored in the second database, and the access efficiency of the first database is higher than the storage efficiency of the second database.

[0068] The first database is a database based on storage media or systems with fast data read / write capabilities and efficient data retrieval capabilities. For example, the first database may be a database based on memory or a solid-state drive (SSD). The first database can be one of the following: Redis, Memcached, Hazelcast, Apache Ignite, VoltDB, etc., or other databases; this application does not limit its scope. The second database is a database based on storage media or systems with lower performance and lower cost. For example, the second database may be a database based on disk storage or tape storage. The second database can be one of the following: MongoDB, MySQL, CouchDB, etc., or other databases; this application does not limit its scope. Optionally, the first database is a Redis database, and the second database is a MongoDB database.

[0069] Token information is used to identify, verify, and authorize user identity, access permissions, and other information. Token information may include, but is not limited to: the identifier of the authorized application, the identifier of the authorized user, the start time of authorization, the end time of authorization, and the scope of authorized permissions, etc. Token information may also include other information, which is not limited in this application.

[0070] In some embodiments, the token information of the first access token is sent to the first client. Optionally, after successful authentication and authorization by the account risk control system, the token information returned to the first client is returned in the form of the following token information structure:

[0071] {

[0072] "access_token": "xxx...xxx",

[0073] "refresh_toekn": "xxx...xxx",

[0074] "scope": "openid",

[0075] "id_token": "xxx...xxx",

[0076] "token_type": "xxx...xxx",

[0077] "expire_in": 299

[0078] In the token information structure described above, the "access_token" field indicates the access token; the "refresh_token" field indicates the refresh token, used to obtain a new access token; the "scope" field indicates the scope of permissions for the access token; the "id_token" field indicates the identity token, a token used to represent user identity information; the "token_type" field indicates the token type, whether it's just an access token or a refresh token; and the "expire_in" field indicates the expiration date of the access token. For example, the descriptions of the fields in the token information structure of the OAuth 2.0-based identity authentication protocol are shown in Table 1.

[0079] Table 1. Description of each field in the token information structure

[0080] Fields Data types describe access_token String OAuth 2.0 Access Token (JWT) refresh_token String OAuth 2.0 refresh token scope String Access token permission scope id_token String OIDC ID Token (JWT) token_type String Token type, takes a fixed value Bearer expires_in Number Access token validity period, in seconds

[0081] Step 340: Based on the pre-configured deletion policy, delete the token information of the first access token from the first database.

[0082] The pre-configured deletion policy described above can be pre-configured by the administrator of the account risk control system or by the tenant; this application does not limit this. The deletion policy refers to the rules or algorithms used to determine which token information needs to be deleted from the first database to free up storage space. Optionally, the deletion policy can be designed based on factors such as the access pattern of the token information, the storage capacity of the database, and performance requirements; this application does not limit this.

[0083] The following describes two types of deletion strategies.

[0084] (i) Deletion strategy based on duration threshold

[0085] In some embodiments, a first unused duration corresponding to the first access token is determined, wherein the first unused duration refers to the duration during which the token information of the first access token stored in the first database is not used; if the first unused duration is greater than the duration threshold corresponding to the first access token, the token information of the first access token is deleted from the first database.

[0086] The first unused time period can refer to the time interval from the last time the first access token was used to the current time, or it can refer to the time interval from the time the first access token was stored in the first database to the current time.

[0087] In some embodiments, if the first access token is successfully accessed, the last time the first access token was used is updated to the current time.

[0088] In some embodiments, the token information in the first database is periodically scanned according to a clearing period, wherein the clearing period is used to indicate the time interval for clearing expired token information in the first database; for any access token, if the unused duration is longer than the duration threshold corresponding to the access token, the token information of the token is deleted from the first database.

[0089] Optionally, a deletion command in the first database is used to set a duration threshold for the token information in the first database. When the storage time of any token information in the first database exceeds the duration threshold, the first database automatically deletes the token information.

[0090] By setting a time limit for access token information in the first database, the first database can promptly delete infrequently used token information, thereby ensuring that the account risk control system can make the most of its resources.

[0091] In some embodiments, the duration threshold can be determined in at least one of the following ways:

[0092] (1) The pre-configured fixed value is determined as the duration threshold corresponding to the first access token;

[0093] (2) Determine the duration threshold corresponding to the first access token based on the validity period of the first access token;

[0094] (3) Determine the duration threshold corresponding to the first access token based on the access frequency of the first access token.

[0095] For the above method (1), the pre-configured fixed value can be set by the administrator of the account risk control system, and this application does not limit this.

[0096] In some embodiments, system configuration information and application configuration information of a first application are obtained from a second database; wherein, the system configuration information includes a first duration, which is a pre-set duration for which the token information of a first access token is stored in the second database, and the application configuration information includes a second duration, which is a pre-set duration for which the token information of a first access token is stored in the first database; if the first duration is less than the second duration, the first duration is determined as the duration threshold of the first access token; if the first duration is greater than the second duration, the second duration is determined as the duration threshold of the first access token.

[0097] For example, if the system configuration information pre-sets a first duration of 1 day and the application configuration information pre-sets a second duration of 2 days, then the first duration is less than the second duration, and the duration threshold of the first access token is 1 day.

[0098] For example, if the system configuration information pre-sets a first duration of 1 day and the application configuration information pre-sets a second duration of 30 minutes, then the first duration is longer than the second duration, and the duration threshold of the first access token is 30 minutes.

[0099] For the above method (2), the duration threshold of the access token is dynamically set according to the validity period of the access token.

[0100] In some embodiments, for a first validity period level among multiple validity period levels, if the validity period of a first access token is greater than the lower limit of the first validity period level and less than or equal to the upper limit of the first validity period level, then the duration threshold coefficient corresponding to the first validity period level is determined as the duration threshold coefficient of the first access token; or, if the validity period of the first access token is greater than the lower limit of the maximum validity period level, then the duration threshold coefficient corresponding to the maximum validity period level is determined as the duration threshold coefficient of the first access token; based on the duration threshold coefficient of the first access token and the validity period of the first access token, the duration threshold of the first access token is determined. Each validity period level corresponds to a duration threshold coefficient, and the range of validity period levels and the corresponding duration thresholds are set by the administrator of the account risk control system; this application does not limit this.

[0101] For an access token, since the default session validity period for most applications is 24 minutes, the probability of it being accessed again within 30 minutes of creation is highest. Applications that require daily logins are also more common, so the probability of it being accessed again within 48 hours of creation is also relatively high. Since some applications support 7 days of login-free access, the probability of it being accessed again within 7 days of creation decreases. Finally, the probability of it being accessed again within 7 days of creation is the lowest. Therefore, over time, the probability of an access token being accessed again decreases.

[0102] The first validity period level mentioned above is any one of multiple validity period levels. The highest validity period level only has a lower limit for validity period, but no upper limit for validity period.

[0103] For example, please refer to Table 2 below. When the validity period of the first access token is greater than 0 and less than or equal to 30 minutes, the duration threshold of the first access token is determined as the validity period of the first access token. When the validity period of the first access token is greater than 30 minutes and less than or equal to 48 hours, the duration threshold coefficient of this validity period level is 85%, and the duration obtained by multiplying the duration threshold of the first access token by the duration threshold coefficient is determined as the validity period of the first access token. When the validity period of the first access token is greater than 48 hours and less than or equal to 7 days, the duration threshold coefficient of this validity period level is 70%, and the duration obtained by multiplying the duration threshold of the first access token by the duration threshold coefficient is determined as the validity period of the first access token. When the validity period of the first access token is greater than 7 days, the duration threshold coefficient of this validity period level is 50%, and the duration obtained by multiplying the duration threshold of the first access token by the duration threshold coefficient is determined as the validity period of the first access token.

[0104] Table 2 Validity Levels and Duration Thresholds

[0105] Validity level Duration threshold (0, 30) minutes Access token validity period (30 minutes, 48 ​​hours) Access token validity period * 85% (48 hours, 7 days) Access token validity period * 70% More than 7 days Access token validity period * 50%

[0106] For the above method (3), the access frequency of the first access token refers to the number of times the first access token is accessed within a certain period of time.

[0107] In some embodiments, for a first access level among multiple access levels, if the access of the first access token is greater than the lower limit of the first access level and less than or equal to the upper limit of the first access level, then the duration threshold coefficient corresponding to the first access level is determined as the duration threshold coefficient of the first access token; the duration threshold of the first access token is determined based on the duration threshold coefficient of the first access token and the validity period of the first access token.

[0108] The first access level mentioned above is any one of multiple access levels.

[0109] By using the above method, the storage time of the access token in the first database can be controlled by pre-setting or dynamically adjusting the duration threshold of the access token. This helps to maximize the user's efficiency and allows the account risk control system to make the most of the storage resources of the first database.

[0110] (ii) Compression-based deletion strategy

[0111] In some embodiments, the utilization rate of the first database is obtained; if the utilization rate is greater than or equal to a threshold value, the information stored in the first database is compressed.

[0112] The utilization rate of the first database refers to the ratio between the resources already allocated to the resources currently in use in the first database.

[0113] In some embodiments, the first database is periodically used for usage rate detection according to the capacity period; if the usage rate is greater than or equal to a threshold value, the information stored in the first database is compressed.

[0114] Compression processing refers to performing some processing on the token information stored in the first database to reduce the storage space occupied by the token information.

[0115] In some embodiments, the utilization rate of the first database is obtained; if the utilization rate is greater than or equal to a threshold value, the complete token information is subsequently stored in the first database.

[0116] For example, when a periodic check finds that the usage rate of the first database exceeds 80%, the first database is compressed; when the usage rate of the first database is less than 80%, the token information subsequently stored in the first database does not need to be compressed.

[0117] By detecting the usage rate of the first database, we can determine whether there is a surge in access to the first database. If there is a surge in access to the first database, we can promptly compress the token information in the first database to ensure that the first database can store as much token information as possible, thereby improving the service efficiency of the account risk control system.

[0118] In some embodiments, information other than the access token is deleted from the token information of all or part of the access tokens in the first database.

[0119] The aforementioned "all access tokens" refers to access tokens that are still valid. The aforementioned "partial access tokens" can be recently accessed access tokens, newly added access tokens, or access tokens with high access frequency; this application does not impose any limitations on this.

[0120] If additional information about the access token is required, it can be found in the second database.

[0121] By storing only the access token in the first database using the above method, the storage space occupied by the access token information in the first database can be effectively reduced, which helps to improve the service efficiency of the account risk control system.

[0122] In some embodiments, the token information in the second database is periodically scanned according to an expiration clearing cycle; and the token information of expired access tokens in the second database is deleted. The expiration clearing cycle indicates the time interval for clearing the token information of expired access tokens from the second database.

[0123] In summary, the technical solution provided in this application stores access tokens generated for user accounts of a specified application simultaneously in a first database and a second database. Then, based on a pre-configured deletion policy, the token information of the first access token is deleted from the first database, while the token information of the first access token in the second database is retained. The access efficiency of the first database is higher than that of the second database. By using two databases to store the token information of access tokens and using a deletion policy to remove the token information of access tokens with low access frequency from the first database, the method achieves cold and hot token separation storage and reasonable and efficient use of system resources, thereby improving the service efficiency of the account risk control system.

[0124] The following describes the process of requesting business services using an access token.

[0125] Please refer to Figure 5 This document illustrates a flowchart of a service request using an access token, according to an embodiment of this application. The process may include at least one of the following steps (510-540):

[0126] Step 510: Receive a service request. The service request is used to request access to the user information of the first user account in the first application. The service request includes the first access token.

[0127] Business requests are used to request and call business interfaces related to the first user account, such as interfaces for obtaining user information, updating user information, modifying user password, and resetting user password.

[0128] For example, the business requests for the user information retrieval interface, user information update interface, user password modification interface, and user password reset interface are as follows:

[0129] (1) User information acquisition interface

[0130] GET / userinfo HTTP / 1.1

[0131] Authorization:Bearer ACCESS_TOKEN_WITH_OPENID_SCOPE

[0132] Host:sample.portal.tencentciam.com

[0133] (2) Update user information interface

[0134]

[0135] (3) Modify user password interface

[0136]

[0137]

[0138] (4) User password reset interface

[0139]

[0140] The content structure of the first access token in the business request includes basic information and custom information of the first access token, which are used during the transmission, parsing, and verification of the first access token. The content structure may include, but is not limited to: basic token information, token validity period, permission scope, custom information, and other standard fields; this application does not limit this. For example, the following is the header and payload of a JWT (JavaScript Object Notation Web Token, a JSON-based token) after decoding:

[0141]

[0142]

[0143] The header contains the following fields: "kid" for unique identifier of the key; "typ" for JWT type; "alg" for R5256 signature algorithm; "sub" for Subject (owner of the claim); "aud" for Audience; "nbf" for Effective Date; "scope" for Scope; "iss" for Issuer; "exp" for Exp; "iat" for Issuance Date; "jti" for Unique Identifier; and "client_id" for Unique Identifier of Client.

[0144] Step 520: Search for the token information of the first access token in the first database.

[0145] In some embodiments, the business request is parsed to obtain a first access token; the first access token is used as an index to search for the token information of the first access token in the first database.

[0146] Step 530: If the token information of the first access token is not found in the first database, then the token information of the first access token is searched in the second database.

[0147] In some embodiments, if the token information of the first access token is found in the second database, the token information of the first access token is stored in the first database.

[0148] By prioritizing the search for access token information in databases with high performance and high read / write efficiency, the access token access efficiency can be improved, thereby enhancing the service efficiency of the account risk control system.

[0149] Step 540: If the token information of the first access token is found, execute the business process corresponding to the business request based on the token information of the first access token.

[0150] A business process refers to a series of steps required to execute based on the type of business request. For example, retrieving the user information required for the business request from a second database. Another example is retrieving the user information corresponding to the business request from the second database and then modifying that information. Yet another example is retrieving the user information corresponding to the business request from the second database and then deleting it.

[0151] In some embodiments, the first access token is verified based on the token information of the first access token. The verification is used to verify the validity of the first access token. If the first access token is valid, the business process corresponding to the business request is executed. If the first access token is invalid, a token invalidation message is sent to indicate that the first access token has expired.

[0152] The validity of a first access token can be verified using at least one of the following methods: signature verification, validity period check, effective time check, and scope of permissions check. Other methods may also be used. Signature verification refers to using a key to verify the signature of the access token when it is protected by a signature, ensuring its integrity and authenticity. Validity period check verifies whether the time spent accessing the access token has exceeded its validity period. Effective time check determines whether the access token is valid at the time of access. Scope of permissions check determines whether the access token grants the user the permission to access the requested resource based on its scope of permissions.

[0153] In some embodiments, the token information of the first access token includes the validity period of the first access token; obtaining the current time; determining that the first access token is valid if the current time has not exceeded the validity period of the first access token; and determining that the first access token is invalid if the current time has exceeded the validity period of the first access token.

[0154] The current time refers to the time when the token information of the first access token was accessed.

[0155] By using the above methods to verify the validity of access tokens, the leakage of user information in the account risk control system can be prevented, ensuring the security and reliability of access token usage.

[0156] In some embodiments, the user information of the first user account in the first application is queried from the second database; and the user information of the first user account in the first application is processed according to the business request.

[0157] The processing of user information can include searching for user information, modifying user information, adding user information, deleting user information, etc., or other processing of user information. This application does not limit this.

[0158] For example, when the current business request calls the interface to obtain user information, after the first access token passes the validity verification, the user information required for the first access token is retrieved from the second database.

[0159] For example, when the current business request calls the interface to update user information, after the first access token passes the validity verification, the user information that needs to be updated for the first access token is retrieved from the second database, and the user information is modified based on the parameters in the business request.

[0160] By using the above method, and retrieving user information from the database according to different business requests for different processing, it is helpful to flexibly handle different business needs and scenarios.

[0161] The following is a description of a specific embodiment.

[0162] Please refer to Figure 6 It shows a timing diagram of the access token generation process provided in one embodiment of this application.

[0163] The first database uses Redis, and the second database uses MongoDB. Redis is an in-memory database, while MongoDB is a disk-based database.

[0164] The first database stores token information for only a portion of the access tokens, while the second database stores token information for all access tokens, all application configuration information, all user information, and system configuration information.

[0165] When a user needs to access protected resources in the first application, the first application running on the first client sends an authentication and authorization request to the account risk control system to request authentication and authorization for the user's first user account. This authentication and authorization request includes the ID of the first application, the first user account, and the account password. The authentication and authorization part retrieves the application information of the first application from the second database based on the ID in the authentication and authorization request to determine whether the first application exists and is enabled. If the first application exists and is enabled, the authentication and authorization part retrieves the user information of the first user account from the second database based on the first user account in the authentication and authorization request to verify whether the first user account is enabled and whether the account password is correct. If the first user account is enabled and the account password is correct, a first access token is generated based on the application configuration information of the first application. The token information of the first access token is stored in the second database. The system management part retrieves the system validity period configured in the system configuration, which is the first duration mentioned above. The first duration and the second duration are compared to determine the duration threshold of the first access token, and the token information of the first access token is stored in the first database. Finally, the account risk control system sends the token information of the first access token to the first client.

[0166] Please refer to Figure 7 It shows a timing diagram of a service request process provided in one embodiment of this application.

[0167] When a user sends a request to the account risk control system to obtain user information using a first access token, the authentication and authorization part of the account risk control system parses the first access token in the request and verifies its format. If the verification is successful, the system searches for the first access token's information in the first database. If the token is found in the first database, its validity period is checked to determine its validity. If the first access token is valid, the system queries the second database for the user information corresponding to the first access token and sends this user information to the first client. If the first access token's information is not found in the first database, the system searches the second database for it. If the token is found in the second database, its validity period is checked to determine its validity. If the first access token is valid, the system queries the second database for the user information corresponding to the first access token and sends this user information to the first client. Otherwise, a first access token verification failure message is sent to the first client.

[0168] The technical solution provided in this application significantly optimizes the management of access tokens in the account risk control system. Before adopting this solution, the first database contained approximately 1.2 million tokens with validity periods ranging from 1 minute to 365 days, occupying 11.48GB of space. This resulted in low performance in both token storage and management, with an average query time of approximately 80ms. After one week of stable operation using the technical solution provided in this application, the first database now has an average of approximately 7,500 resident tokens, representing a 95% reduction in resident token maintenance. The average memory usage of the first database is now approximately 120MB, saving approximately 95% of memory. The average query time is now approximately 5ms, improving query speed by approximately 92%.

[0169] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0170] Please refer to Figure 8 This diagram illustrates a block diagram of an access token storage device according to an embodiment of this application. The device has the functionality to implement the method example described above; this functionality can be implemented in hardware or by hardware executing corresponding software. The device can be the computer device described above, or it can be located within a computer device. Figure 8 As shown, the device 800 may include a request receiving module 810, a token generation module 820, an information storage module 830, and an information deletion module 840.

[0171] The request receiving module 810 is used to receive an authentication and authorization request, which is used to request authentication and authorization for the first user account to access the first application.

[0172] The token generation module 820 is used to generate a first access token for the first user account in the first application, and the first access token is used to access the user information of the first user account in the first application.

[0173] The information storage module 830 is used to store the token information of the first access token in a first database and a second database. The token information of the first access token includes the first access token and related information of the first access token. The information stored in the first database is a subset of the information stored in the second database, and the access efficiency of the first database is higher than the storage efficiency of the second database.

[0174] The information deletion module 840 is used to delete the token information of the first access token from the first database based on a pre-configured deletion policy.

[0175] In some embodiments, the information deletion module 840 is configured to determine a first unused duration corresponding to the first access token, wherein the first unused duration refers to the duration during which the token information of the first access token stored in the first database is not used; and if the first unused duration is greater than the duration threshold corresponding to the first access token, the token information of the first access token is deleted from the first database.

[0176] In some embodiments, the information deletion module 840 is further configured to determine a pre-configured fixed value as the duration threshold corresponding to the first access token; or, determine the duration threshold corresponding to the first access token based on the validity period of the first access token; or, determine the duration threshold corresponding to the first access token based on the access frequency of the first access token.

[0177] In some embodiments, the apparatus 800 further includes a service receiving module, a token lookup module, and a service execution module (in... Figure 8 (Not shown in the image).

[0178] A service receiving module is used to receive a service request, the service request being used to request access to the user information of the first user account in the first application, the service request including the first access token.

[0179] The token lookup module is used to search for the token information of the first access token in the first database; if the token information of the first access token is not found in the first database, then the token information of the first access token is searched in the second database.

[0180] The business execution module is used to execute the business process corresponding to the business request based on the token information of the first access token when the token information of the first access token is found.

[0181] In some embodiments, the token lookup module is further configured to store the token information of the first access token in the first database if the token information of the first access token is found in the second database.

[0182] In some embodiments, the business execution module includes a token verification submodule, a business execution submodule, and an invalidation return submodule (in... Figure 8 (Not shown in the image).

[0183] The token verification submodule is used to verify the first access token based on the token information of the first access token, and the verification is used to verify the validity of the first access token.

[0184] The business execution submodule is used to execute the business process corresponding to the business request when the first access token is valid.

[0185] The failure return submodule is used to send a token failure message when the first access token fails, the token failure message being used to indicate that the first access token has failed.

[0186] In some embodiments, the token information of the first access token includes the validity period of the first access token; the token verification submodule is further configured to obtain the current time; if the current time has not exceeded the validity period of the first access token, determine that the first access token is valid; if the current time has exceeded the validity period of the first access token, determine that the first access token is invalid.

[0187] In some embodiments, the business execution module is further configured to query user information of the first user account in the first application from the second database; and process the user information of the first user account in the first application according to the business request.

[0188] In some embodiments, the device 800 further includes an information compression module (in Figure 8 (Not shown in the image) is used to obtain the usage rate of the first database; if the usage rate is greater than or equal to a threshold value, the information stored in the first database is compressed.

[0189] In some embodiments, the information compression module is used to delete information other than the access token from the token information of all or part of the access tokens in the first database.

[0190] In some embodiments, the authentication and authorization request includes the identification information of the first application and the account password information of the first user account; the device 800 further includes a verification and authorization module (in Figure 8 (Not shown in the image) is used to verify the validity of the first application based on the identification information of the first application; if the first application is valid, to verify the validity of the account password information of the first user account; if the account password information of the first user account is valid, to execute the step of generating the first access token for the first user account for the first application.

[0191] In summary, the technical solution provided in this application stores access tokens generated for user accounts of a specified application simultaneously in a first database and a second database. Then, based on a pre-configured deletion policy, the token information of the first access token is deleted from the first database, while the token information of the first access token in the second database is retained. The access efficiency of the first database is higher than that of the second database. By using two databases to store the token information of access tokens and using a deletion policy to remove the token information of access tokens with low access frequency from the first database, the method achieves cold and hot token separation storage and reasonable and efficient use of system resources, thereby improving the service efficiency of the account risk control system.

[0192] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0193] Please refer to Figure 9 This diagram illustrates a structural block diagram of a computer device 900 provided in one embodiment of this application. The computer device 900 may be... Figure 1 Server 10 in the illustrated implementation environment is used to implement the access token storage method provided in the above embodiments. Specifically:

[0194] Computer device 900 includes a central processing unit (CPU) 901, a system memory 904 including random access memory (RAM) 902 and read-only memory (ROM) 903, and a system bus 905 connecting the system memory 904 and the CPU 901. Server 900 also includes a basic input / output (I / O) system 906 that facilitates the transfer of information between various devices within the computer, and a mass storage device 907 for storing the operating system 913, application programs 914, and other program modules 915.

[0195] The basic input / output system 906 includes a display 908 for displaying information and an input device 909 for user input, such as a mouse or keyboard. Both the display 908 and the input device 909 are connected to the central processing unit 901 via an input / output controller 910 connected to the system bus 905. The basic input / output system 906 may also include the input / output controller 910 for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 910 also provides output to a display screen, printer, or other types of output devices.

[0196] Mass storage device 907 is connected to central processing unit 901 via a mass storage controller (not shown) connected to system bus 905. Mass storage device 907 and its associated computer-readable media provide non-volatile storage for server 900. That is, mass storage device 907 may include computer-readable media (not shown) such as hard disk or CD-ROM (CompactDisc Read-Only Memory) drive.

[0197] Without loss of generality, computer-readable media can include computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes RAM, ROM, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), flash memory or other solid-state storage technologies, CD-ROM, DVD (Digital Video Disc) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that computer storage media are not limited to the above-mentioned types. The system memory 904 and mass storage device 907 described above can be collectively referred to as memory.

[0198] According to various embodiments of this application, server 900 can also connect to and operate on a remote computer on a network such as the Internet. That is, server 900 can connect to network 912 via network interface unit 911 connected to system bus 905, or it can use network interface unit 911 to connect to other types of networks or remote computer systems (in...). Figure 9 (Not shown in the image).

[0199] The memory also includes a computer program stored in the memory and configured to be executed by one or more processors to implement the above-described method for storing the access token.

[0200] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program, when executed by a processor, implements the above-described method for storing the access token. Optionally, the computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), solid-state drives (SSDs), or optical discs, etc. The random access memory may include resistive random access memory (ReRAM) and dynamic random access memory (DRAM).

[0201] In an exemplary embodiment, a computer program product is also provided, comprising a computer program stored in a computer-readable storage medium. A processor of a terminal device reads the computer program from the computer-readable storage medium and executes the computer program, causing the terminal device to perform the aforementioned access token storage method.

[0202] It should be noted that the collection and processing of relevant data (such as user information) in this application should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0203] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0204] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for storing access tokens, characterized in that, The method includes: Receive an authentication and authorization request, the authentication and authorization request being used to request authentication and authorization for the first user account to access the first application; Generate a first access token for the first user account in the first application. The first access token is used to access the user information of the first user account in the first application. In the first database and the second database, the token information of the first access token is stored. The token information of the first access token includes the first access token and related information of the first access token. The information stored in the first database is a subset of the information stored in the second database, and the access efficiency of the first database is higher than the storage efficiency of the second database. Based on a pre-configured deletion policy, the token information of the first access token is deleted from the first database.

2. The method according to claim 1, characterized in that, The deletion of the token information of the first access token from the first database based on the pre-configured deletion policy includes: Determine the first unused duration corresponding to the first access token, where the first unused duration refers to the duration during which the token information of the first access token stored in the first database is not used; If the first unused duration exceeds the duration threshold corresponding to the first access token, the token information of the first access token will be deleted from the first database.

3. The method according to claim 2, characterized in that, The method further includes: The pre-configured fixed value is determined as the duration threshold corresponding to the first access token; or, Based on the validity period of the first access token, determine the duration threshold corresponding to the first access token; or, The duration threshold corresponding to the first access token is determined based on the access frequency of the first access token.

4. The method according to claim 1, characterized in that, The method further includes: Receive a service request, the service request being used to request access to the user information of the first user account in the first application, the service request including the first access token; Search the first database for the token information of the first access token; If the token information of the first access token is not found in the first database, then the token information of the first access token is searched in the second database. If the token information of the first access token is found, the business process corresponding to the business request is executed based on the token information of the first access token.

5. The method according to claim 4, characterized in that, The method further includes: If the token information of the first access token is found in the second database, then the token information of the first access token is stored in the first database.

6. The method according to claim 4, characterized in that, The process of executing the business request based on the token information of the first access token includes: Based on the token information of the first access token, the first access token is verified, and the verification is used to verify the validity of the first access token. If the first access token is valid, the business process corresponding to the business request will be executed; If the first access token expires, a token expiration message is sent, which indicates that the first access token has expired.

7. The method according to claim 6, characterized in that, The token information of the first access token includes the validity period of the first access token; The step of verifying the first access token based on the token information of the first access token includes: Get the current time; If the current time has not exceeded the validity period of the first access token, the first access token is determined to be valid; If the current time exceeds the expiration date of the first access token, the first access token is determined to be invalid.

8. The method according to claim 4, characterized in that, The business process corresponding to executing the business request includes: Query the user information of the first user account in the first application from the second database; Based on the business request, the user information of the first user account in the first application is processed.

9. The method according to claim 1, characterized in that, The method further includes: Obtain the usage rate of the first database; If the usage rate is greater than or equal to a threshold value, the information stored in the first database is compressed.

10. The method according to claim 9, characterized in that, The compression process for the information stored in the first database includes: Delete all information other than the access token from the token information of all or part of the access tokens in the first database.

11. The method according to claim 1, characterized in that, The authentication and authorization request includes the identification information of the first application and the account password information of the first user account; After receiving the authentication and authorization request, the process also includes: The validity of the first application is verified based on its identification information. If the first application is valid, the validity of the account password information of the first user account is verified; If the password information of the first user account is valid, the step of generating the first access token for the first user account for the first application is executed.

12. A storage device for an access token, characterized in that, The device includes: The request receiving module is used to receive authentication and authorization requests, which are used to request authentication and authorization for the first user account to access the first application. The token generation module is used to generate a first access token for the first user account in the first application. The first access token is used to access the user information of the first user account in the first application. An information storage module is used to store token information of the first access token in a first database and a second database. The token information of the first access token includes the first access token and related information of the first access token. The information stored in the first database is a subset of the information stored in the second database, and the access efficiency of the first database is higher than the storage efficiency of the second database. The information deletion module is used to delete the token information of the first access token from the first database based on a pre-configured deletion policy.

13. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the method as claimed in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, The computer program product includes a computer program that is loaded and executed by a processor to implement the method as described in any one of claims 1 to 11.

Images