CN113852631A - Method and device for determining access token - Google Patents
Method and device for determining access token Download PDFInfo
- Publication number
- CN113852631A CN113852631A CN202111124112.4A CN202111124112A CN113852631A CN 113852631 A CN113852631 A CN 113852631A CN 202111124112 A CN202111124112 A CN 202111124112A CN 113852631 A CN113852631 A CN 113852631A
- Authority
- CN
- China
- Prior art keywords
- access token
- server
- preset
- request
- token
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 65
- 238000012795 verification Methods 0.000 claims description 32
- 238000012545 processing Methods 0.000 claims description 8
- 230000001186 cumulative effect Effects 0.000 claims description 5
- SPBWHPXCWJLQRU-FITJORAGSA-N 4-amino-8-[(2r,3r,4s,5r)-3,4-dihydroxy-5-(hydroxymethyl)oxolan-2-yl]-5-oxopyrido[2,3-d]pyrimidine-6-carboxamide Chemical compound C12=NC=NC(N)=C2C(=O)C(C(=O)N)=CN1[C@@H]1O[C@H](CO)[C@@H](O)[C@H]1O SPBWHPXCWJLQRU-FITJORAGSA-N 0.000 description 24
- 238000010586 diagram Methods 0.000 description 13
- 238000004590 computer program Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000001364 causal effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Networks & Wireless Communication (AREA)
- Theoretical Computer Science (AREA)
- Medical Informatics (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Databases & Information Systems (AREA)
- Computing Systems (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The invention discloses a method and a device for determining an access token, wherein the method comprises the following steps: receiving a request carrying a user certificate and a certificate key and used for obtaining an access token, which is sent by a first API client; determining whether an access token corresponding to the user credential is obtained from a preset cache server; when the access token corresponding to the user certificate is not acquired from the preset cache server, sending a request for acquiring the distributed lock to the preset cache server; and when a target distributed lock fed back by the preset cache server is received, sending an access token obtaining request to the interface open platform server based on the user certificate and the certificate key, receiving a new access token fed back by the interface open platform server, and sending the new access token to the first API interface client. The method can acquire the effective and accurate access token, and improves the acquisition efficiency of the access token.
Description
Technical Field
The embodiment of the invention relates to the field of financial technology (Fintech), in particular to a method and a device for determining an access token.
Background
With the development of computer technology, more and more technologies are applied in the financial field, and the traditional financial industry is gradually changing to financial technology, but due to the requirements of the financial industry on safety and real-time performance, higher requirements are also put forward on the technologies.
Currently, in the design of APP (Application program interface), most interfaces relate to personal information of a user and sensitive data of a product, and therefore authentication needs to be performed on the interfaces to protect the personal information of the user.
When the identity of the interface is verified, generally, an API requests a client to send a request carrying user authentication information for obtaining an access token to a server, the server determines whether the user authentication information is correct or not after receiving the request, determines the access token access _ token when the user authentication information is correct, and feeds back the access token access _ token to the API requests the client.
Specifically, each user authentication information corresponds to one valid access _ token only in one time period, and therefore, when the corresponding valid access _ token expires, the interface of the application server cannot be called. And since the application server has a limited number of times to acquire the access _ token, the access _ token needs to be cached in the cache server, and the access _ token is acquired from the interface open platform at regular time to update the access _ token in the cache server.
However, when the access _ token in the cache server expires, when multiple application servers receive API requests at the same time, that is, multiple application servers need to update the access _ token at the same time, since it takes a certain time to obtain the access _ token from the interface open platform, and the latest access _ token and the previous access _ token have a one-minute coexistence period, that is, all the rest of the access _ tokens expire.
This results in only two requests being successful for all API requests in this time before getting a new access token back, and the rest failing because the access token expires. Therefore, the problem that the effect of obtaining the effective access token is poor exists in the prior art.
Disclosure of Invention
The invention provides a method and a device for determining an access token, which are used for solving the problem of poor effect of obtaining an effective access token in the prior art.
In a first aspect, the present invention provides a method for determining an access token, applied to an application server, including: receiving a request for obtaining an access token sent by a first API client, wherein the request for obtaining the access token carries a user certificate and a certificate key; determining whether an access token corresponding to the user certificate is acquired from a preset cache server; when the access token corresponding to the user certificate is not acquired from the preset cache server, sending a request for acquiring a distributed lock to the preset cache server; the distributed lock is used for controlling the application servers, so that only one application server updates the access token at the same time; and when a target distributed lock fed back by the preset cache server is received, sending an access token obtaining request to an interface open platform server based on the user certificate and the certificate key, receiving a new access token fed back by the interface open platform server, and sending the new access token to the first API interface client.
In the method, when the access token corresponding to the user credential does not exist in the preset cache server, a request for acquiring the distributed lock needs to be sent to the preset cache server, so that when the target distributed lock fed back by the preset cache server is received, the target distributed lock is used for ensuring that only the application server updates the access token, so that the uniqueness and the validity of the newly acquired access token are ensured, and the situation of acquiring the overdue access token is avoided.
Optionally, after determining whether to acquire the access token corresponding to the user credential from a preset cache server, the method further includes: when the access token corresponding to the user certificate is obtained from the preset cache server, carrying out valid duration verification on the corresponding access token; and when the corresponding access token valid duration is determined to pass the verification, sending the corresponding access token to the first API interface client.
In the method, when the access token corresponding to the user certificate is determined to be acquired from the preset cache server, the access token is not directly fed back to the first API interface client, but valid duration verification is performed on the access token, so that the access token finally fed back to the first API interface client is guaranteed to be valid as much as possible.
Optionally, performing validity duration verification on the corresponding access token includes: determining the remaining effective duration of the corresponding access token; determining whether the residual effective time length is greater than a preset time length or not, wherein the preset time length is correspondingly determined based on the data refreshing time length and the guarantee time length of the preset cache server; and when the residual effective duration is determined to be greater than the preset duration, determining that the effective duration of the corresponding access token passes verification.
According to the method, a specific mode for verifying the valid duration of the access token corresponding to the user certificate is provided, and based on the mode, the valid duration of the access token can be verified simply and efficiently.
Optionally, after determining whether the remaining effective duration is greater than a preset duration, the method further includes: and when the residual effective duration is determined to be not greater than the preset duration, sending a request for acquiring the distributed lock to the preset cache server.
Based on the method, a new access token is acquired when the access token is determined to exist but is about to fail or is failed, so that the application server can acquire the access token with validity.
Optionally, after sending the request for obtaining the distributed lock to the preset cache server, the method further includes: determining whether a first time interval from the moment of sending the request for obtaining the distributed lock to the current moment reaches a preset time interval; and when the first time interval is determined to reach the preset time interval and the target distributed lock is not received, sending a request for acquiring the distributed lock to the preset cache server.
Based on the method, the request for acquiring the distributed lock can be regularly sent to the preset cache server, so that the preset cache server can receive the request for acquiring the distributed lock as far as possible and respond to the request for acquiring the distributed lock.
Optionally, after determining that the first time interval reaches the preset time interval, before sending a request for acquiring a distributed lock to the preset cache server, the method further includes: sending, to the first API interface client, whether the cumulative number of times of requests for acquiring the distributed lock reaches a preset number threshold to the preset cache server; and when the accumulated times are determined not to reach the preset times threshold value, sending a request for acquiring the distributed lock to the preset cache server.
Based on the method, the acquisition times of the distributed lock can be limited, and the service life of the application server is prolonged as much as possible on the basis of realizing the requirement of acquiring the distributed lock.
Optionally, the access token in the preset cache server is updated correspondingly based on the access token determined by the timing task in the timer corresponding to the preset cache server.
Based on the method, the access token in the preset cache server can be automatically updated based on the timing task, namely, the access token in the preset cache server is ensured to be in the valid period as much as possible.
In a second aspect, the present invention provides an apparatus for determining an access token, which is applied to an application server and includes: the system comprises a receiving unit, a first API interface client and a second API interface client, wherein the receiving unit is used for receiving a request for obtaining an access token sent by the first API interface client, and the request for obtaining the access token carries a user certificate and a certificate key; the acquisition unit is used for determining whether an access token corresponding to the user certificate is acquired from a preset cache server; the sending unit is used for sending a request for obtaining the distributed lock to the preset cache server when the access token corresponding to the user certificate is not obtained from the preset cache server; the distributed lock is used for controlling the application servers, so that only one application server updates the access token at the same time; and the processing unit is used for sending an access token obtaining request to an interface open platform server based on the user certificate and the certificate key when receiving the target distributed lock fed back by the preset cache server, receiving a new access token fed back by the interface open platform server, and sending the new access token to the first API interface client.
Optionally, the apparatus further includes a verification unit, configured to: when the access token corresponding to the user certificate is obtained from the preset cache server, carrying out valid duration verification on the corresponding access token; and when the corresponding access token valid duration is determined to pass the verification, sending the corresponding access token to the first API interface client.
Optionally, the verification unit is specifically configured to: determining the remaining effective duration of the corresponding access token; determining whether the residual effective time length is greater than a preset time length or not, wherein the preset time length is correspondingly determined based on the data refreshing time length and the guarantee time length of the preset cache server; and when the residual effective duration is determined to be greater than the preset duration, determining that the effective duration of the corresponding access token passes verification.
Optionally, the verification unit is further configured to: and when the residual effective duration is determined to be not greater than the preset duration, sending a request for acquiring the distributed lock to the preset cache server.
Optionally, after sending the request for acquiring the distributed lock to the preset cache server, the apparatus further includes a determining unit, configured to: determining whether a first time interval from the moment of sending the request for obtaining the distributed lock to the current moment reaches a preset time interval; and when the first time interval is determined to reach the preset time interval and the target distributed lock is not received, sending a request for acquiring the distributed lock to the preset cache server.
Optionally, after determining that the first time interval reaches the preset time interval, before sending a request for acquiring a distributed lock to the preset cache server, the determining unit is further configured to: sending, to the first API interface client, whether the cumulative number of times of requests for acquiring the distributed lock reaches a preset number threshold to the preset cache server; and when the accumulated times are determined not to reach the preset times threshold value, sending a request for acquiring the distributed lock to the preset cache server.
Optionally, the access token in the preset cache server is updated correspondingly based on the access token determined by the timing task in the timer corresponding to the preset cache server.
The advantageous effects of the second aspect and the various optional apparatuses of the second aspect may refer to the advantageous effects of the first aspect and the various optional methods of the first aspect, and are not described herein again.
In a third aspect, the present invention provides a computer device comprising a program or instructions for performing the method of the first aspect and the alternatives of the first aspect when the program or instructions are executed.
In a fourth aspect, the present invention provides a storage medium comprising a program or instructions which, when executed, is adapted to perform the method of the first aspect and the alternatives of the first aspect.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings that are required to be used in the description of the embodiments will be briefly described below.
Fig. 1 is a schematic diagram of a method for determining an access token according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating steps of a method for determining an access token according to an embodiment of the present invention;
FIG. 3 is a flowchart illustrating another step of a method for determining an access token according to an embodiment of the present invention;
fig. 4 is a signaling interaction diagram of an application server, a preset cache server, and an interface open platform server according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of an apparatus for determining an access token according to an embodiment of the present invention.
Detailed Description
In order to better understand the technical solutions, the technical solutions will be described in detail below with reference to the drawings and the specific embodiments of the specification, and it should be understood that the embodiments and specific features of the embodiments of the present invention are detailed descriptions of the technical solutions of the present invention, and are not limitations of the technical solutions of the present invention, and the technical features of the embodiments and examples of the present invention may be combined with each other without conflict.
It is noted that the terms first, second and the like in the description and in the claims of the present invention are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the images so used are interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the invention, as detailed in the appended claims.
In order to facilitate understanding of the technical solutions provided by the embodiments of the present invention, some key terms used in the embodiments of the present invention are explained first:
access _ token: namely, the access token is a globally unique interface calling credential of the server corresponding to the application access interface open platform.
appid: the user certificate is a third-party user unique certificate distributed to each third-party user by a server corresponding to the interface open platform;
appsecret: the certificate key can also be called a private key, and is a third-party user unique certificate key distributed to each third-party user by a server corresponding to the interface open platform;
redis (Remote Dictionary Server): an open source, network-supporting, memory-based and persistent log-type, Key-Value database, and provides API in multiple languages, i.e. a high-performance kay-Value cache server;
an interface open platform: the software system makes an external program to increase the functions of the software system or use the resources of the software system by disclosing its API (Application programming interface) or functions, without changing the source code of the software system, that is, the platform providing the open API is itself called an interface open platform.
The following briefly introduces the design concept of the embodiment of the present invention:
currently, in the design of an APP (Application program) open API, most interfaces relate to personal information of a user and sensitive data of a product, and therefore authentication needs to be performed on the interfaces to protect the personal information of the user.
Specifically, when the interface is subjected to identity verification, generally, the API requests the client to send a request carrying user authentication information for obtaining the access token to the server, after receiving the request, the server determines whether the user authentication information is correct, and when determining that the user authentication information is correct, determines the access token access _ token, and feeds back the access token _ token to the API request client.
However, in view of the characteristic of the access _ token that only one access _ token is allowed to be valid for a period of time for each user authentication information, when the access _ token having passed the validity period is used to call the interface of the application server, an error will be reported to the client sending the API request, and the acquisition of the access _ token by the application server is limited in the number of times, for example, each application server acquires the access _ token up to 8000 times per day, so the access _ token needs to be cached in the cache server and refreshed periodically.
However, since the access _ token is only stored in the corresponding cache server, when the access _ token in the system cache expires, in the case that a plurality of servers update the access _ token at the same time, the failed access _ token may be updated to the cache server, so that a part of the servers may obtain the expired access _ token.
For example, the application server receives the first API request, acquires the access _ token from the cache server, and when the access _ token is found to have passed the validity period, needs to request a new access _ token from the server corresponding to the interface open platform. Further, after the access _ token is acquired, the access _ token in the cache server is updated.
However, when the access _ token corresponding to the first API request is not obtained from the server corresponding to the interface opening platform, the second API request is received, that is, the access _ token is still obtained from the cache server, and since the new access _ token obtained from the first API request is not returned yet, the access _ token obtained from the cache server is still an expired old access _ token, and therefore, the new access _ token is also applied to the interface opening platform, and the access _ token in the cache server is updated after the access _ token is obtained.
Specifically, a certain time is required for obtaining the access _ token from the interface opening platform, and before a new access _ token is not returned yet, all the access _ tokens obtained by all the API requests in this time from the cache server are all expired old access _ tokens, and at this time, the application to the interface opening platform is triggered, and tasks of the access _ tokens corresponding to all the API requests are obtained. Therefore, the interface open platform receives a plurality of requests for applying the access _ token, and then the interface open platform returns the latest access _ token and updates the access _ token in the cache server.
In the actual implementation process, the interface open platform is only valid for the latest access _ token, the latest access _ token and the previous access _ token have a coexistence period of one minute, and the rest of the access _ tokens are all expired, so that before the new access _ token is obtained and returned, only two requests are successful for all API requests in the period of time, and the rest of the API requests fail because the access _ token is expired and expired.
In view of this, the embodiment of the present invention provides a method for determining an access token, which guarantees that only one application server updates an access _ token and other servers obtain the access _ token from a cache server through a distributed lock, thereby guaranteeing uniqueness of the access _ token and ensuring normal call authentication for each API request.
After the design concept of the embodiment of the present invention is introduced, some simple descriptions are made below on application scenarios to which the technical scheme for determining the access token in the embodiment of the present invention is applicable, and it should be noted that the application scenarios described in the embodiment of the present invention are for more clearly describing the technical scheme in the embodiment of the present invention, and do not form limitations on the technical scheme provided in the embodiment of the present invention.
In the embodiment of the present invention, please refer to an application scenario schematic diagram shown in fig. 1, where the scenario includes an electronic device 101, an application server 102, a preset cache server 103, and a server 104 corresponding to an interface open platform, the electronic device 101 may communicate with the application server 102, and the application server 102, the server 103, and the server 104 may also communicate with each other. Such as directly or indirectly through wired or wireless communication, as the invention is not limited. The application server 102 comprises an application server 102-1, application servers 102-2, … … and an application server 102-n, wherein n is a positive integer greater than 2. For convenience of description, hereinafter, the "server corresponding to the interface open platform" is referred to as an "interface open platform server".
In the scene, one application system is correspondingly deployed in n application servers 102, in order to ensure that 1 access _ token corresponds to only one api in an interface open platform, that is, the access _ token is consistent, the corresponding access _ token obtained from the interface open platform is placed in the cache server 103 through the api and the appsecret, and when an api interface is called, the access _ token is obtained from the preset cache server 103 and interacts with the interface open platform.
In this scenario, the electronic device 101 sending the request for obtaining the access token interacts with one application server 102 (e.g., the application server 102-1) each time, and when the application server 102-1 cannot find the access _ token corresponding to the user credential, i.e., the api, in the request for obtaining the access token from the corresponding cache server 103, the application server 102-1 sends the request for obtaining the access _ token to the server 104 corresponding to the interface open platform, so as to determine a new access _ token corresponding to the user credential, and update and cache the new access _ token in the preset cache server 103. It should be noted that the cache server specifically interacting with the electronic device 101 may be determined by the application system based on the load condition of each application server, and the like, which is not limited in the present invention.
Specifically, the preset cache server may be a redis server, and certainly, may also be another server that can cache data, which is not limited in the present invention.
The application server 102, the preset cache server 103, and the server 104 may be independent physical servers, may also be a server cluster or a distributed system formed by a plurality of physical servers, and may also be cloud servers providing basic cloud computing services such as cloud service, a cloud database, cloud computing, a cloud function, cloud storage, Network service, cloud communication, middleware service, domain name service, security service, CDN (Content Delivery Network), and a big data and artificial intelligence platform. The electronic device 101 may be a smartphone, a tablet computer, a laptop computer, a desktop computer, a smart television, a smart wearable device, etc., or may be a server, but is not limited thereto.
To further illustrate the solution of the method for determining an access token according to the embodiments of the present invention, the following detailed description is made with reference to the accompanying drawings. Although embodiments of the present invention provide method steps as shown in the following embodiments or figures, more or fewer steps may be included in the method based on conventional or non-inventive efforts. In steps where no necessary causal relationship exists logically, the order of execution of the steps is not limited to that provided by embodiments of the present invention. The method can be executed in sequence or in parallel according to the method shown in the embodiment or the figures when the method is executed in an actual processing procedure or a device (for example, a parallel processor or an application environment of multi-thread processing).
The method for determining an access token in the embodiment of the present invention is described below with reference to the method flowchart shown in fig. 2, and the method flow in the embodiment of the present invention is described below.
Step 201: and receiving a request for obtaining the access token sent by the first API client, wherein the request for obtaining the access token carries a user certificate and a certificate key.
Step 202: and determining whether an access token corresponding to the user credential is obtained from a preset cache server.
In this embodiment of the application, the application server may receive a request for obtaining the access token sent by the first API interface client, where the request for obtaining the access token carries a user credential and a credential key, and then the application server determines whether to obtain the access token corresponding to the user credential from a preset cache server. Specifically, when the access token corresponding to the user credential is not obtained from the preset cache server, step 203 is executed.
And when the access token corresponding to the user certificate can be obtained from the preset cache server, performing valid duration verification on the access token corresponding to the user certificate, and when the valid duration verification of the access token corresponding to the user certificate is passed, sending the access token corresponding to the user certificate to the first API client.
In the embodiment of the present invention, the valid duration verification may be performed on the access token corresponding to the user credential by using, but not limited to, the following steps:
step a: and determining the remaining effective duration of the access token corresponding to the user certificate.
In the embodiment of the invention, the application server can analyze the information of the access token corresponding to the user certificate and determine the remaining effective duration of the access token corresponding to the user certificate. Specifically, the application server may correspondingly determine the remaining valid duration of the access token corresponding to the user credential based on the expiration time and the valid duration corresponding to the access token.
Step b: and determining whether the residual effective time length is greater than a preset time length, wherein the preset time length is correspondingly determined based on the data refreshing time length and the guarantee time length of a preset cache server.
In the embodiment of the present invention, if the preset data refresh time of the cache server is 30 minutes and the guaranteed time is 10 minutes, the preset time may be 40 minutes. Specifically, the data refresh time may be a time period within 0 to 120 minutes, and may be determined correspondingly based on actual implementation, which is not limited in the present application.
In this embodiment, after determining the remaining effective duration and the preset duration, the remaining effective duration and the preset duration may be compared, and specifically, when determining that the remaining effective duration is greater than the preset duration, the step c is executed; and d, executing the step d when the residual effective duration is determined to be not greater than the preset duration.
Step c: and when the residual effective duration is determined to be greater than the preset duration, determining that the effective duration of the access token corresponding to the user certificate passes verification.
Step d: and when the residual effective duration is determined to be not greater than the preset duration, sending a request for acquiring the distributed lock to a preset cache server.
Therefore, the situation that the access _ token is expired within the period of time due to the fact that the remaining effective time of the access _ token is less, for example, 0 minute, is effectively prevented, namely the finally acquired access _ token is ensured to be effective.
Step 203: when the access token corresponding to the user certificate is not acquired from the preset cache server, sending a request for acquiring the distributed lock to the preset cache server; the distributed lock is used to control the application servers such that only one application server performs an update of the access token at a time.
In the embodiment of the invention, when the access token corresponding to the user certificate is not acquired from the preset cache server, a request for acquiring the distributed lock is sent to the preset cache server, and when the target distributed lock is not received, whether a first time interval from the moment of sending the request for acquiring the distributed lock to the current moment reaches a preset time interval or not can be determined; and when the first time interval is determined to reach the preset time interval and the target distributed lock is not received, sending a request for acquiring the distributed lock to a preset cache server.
Therefore, in the embodiment of the present invention, when the application server does not rob the target distributed lock for the first time, the request for acquiring the distributed lock may be continuously sent to the preset cache server after the preset time interval.
In the embodiment of the present invention, after the application server determines that the first time interval reaches the preset time interval, before sending the request for acquiring the distributed lock to the preset cache server, whether the cumulative number of times of sending the request for acquiring the distributed lock to the preset cache server reaches the preset number threshold may also be executed for the first API interface client; and when the accumulated times are determined not to reach the preset times threshold value, sending a request for acquiring the distributed lock to a preset cache server.
Obviously, after the application server does not acquire the target distributed lock for the first time, the application server may acquire the target distributed lock again at an interval of a preset time, and the retry number is less than a preset threshold number, for example, the application server may acquire the target distributed lock again every 100 milliseconds and retry 10 times at most until the target distributed lock is acquired.
Step 204: and when a target distributed lock fed back by the preset cache server is received, sending an access token obtaining request to the interface open platform server based on the user certificate and the certificate key, receiving a new access token fed back by the interface open platform server, and sending the new access token to the first API interface client.
In the embodiment of the invention, when the application server receives the target distributed lock fed back by the preset cache server, the request for obtaining the access token is sent to the interface open platform server based on the user certificate and the certificate key, then the interface open platform server determines whether the user certificate and the certificate key conform to the corresponding preset format, when the user certificate and the certificate key conform to the corresponding preset format, the user certificate and the certificate key can be determined to pass the verification, and after the user certificate and the certificate key are determined to pass the verification, a new token can be fed back to the application server, so that the application server can receive the new access token fed back by the interface open platform server and send the new access token to the first API interface client.
Further, the application server may also update the access token in the cache server based on the new access token, and release the target distributed lock, so that other application servers may acquire the target distributed lock to perform acquisition of the new access token.
Optionally, in the embodiment of the present invention, the access token in the preset cache server is updated correspondingly based on the access token determined by the timing task in the timer corresponding to the preset cache server.
For example, a specific process of starting a timing task and regularly updating the target access _ token in the preset cache server every 30 minutes is as follows:
a) the method comprises the following steps Starting a timing task of a timer in a redis server, reading a target access _ token from a cache of the redis server every 30 minutes, judging whether the target access _ token exists, and if the target access _ token does not exist, acquiring the target access _ token from an interface open platform server by an application server;
b) the method comprises the following steps If the target access _ token exists, judging whether the remaining effective time length of the access _ token is more than 40 minutes, specifically, the 40 minutes is determined based on the guaranteed time length of 10 minutes and the timing refreshing time length of 30 minutes; if the remaining effective duration is less than 40 minutes, the application server needs to acquire a new access _ token from the open platform;
c) the method comprises the following steps Acquiring a distributed lock from a redis server, if acquiring a target distributed lock fails, acquiring the target distributed lock again at intervals of 100 milliseconds, retrying for 10 times at most until the distributed lock is acquired, and if acquiring the redis distributed lock for 10 continuous times fails, exiting the timing task;
d) the method comprises the following steps When the target distributed lock is successfully obtained, reading a target access _ token from a cache of the redis server, judging whether the access _ token exists, if the residual effective time of the access _ token obtained from the cache is more than 40 minutes, indicating that the target access _ token is updated by a timer or api call of another application server, and exiting the timing task;
e) the method comprises the following steps If the target access _ token in the cache of the redis server does not exist or the remaining effective time is less than 40 minutes, applying for the latest access _ token to the interface open platform server, and obtaining success of the access _ token from the open platform, updating the latest access _ token into the redis cache, wherein the latest access _ token comprises the value, expiration time and effective duration of the access _ token;
f) the method comprises the following steps The redis distributed lock is released.
It can be seen that the access token cached in the redis server can be updated based on the timer in the redis server, so that the access token cached in the redis server is ensured to be in the validity period as much as possible, and because the access token obtained during updating is correspondingly determined from the interface open platform server, that is, the access tokens stored in the redis server are all generated by the interface open platform server, and the access tokens are all stored in association with the user credential, the subsequent application server can obtain the corresponding access token from the redis server based on the user credential.
Referring to fig. 3, fig. 3 is a schematic diagram of determining an access token according to an embodiment of the present disclosure.
Step 301: receiving a request for acquiring an access token sent by a first API client;
step 302: and judging whether an access token corresponding to the user certificate carried in the request for obtaining the access token exists in the preset cache server. When it is determined that the preset cache server has an access token corresponding to the user credential carried in the request for obtaining the access token, executing step 305; when it is determined that the preset cache server does not have an access token corresponding to the user credential carried in the request for obtaining the access token, step 303 is executed.
Step 303: and sending a request for acquiring a new access token to the interface open platform server so that the interface open platform server generates the new access token based on the user certificate and the certificate key through an encryption algorithm.
Step 304: and receiving a new access token sent by the interface open platform server.
Step 305: validating an access token corresponding to the user credential; when it is determined that the access token is not authenticated, go to step 306; when it is determined that the access token is valid, step 308 is performed.
Step 306: and when the access token is determined to pass the verification, sending a request for acquiring a new access token to the interface open platform server so that the interface open platform server generates the new access token based on the user certificate and the certificate key through an encryption algorithm.
Step 307: and receiving a new access token sent by the interface open platform server.
Step 308: the access token is sent to the first API interface client.
It can be seen that when the client sends the API request, the access _ token needs to be acquired from the interface opening platform for authentication, and only if the authentication is passed, the normal access interface is allowed to open the interface corresponding to the platform. The access _ token is a unique access identifier obtained from the interface open platform through the api and the secret, and can be used for authentication only in the validity period of the access _ token, otherwise, the access is denied.
Referring to fig. 4, a signaling interaction diagram of an application server, a preset cache server and an interface open platform server according to an embodiment of the present invention is shown.
Step 401: and the application server sends a request for acquiring the target access _ token corresponding to the apid to the redis server.
In the embodiment of the present invention, the application server may receive a request for obtaining the access token sent by the client, where the request for obtaining the access token carries the api and the app secret, and therefore the application server may send a request for obtaining the target access _ token corresponding to the api to the redis server.
Step 402: the redis server judges whether the target access _ token exists or not, and if yes, feeds the target access _ token back to the application server; if not, the information of acquisition failure is fed back to the application server, and the application server executes step 403.
In the embodiment of the present invention, when the application server obtains the target access _ token from the redis server, it is further required to determine whether the target access _ token has passed the validity period, and if the validity period has passed, it is still required to obtain the latest access _ token from the interface open platform server. When the target access _ token is in the valid period, the client can use the access _ token to realize the api call.
In the embodiment of the invention, when the timer task does not obtain the latest access _ token corresponding to the api from the interface open platform server, a new api request needs to be executed, and at this time, no access _ token exists, so that the target access _ token does not exist in the redis server.
Step 403: the application server sends a request to a redis server to acquire a redis distributed lock.
Step 404: the redis server returns the target distributed lock to the application server.
Step 405: the application server sends a request for obtaining a new access _ token corresponding to the app to the interface open platform server based on the app and the app secret carried in the request for obtaining the access token sent by the client.
Step 406: and the interface open platform server returns a new access _ token corresponding to the apid to the application server.
Step 407: and the application server sends a new access _ token corresponding to the apid to the redis server and releases the target distributed lock.
Therefore, through the redis distributed lock, only one server of the access _ token is updated, and other servers acquire the access _ token from the redis cache, so that the uniqueness of the access _ token is ensured, and the api calling authentication is ensured to be normal.
To better illustrate the solutions provided by the embodiments of the present invention, a specific example is described below.
It is assumed that the first client, the second client and the third client respectively send the same requests of appid1 and app secret1 for obtaining access tokens, and according to the sequence from first to last in time, the first client sends a first request of obtaining the access token, the second client sends a second request of obtaining the access token, and the third client sends a third request of obtaining the access token, and the application server 1, the application server 2 and the application server 3 respectively receive the first api request of obtaining the access token, the second api request of obtaining the access token and the third api request of obtaining the access token.
Specifically, the application server 1 may determine whether to acquire an access token corresponding to the api 1 from the redis server; when the access token corresponding to the appid1 is not acquired from the redis server, sending a request for acquiring a distributed lock to the redis server; when a target distributed lock fed back by a redis server is received, an access token obtaining request is sent to an interface open platform server based on the api 1 and the api cret1, then the interface open platform server determines whether the api 1 and the api cret1 conform to the corresponding preset formats, when it is determined that the api 1 and the api cret1 conform to the corresponding preset formats, it may be determined that the authentication of the api 1 and the api cret1 is passed, and after it is determined that the authentication of the api 1 and the api cret1 is passed, a new access token may be fed back to the application server 2, so that the application server 1 may receive the new access token fed back by the interface open platform server.
Further, the application server 1 may send a new access token to the first client, and then send the new access token to the redis server, so that the redis server updates the access token corresponding to the appid1, that is, after this time, the latest access token corresponding to the appid1 is cached in the redis server. It can be seen that the first client has obtained a valid access token.
Specifically, when the application server 2 may verify the apdid 1 and the appserct 1, and when it is determined that the appid1 and the appserct 1 are verified to be passed, it is determined whether to acquire the access token corresponding to the appid1 from the redis server, and when the access token corresponding to the update of the application server 1 is stored in the redis server, the access token corresponding to the appid1 may be acquired, and then the valid duration verification is performed on the access token, which may specifically refer to the foregoing steps a-d, and is not described here again. When the application server 2 determines that the validity duration of the access token passes the verification, the access token may be sent to the second client, and then sent to the redis server, so that the redis server updates the access token corresponding to the api 1, that is, at this moment, the access token is cached in the redis server. It can be seen that the second client has obtained a valid access token.
In addition, when the application server 2 does not acquire the access token corresponding to the api 1 from the redis server, sending a request for acquiring a distributed lock to the redis server; when a target distributed lock fed back by a redis server is received, an access token obtaining request is sent to an interface open platform server based on the api 1 and the api cret1, then the interface open platform server determines whether the api 1 and the api cret1 conform to the corresponding preset formats, when it is determined that the api 1 and the api cret1 conform to the corresponding preset formats, it may be determined that the authentication of the api 1 and the api cret1 is passed, and when it is determined that the authentication of the api 1 and the api cret1 is passed, a new access token may be fed back to the application server 2.
Further, the application server 2 may receive a new access token fed back by the interface open platform server, send the new access token to the second client, and then send the new access token to the redis server, so that the redis server updates the access token corresponding to the api 1, that is, after that, the latest token corresponding to the api 1 is cached in the redis server, and then, the second client obtains a valid access token.
Specifically, when the application server 3 may verify the apdi 1 and the appecret 1, and when it is determined that the appi 1 and the appecret 1 are verified to be passed, it is determined whether to acquire the access token corresponding to the appi 1 from the redis server, and when the access token stored in the redis server is an updated access token corresponding to the application server 1 or the application server 2, the access token corresponding to the appi 1 may be acquired, and then valid duration verification is performed on the access token, which may specifically refer to the execution of the foregoing steps a-d, and details are not repeated here. When the application server 3 determines that the validity duration of the access token passes the verification, the access token may be sent to the third client, and then sent to the redis server, so that the redis server updates the access token corresponding to the api 1, that is, at this moment, the access token is cached in the redis server. It can be seen that the third client has obtained a valid access token.
In addition, when the application server 3 does not acquire the access token corresponding to the api 1 from the redis server, sending a request for acquiring a distributed lock to the redis server; when a target distributed lock fed back by a redis server is received, an access token acquisition request is sent to an interface open platform server based on the api 1 and the api cret1, then the interface open platform server determines whether the api 1 and the api cret1 conform to the corresponding preset formats, when it is determined that the api 1 and the api cret1 conform to the corresponding preset formats, it may be determined that the authentication of the api 1 and the api cret1 is passed, and when it is determined that the authentication of the api 1 and the api cret1 is passed, a new access token may be fed back to the application server 3.
Further, the application server 3 may receive a new access token fed back by the interface open platform server, send the new access token to the third client, and then send the new access token to the redis server, so that the redis server updates the access token corresponding to the api 1, that is, after that, the latest token corresponding to the api 1 is cached in the redis server, and then, the third client obtains a valid access token.
It should be noted that, if the first client, the second client, and the third client are for different appids, all of them may be executed according to the execution manner of the first client in the foregoing example, so as to obtain a valid access token.
Therefore, based on the method provided by the embodiment of the invention, the validity of the access token correspondingly acquired by each client can be ensured as much as possible.
As shown in fig. 5, the present invention provides an apparatus for determining an access token, comprising: a receiving unit 501, configured to receive a request for obtaining an access token sent by a first API interface client, where the request for obtaining the access token carries a user credential and a credential key; an obtaining unit 502, configured to determine whether to obtain an access token corresponding to the user credential from a preset cache server; a sending unit 503, configured to send a request for obtaining a distributed lock to the preset cache server when an access token corresponding to the user credential is not obtained from the preset cache server; the distributed lock is used for controlling the application servers, so that only one application server updates the access token at the same time; and the processing unit 504 is configured to, when receiving the target distributed lock fed back by the preset cache server, send an access token acquisition request to the interface open platform server based on the user credential and the credential key, receive a new access token fed back by the interface open platform server, and send the new access token to the first API interface client.
Optionally, the apparatus further includes a verification unit, configured to: when the access token corresponding to the user certificate is obtained from the preset cache server, carrying out valid duration verification on the corresponding access token; and when the corresponding access token valid duration is determined to pass the verification, sending the corresponding access token to the first API interface client.
Optionally, the verification unit is specifically configured to: determining the remaining effective duration of the corresponding access token; determining whether the residual effective time length is greater than a preset time length or not, wherein the preset time length is correspondingly determined based on the data refreshing time length and the guarantee time length of the preset cache server; and when the residual effective duration is determined to be greater than the preset duration, determining that the effective duration of the corresponding access token passes verification.
Optionally, the verification unit is further configured to: and when the residual effective duration is determined to be not greater than the preset duration, sending a request for acquiring the distributed lock to the preset cache server.
Optionally, after sending the request for acquiring the distributed lock to the preset cache server, the apparatus further includes a determining unit, configured to: determining whether a first time interval from the moment of sending the request for obtaining the distributed lock to the current moment reaches a preset time interval; and when the first time interval is determined to reach the preset time interval and the target distributed lock is not received, sending a request for acquiring the distributed lock to the preset cache server.
Optionally, after determining that the first time interval reaches the preset time interval, before sending a request for acquiring a distributed lock to the preset cache server, the determining unit is further configured to: sending, to the first API interface client, whether the cumulative number of times of requests for acquiring the distributed lock reaches a preset number threshold to the preset cache server; and when the accumulated times are determined not to reach the preset times threshold value, sending a request for acquiring the distributed lock to the preset cache server.
Optionally, the access token in the preset cache server is updated correspondingly based on the access token determined by the timing task in the timer corresponding to the preset cache server.
Embodiments of the present invention provide a computer device comprising a program or instructions which, when executed, is configured to perform a method of determining an access token and any optional method provided by embodiments of the present invention.
Embodiments of the present invention provide a storage medium comprising a program or instructions which, when executed, is configured to perform a method for determining an access token and any optional method provided by embodiments of the present invention.
Finally, it should be noted that: as will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.
Claims (10)
1. A method for determining an access token, applied to an application server, comprising:
receiving a request for obtaining an access token sent by a first API client, wherein the request for obtaining the access token carries a user certificate and a certificate key;
determining whether an access token corresponding to the user certificate is acquired from a preset cache server;
when the access token corresponding to the user certificate is not acquired from the preset cache server, sending a request for acquiring a distributed lock to the preset cache server; the distributed lock is used for controlling the application servers, so that only one application server updates the access token at the same time;
and when a target distributed lock fed back by the preset cache server is received, sending an access token obtaining request to an interface open platform server based on the user certificate and the certificate key, receiving a new access token fed back by the interface open platform server, and sending the new access token to the first API interface client.
2. The method of claim 1, wherein after determining whether the access token corresponding to the user credential is obtained from a preset cache server, the method further comprises:
when the access token corresponding to the user certificate is obtained from the preset cache server, carrying out valid duration verification on the corresponding access token;
and when the corresponding access token valid duration is determined to pass the verification, sending the corresponding access token to the first API interface client.
3. The method of claim 2, wherein validating the corresponding access token comprises:
determining the remaining effective duration of the corresponding access token;
determining whether the residual effective time length is greater than a preset time length or not, wherein the preset time length is correspondingly determined based on the data refreshing time length and the guarantee time length of the preset cache server;
and when the residual effective duration is determined to be greater than the preset duration, determining that the effective duration of the corresponding access token passes verification.
4. The method of claim 3, wherein after determining whether the remaining effective duration is greater than a preset duration, the method further comprises:
and when the residual effective duration is determined to be not greater than the preset duration, sending a request for acquiring the distributed lock to the preset cache server.
5. The method of claim 1, wherein after sending the request to obtain the distributed lock to the pre-provisioned cache server, the method further comprises:
determining whether a first time interval from the moment of sending the request for obtaining the distributed lock to the current moment reaches a preset time interval;
and when the first time interval is determined to reach the preset time interval and the target distributed lock is not received, sending a request for acquiring the distributed lock to the preset cache server.
6. The method of claim 5, wherein after determining that the first time interval reaches the preset time interval, before sending a request to the preset cache server to acquire a distributed lock, the method further comprises:
sending, to the first API interface client, whether the cumulative number of times of requests for acquiring the distributed lock reaches a preset number threshold to the preset cache server;
and when the accumulated times are determined not to reach the preset times threshold value, sending a request for acquiring the distributed lock to the preset cache server.
7. The method of claim 1, wherein the access token in the preset cache server is updated based on the access token determined by the timing task in the timer corresponding to the preset cache server.
8. An apparatus for determining an access token, applied to an application server, comprising:
the system comprises a receiving unit, a first API interface client and a second API interface client, wherein the receiving unit is used for receiving a request for obtaining an access token sent by the first API interface client, and the request for obtaining the access token carries a user certificate and a certificate key;
the acquisition unit is used for determining whether an access token corresponding to the user certificate is acquired from a preset cache server or not;
the sending unit is used for sending a request for obtaining the distributed lock to the preset cache server when the access token corresponding to the user certificate is not obtained from the preset cache server; the distributed lock is used for controlling the application servers, so that only one application server updates the access token at the same time;
and the processing unit is used for sending an access token obtaining request to an interface open platform server based on the user certificate and the certificate key when receiving the target distributed lock fed back by the preset cache server, receiving a new access token fed back by the interface open platform server, and sending the new access token to the first API interface client.
9. A computer device comprising a program or instructions that, when executed, perform the method of any of claims 1 to 7.
10. A storage medium comprising a program or instructions which, when executed, perform the method of any one of claims 1 to 7.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111124112.4A CN113852631A (en) | 2021-09-24 | 2021-09-24 | Method and device for determining access token |
| PCT/CN2022/120217 WO2023045970A1 (en) | 2021-09-24 | 2022-09-21 | Method and apparatus for determining access token |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111124112.4A CN113852631A (en) | 2021-09-24 | 2021-09-24 | Method and device for determining access token |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113852631A true CN113852631A (en) | 2021-12-28 |
Family
ID=78979411
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111124112.4A Pending CN113852631A (en) | 2021-09-24 | 2021-09-24 | Method and device for determining access token |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN113852631A (en) |
| WO (1) | WO2023045970A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114844636A (en) * | 2022-05-19 | 2022-08-02 | 青岛海尔科技有限公司 | Method and device for updating access token, storage medium and electronic device |
| WO2023045970A1 (en) * | 2021-09-24 | 2023-03-30 | 深圳前海微众银行股份有限公司 | Method and apparatus for determining access token |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110266703A (en) * | 2019-06-25 | 2019-09-20 | 广州小鹏汽车科技有限公司 | Token method for refreshing, device, storage medium and controlling terminal |
| CN112491778A (en) * | 2019-09-11 | 2021-03-12 | 北京京东尚科信息技术有限公司 | Authentication method, device, system and medium |
| US11263061B2 (en) * | 2020-02-24 | 2022-03-01 | Microsoft Technology Licensing, Llc | Efficient and scalable use of shared resources |
| CN112486696A (en) * | 2020-12-11 | 2021-03-12 | 上海悦易网络信息技术有限公司 | Method and equipment for acquiring distributed lock |
| CN113852631A (en) * | 2021-09-24 | 2021-12-28 | 深圳前海微众银行股份有限公司 | Method and device for determining access token |
-
2021
- 2021-09-24 CN CN202111124112.4A patent/CN113852631A/en active Pending
-
2022
- 2022-09-21 WO PCT/CN2022/120217 patent/WO2023045970A1/en unknown
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023045970A1 (en) * | 2021-09-24 | 2023-03-30 | 深圳前海微众银行股份有限公司 | Method and apparatus for determining access token |
| CN114844636A (en) * | 2022-05-19 | 2022-08-02 | 青岛海尔科技有限公司 | Method and device for updating access token, storage medium and electronic device |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023045970A1 (en) | 2023-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2019246872B2 (en) | Tiered connection pooling methods, systems and computer readable storage media | |
| US20170289134A1 (en) | Methods and apparatus for assessing authentication risk and implementing single sign on (sso) using a distributed consensus database | |
| CN107124431B (en) | Authentication method, device, computer readable storage medium and authentication system | |
| US10819701B2 (en) | Autonomous secrets management for a managed service identity | |
| WO2023045970A1 (en) | Method and apparatus for determining access token | |
| US11762980B2 (en) | Autonomous secrets renewal and distribution | |
| US10691790B2 (en) | Autonomous secrets management for a temporary shared access signature service | |
| EP3765982B1 (en) | Autonomous cross-scope secrets management | |
| JP5837987B2 (en) | Automated password management | |
| CN109936552B (en) | Key authentication method, server and system | |
| CN108696356B (en) | Block chain-based digital certificate deleting method, device and system | |
| CN106357694B (en) | Access request processing method and device | |
| CN113271296B (en) | Login authority management method and device | |
| WO2023093500A1 (en) | Access verification method and apparatus | |
| CN114301678B (en) | Data access method and device, electronic equipment and storage medium | |
| US8719622B2 (en) | Recording and preventing crash in an appliance | |
| CN112003852B (en) | Resource access control method, device, equipment and storage medium | |
| CN113312576A (en) | Page jump method, system and device | |
| CN112953719B (en) | Token authentication method and device | |
| CN112861092B (en) | Method and system for realizing single-terminal login restriction based on JWT authentication application | |
| US20220100485A1 (en) | Applet package sending method and device, electronic apparatus, and computer readable medium | |
| EP3490214A1 (en) | Method for managing lifecycle of credentials | |
| JP6180491B2 (en) | Automated password management | |
| CN115632802A (en) | Processing method and device for authorization duration | |
| CN116954933A (en) | Interface calling method and device, storage medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |