Authentication system, method, client, server, device, medium, and product

Abstract

Embodiments of the present disclosure disclose authentication system, method, client, server, device, medium, and product. The system comprising a client comprising a first storage, a resource server comprising a second storage, and an authentication server, wherein the client, configured to obtain an access token from the authentication server before determining to access the resource server, store the access token in the first storage, acquire the access token from the first storage when determining to access the resource server, generate a business request carrying the access token, and send the business request; the resource server, configured to obtain a public key from the authentication server before receiving the business request, store the public key in the second storage, receive the business request, acquire the public key from the second storage, and verify the access token based on the public key; the authentication server, configured to provide the access token and the public key. The business processing time of the client and resource server is saved, and the service availability is improved.

Description

Authentication system, method, client, server, device, medium, and productFIELD

[0001] The present disclosure relates to the technical field of network security technology, in particular to an authentication system, method, client, server, device, medium, and product.BACKGROUND

[0002] In authorization models (such as OAuth2) , when client wants to request data from resource server, it needs to request an access token from authorization server and then send it along with a business request to the resource server. The resource server needs to verify the access token with a public key obtained from the authorization server before processing the request.

[0003] However, the network connection between the client or resource server with the authorization server may be unstable, which can affect the availability of business functions.SUMMARY

[0004] Embodiments of the present disclosure propose an authentication system, method, client, server, device, medium, and product.

[0005] In a first aspect, an authentication system is provided. The system comprising a client comprising a first storage, a resource server comprising a second storage, and an authentication server, wherein the client, configured to obtain an access token from the authentication server before determining to access the resource server, store the access token in the first storage, acquire the access token from the first storage when determining to access the resource server, generate a business request carrying the access token, and send the business request; the resource server, configured to obtain a public key from the authentication server before receiving the business request, store the public key in the second storage, receive the business request, acquire the public key from the second storage, and verify the access token based on the public key; the authentication server, configured to provide the access token and the public key.

[0006] In a second aspect, an authentication method executed by a client is provided. The method comprising: obtaining an access token from an authentication server before determining to access a resource server; storing the access token in a first storage of the client; acquiring the access token from the first storage when determining to access the resource server; generating a business request carrying the access token; and sending the business request to the resource server; wherein the resource server verifies the access token based on a public key obtained  from the authentication server before receiving the business request.

[0007] In a third aspect, an authentication method executed by a resource server is provided. The method comprising: obtaining a public key from an authentication server before receiving a business request from a client; storing the public key in a second storage of the resource server; receiving the business request from the client, wherein the business request carries an access token, which is obtained by the client from the authentication server before determining to access the resource server; acquiring the public key from the second storage in response to the business request; and verifying the access token based on the public key.

[0008] In a fourth aspect, a client is provided. The client comprising: an obtaining module, configured to obtain an access token from an authentication server before determining to access a resource server; a storing module, configured to store the access token in a first storage of the client; an acquiring module, configured to acquire access token from the first storage when determining to access the resource server; a generating module, configured to generate a business request carrying the access token; and a sending module, configured to send the business request to the resource server; wherein the resource server verifies the access token based on a public key obtained from the authentication server before receiving the business request.

[0009] In a fifth aspect, a resource server is provided. The resource server comprising: an obtaining module, configured to obtain a public key from an authentication server before receiving a business request from a client; a storing module, configured to store the public key in a second storage of the resource server; a receiving module, configured to receive the business request from the client, wherein the business request carries an access token, which is obtained by the client from the authentication server before determining to access the resource server; an acquiring module, configured to acquire the public key from the second storage in response to the business request; and a verifying module, configured to verify the access token based on the public key.

[0010] In a sixth aspect, an electronic device is provided. The electronic device comprising a processor and a memory, wherein an application program executable by the processor is stored in the memory for causing the processor to execute an authentication method as described in any of the above.

[0011] In a seventh aspect, a computer-readable medium comprising computer-readable instructions stored thereon is provided, wherein the computer-readable instructions for executing an authentication method as described in any of the above.

[0012] In an eighth aspect, a computer program product comprising a computer program, when the computer program is executed by a processor for executing an authentication method as described in any of the above.

[0013] According to the above technical solutions, the system comprising a client comprising a first storage, a resource server comprising a second storage, and an authentication server. The client is configured to obtain an  access token from the authentication server before determining to access the resource server, store the access token in the first storage, acquire the access token from the first storage when determining to access the resource server, generate a business request carrying the access token, and send the business request. The resource server is configured to obtain a public key from the authentication server before receiving the business request, store the public key in the second storage, receive the business request, acquire the public key from the second storage, and verify the access token based on the public key; the authentication server, configured to provide the access token and the public key. Therefore, the client can previously request access token from the authentication server and store the access token in its local storage before sending a business request. When the client sends a business request, it only needs to read the access token obtained previously from the authentication server which is stored in the local storage of the client, instead of requesting an access token from the authentication server at this time, which saves the client's business processing time and improves business availability (even if the authentication server cannot be accessed at this time, there is no need to worry about availability of access token) . In addition, the resource server also obtains and stores previously the public key in local storage of the resource server. When the resource server needs to use public key to verify access token, the resource server only needs to read the public key from the local storage of the resource server, which saves the business processing time of the resource server and improves the business availability (even if the authentication server cannot be accessed at this time, there is no need to worry about availability of public key) .BRIEF DESCRIPTION OF THE DRAWINGS

[0014] To make technical solutions of examples of the present disclosure clearer, accompanying drawings to be used in description of the examples will be simply introduced hereinafter. Obviously, the accompanying drawings to be described hereinafter are only some examples of the present disclosure. Those skilled in the art may obtain other drawings according to these accompanying drawings without creative labor.

[0015] Fig. 1 is a schematic diagram of an authentication system in the prior art.

[0016] Fig. 2 is an exemplary configuration diagram of an authentication system according to an embodiment of the present disclosure.

[0017] Fig. 3 is an exemplary schematic diagram of an authentication process according to an embodiment of the present disclosure.

[0018] Fig. 4 is a first exemplary flow chart of an authentication method according to an embodiment of the present disclosure.

[0019] Fig. 5 is a second exemplary flow chart of an authentication method according to an embodiment of the  present disclosure.

[0020] Fig. 6 is an exemplary structural diagram of a client according to an embodiment of the present disclosure.

[0021] Fig. 7 is an exemplary structure diagram of a resource server according to an embodiment of the present disclosure.

[0022] Fig. 8 is a structural diagram of an electronic device according to an embodiment of the present disclosure.

[0023] List of reference numbers: DETAILED DESCRIPTION

[0024] To make the purpose, technical scheme, and advantages of the disclosure clearer, the following examples are given to further explain the disclosure in detail. Nouns and pronouns related to people in this patent application are not limited to specific gender.

[0025] To be concise and intuitive in description, the scheme of the disclosure is described below by describing several representative embodiments. Many details in the embodiments are only used to help understand the scheme of the disclosure. However, it is obvious that the technical scheme of the disclosure can be realized without being limited to these details. To avoid unnecessarily blurring the scheme of the disclosure, some embodiments are not described in detail, but only the framework is given. Hereinafter, "including" refers to "including but not limited to" , "according to... " refers to "at least according to..., but not limited to... " . When the number of an element is not specifically indicated below, it means that the element can be one or more, or can be understood as at least one. The terms "a" or "an" in this disclosure should not be understood as one, but as at least one.

[0026] Fig. 1 is a schematic diagram of an authentication system in the prior art. The authentication system includes a client 10, a resource server 11 and an authentication server 12. The client 10 expects to access resources in the resource server 11. The authentication process includes the following steps:

[0027] S100: client 10 determines to access resource server 12.

[0028] S101: client 10 requests an access token from the authorization server 12, and the authorization server 12 returns the access token to the client 10.

[0029] S102: client 10 carries the access token in a business request and sends the business request to resource server 11.

[0030] S103: resource server 11 receives the business request, requests public key from the authorization server 12, and the authorization server 12 replies public key to the resource server 11.

[0031] S104: resource server 11 verifies the access token in the business request based on the public key. When the authentication is passed, provide resources for the client 10; When the authentication fails, the client 10 is denied to access resources of resource server 11.

[0032] In this processing mode, client 10 requests an access token from authorization server 12 when it is  determined to access resource server 12 and resource server 11 requests a public key from the authorization server 12 when resource server 11 receives a business request from client 10. However, considering that the network connection between client 10 or resource server 11 with authorization server 12 may be unstable, it may cause client 10 to fail to receive access token for a long time and / or resource server 11 to fail to receive public key for a long time, thus affecting the availability of business functions. It is usually based on a long timeout connection or retry mechanism with the authorization server 12 to try to solve the problem. While long timeout connection with the authorization server 12 affects service response time, and the retry mechanism also affects the service stability.

[0033] According to embodiments of the present disclosure, client previously requests access token from authentication server and stores the access token in local storage of the client before sending business request. When it is determined that the client shall send a business request, it only needs to read the access token obtained previously from the local storage of the client, instead of requesting access token from the authentication server at this time, which saves the client's business processing time and improves business availability. In addition, the resource server also obtains public key from authentication server and stores in advance in local storage of the resource server. When resource server needs to use public key to verify access token, resource server only needs to read the public key from local storage of the resource server, which saves business processing time of the resource server and improves business availability.

[0034] The above disclosure details the technical defects in the prior art, the causes of the technical defects, and the thinking and analysis process to overcome the technical defects. In fact, the cognition of the above technical defects is not a general knowledge in the field, but a novel discovery of the applicant in the research. In addition, the cause tracing of the technical defect and the thinking and analysis process to overcome the technical defect are also the results of the applicant's gradual analysis in the actual research process, and are not universal knowledge in the field.

[0035] Fig. 2 is an exemplary configuration diagram of an authentication system according to an embodiment of the present disclosure. As shown in Figure 2, the system includes a client 20, a resource server 30, and an authentication server 40.

[0036] The client 20 includes a first storage 22. The client 20 obtains an access token from the authentication server 40 and stores the access token in the first storage 22 before determining to access the resource server 30. When it is determined to access the resource server 30, the access token is read from the first storage 22. The client 20 generates a business request carrying the access tokens and sends the business request to the resource server 30.

[0037] The resource server 30 includes a second storage 32. The resource server 30 acquires a public key from the authentication server 40 before receiving the business request from the client 20. The resource server 30 stores the  public key in the second storage 32. Later, the resource server 30 receives the business from the client 20, reads the public key from the second storage 32 in response to the business request, and verifies the access token based on the public key. The authentication server 40 is configured to provide both access token and public key.

[0038] For example, both the first storage 22 and the second storage 32 can be implemented as cache memory.

[0039] The client 20 refers to a hardware device or application program that attempts to access resources in the resource server 30. For example, according to the OAuth 2.0 specification, client 20 can include: (1) : public clients: clients that run in an environment that cannot be kept secret, such as mobile applications or JavaScript applications. (2) confidential clients: clients that can maintain authentication information, such as server-side applications. Public clients and confidential clients differ in implementation, but both need to provide some information, such as the application's identity (client ID) , when requesting authorization or obtaining a token.

[0040] For example, client 20 can use OAuth2Rest Template or Rest Template to send business requests to resource server 30.

[0041] The resource server 30 may manage and provide specific resources. In a broader context, resource server 30 may be viewed as part of a computer system capable of providing services in the network. Its main functions include verifying the access token to check whether the resources requested by the client 20 are authorized to access, and providing the requested resources to the client 20 after the verification is passed. The resource server 30 needs to consider some key issues in terms of security, such as verifying the validity of the access token, checking the token signature, expiration time, permissions, etc., to ensure that only authorized users can access limited resources. In addition, the resource server 30 can also take appropriate data protection measures, such as using encryption algorithms to encrypt sensitive data for storage and transmission, to prevent unauthorized access and protect the confidentiality of data. At the same time, the resource server 30 can record and monitor the access behavior of the client 20, to timely discover security events such as abnormal access and intrusion. The architecture of resource server 30 can vary according to the application requirements, including single application, distributed application and microservice architecture. Each architecture has its advantages and disadvantages, for example, single application simplifies deployment and maintenance, but lacks flexibility and scalability; The microservice architecture realizes a high degree of resource splitting and management, but increases the complexity of communication and coordination between services.

[0042] The authentication server 40 is a server responsible for authenticating the user identity and granting application authorization. It interacts with client 20 (such as Web or mobile applications) and resource server 30 through a series of APIs to securely manage access to protected resources.

[0043] In one embodiment, the client 20 comprises a first daemon process 23. The first daemon process 23 is  configured to obtain the access token from the authentication server 40 before determining to access the resource server 30, store the access token in the first storage 22, determine periodically whether the access token in the first storage 22 has expired, obtain an updated access token from the authentication server 40 when it is determined that the access token has expired, and update the expired access token in the first storage 22 based on the updated access token.

[0044] In one embodiment, the resource server 30 comprises a second daemon process 33. The second daemon process 33 is configured to obtain public key from authentication server 40 before receiving the business request, store the public key in the second storage 32, obtain periodically an updated public key from the authentication server 40, and update periodically the public key in the second storage 32 based on the updated public key.

[0045] The first daemon process 23 and the second daemon process 33 are daemons that run in the background. For example, the first daemon process 23 and the second daemon process 33 can be started when their respective systems boot, and continue to run until their respective systems shut down. Preferably, the first daemon 23 and the second daemon 33 have the following characteristics: (1) Background running: The first daemon process 23 and the second daemon process 33 run in the background and are not controlled by the terminal, which prevents the process from being interrupted by terminal information during execution. (2) Long term running: The first daemon process 23 and the second daemon process 33 usually start running when the system starts, and run until the system shuts down unless they are forcibly terminated.

[0046] The client 20 may include the business function 21 of the client. The business function 21 can be used to determine whether to access resource server 30 or not. The resource server 30 may include business function 31 of the resource server. The business function 31 can be used to verify access token based on public key.

[0047] In one embodiment, the client 20 is configured to predict time point of accessing the resource server 30 based on historical behavior data of accessing the resource server 30, and obtain the access token from the authentication server 40 before the predicted time point. Therefore, based on the historical behavior data of accessing the resource server 30, predict the time point of the next access to the resource server, and obtain the access token in advance of this time point, to realize a way of obtaining the access token in advance. For example, business function 21 of client 20 may analyze historical behavior data of accessing resource server 30 to predict time point of next access to the resource server 30. Moreover, before the time point arrives, business function 21 of client 20 instructs the first daemon process 23 to obtain an access token from the authentication server 40. For example, based on historical behavior data, it is found that client 20 often accesses resource server 30 at 9: 00 a. m. on Thursday every week. Therefore, an access token can be obtained from the authentication server at 8: 00 a. m. on Thursday of this week.

[0048] Based on the system structure shown in Figure 2, the authentication process includes the following steps:

[0049] S200: client 20 determines to access resource server 40.

[0050] S201: client 20 reads a pre-stored access token from the first storage 22. Before step S200, the first daemon process 23 has requested an access token from authentication server 40 and stored the access token in the first storage 22. Moreover, before step S200, the first daemon process 23 continuously maintains the validity period of the access token in the first storage 22. Specifically, the first daemon process 23 is used to periodically determine whether the access token in the first storage 22 has expired. When it expires, an updated access token is obtained from the authentication server 40 by the first daemon process 23, and the expired access token in the first storage 22 is updated based on the updated access token. Preferably, the maintenance cycle of the first daemon 23 is less than the validity period of the access token.

[0051] S202: business function 21 carries the access token in a business request and sends the business request to business function 31 of resource server 30.

[0052] S203: business function 31 of resource server 30 receives the business request and reads a pre-stored public key from the second storage 32. Before step S203, the second daemon process 33 has requested the public key from authentication server 40 and stored it in the second storage 32. Moreover, before step S203, the second daemon process 23 continuously maintains the validity period of the public key in the second storage 32. Specifically, the second daemon process 33obtains periodically an updated public key from the authentication server 40, and updates periodically the public key in the second storage 32 based on the updated public key.

[0053] S204: business function 31 of resource server 30 verifies the access token in the business request based on the public key. When the authentication is passed, provide resources for the client 20. When the authentication fails, the client 20 is denied to resources.

[0054] For example, the access token can be verified through asymmetric verification algorithm. For example, asymmetric verification algorithms can include RSA, DSA, ECC (Elliptic Curve Cryptography) , etc. Among them: (1) RSA algorithm: This is a difficult asymmetric encryption algorithm based on large number decomposition. It needs to select two large prime numbers as part of the private key, and then calculate their product as part of the public key. The security of RSA algorithm depends on the difficulty of large number decomposition. It is recommended to use a key length of 2048 bits or more. RSA algorithm is one of the most widely used asymmetric encryption algorithms. For example, RSA algorithm is used in SSL / TLS, SSH and other protocols. (2) DSA algorithm: This is an asymmetric encryption algorithm based on the difficulty of discrete logarithms. It needs to select a prime number q and a multiple p of q as part of the private key, and then calculate the original root g of a module p and an integer y of a module q as part of the public key. The security of DSA algorithm depends on the  difficulty of discrete logarithm. It is recommended to use 2048 bits or more of key length. DSA algorithm has the advantage of fast digital signature speed and is suitable for generating digital certificates, but its disadvantage is that it cannot be used for data encryption, and the signature process requires random numbers. (3) ECC: This is an asymmetric encryption algorithm based on elliptic curve mathematics. ECC can provide the same security level as RSA and DSA by using a smaller key length, so it is increasingly valued in the occasions where efficient and secure communication is required.

[0055] The above exemplary description of a typical example of an authentication algorithm, and those skilled in the art can realize that this description is only exemplary and is not used to limit the protection scope of the embodiment of the disclosure.

[0056] Based on the system architecture shown in Figure 2, Fig. 3 is an exemplary schematic diagram of an authentication process according to an embodiment of the present disclosure. As shown in Figure 3, the process includes a pre-processing stage 60 and a business request authentication stage 70. The pre-processing phase 60 is executed before the business request authentication phase 70.

[0057] The pretreatment stage 60 includes the following steps:

[0058] S301: The first daemon process 23 in client 20 requests an access token from authentication server 40.

[0059] S302: Authentication server 40 returns an access token to the first daemon process 23 in the client 20.

[0060] S303: The first daemon process 23 stores the access token in the first storage 22.

[0061] S304: The first storage 22 returns a storage success notification to the first daemon 23.

[0062] S305: The second daemon process 33 in the resource server 30 requests a public key from the authentication server 40.

[0063] S306: The authentication server 40 returns the public key to the second daemon process 33.

[0064] S307: The second daemon process 33 stores the public key in the second storage 32.

[0065] S308: The second storage 32 returns a storage success notification to the second daemon process 33.

[0066] After the pre-processing stage 60 is executed, then the business request authentication stage 70 is executed. The business request authentication phase 70 includes:

[0067] S309: The business function 21 of the client determines to access the resource server 30.

[0068] S310: The business function 21 of the client reads the access token from the first storage 22.

[0069] S311: The first storage 22 sends the access token to the client business function 21.

[0070] S312: The business function 21 of the client carries the access token in the business request and sends the business request to the business function 31 of the resource server.

[0071] S313: The business function 31 of the resource server 30 reads the public key from the second storage 32.

[0072] S314: The second storage 32 sends the public key to the business function 31 of the resource server 30.

[0073] S315: The business function 31 of the resource server 30 verifies the access token based on the public key.

[0074] S316: The business function 31 of the resource server 30 sends a reply message to the business function 21 of the client 20 based on the verification result.

[0075] Fig. 4 is a first exemplary flow chart of an authentication method according to an embodiment of the present disclosure. The method is executed by a client. As shown in Figure 4, the method includes the following steps:

[0076] S401: obtaining an access token from an authentication server before determining to access a resource server.

[0077] S402: storing the access token in a first storage of the client.

[0078] S403: acquiring the access token from the first storage when determining to access the resource server.

[0079] S404: generating a business request carrying the access token.

[0080] S404: sending the business request to the resource server.

[0081] The resource server verifies the access token based on a public key obtained from the authentication server before receiving the business request. In one embodiment, the method comprises: configuring a first daemon process in the client; enabling the first daemon to obtain the access token from the authentication server before determining to access the resource server, store the access token in the first storage, and determine periodically whether the access token in the first storage has expired; enabling the first daemon to obtain an updated access token from the authentication server and update the expired access token in the first storage based on the updated access token when it is determined that the access token in the first storage has expired. In one embodiment, the method comprises: predicting time point of accessing the resource server based on historical behavior data of accessing the resource server; obtaining the access token from the authentication server before the predicted time point.

[0082] Fig. 5 is a second exemplary flow chart of an authentication method according to an embodiment of the present disclosure. The method is executed by a resource server. As shown in Figure 5, the method includes the following steps:

[0083] S501: obtaining a public key from an authentication server before receiving a business request from a client.

[0084] S502: storing the public key in a second storage of the resource server.

[0085] S503: receiving the business request from the client, wherein the business request carries an access token, which is obtained by the client from the authentication server before determining to access the resource server.

[0086] S504: acquiring the public key from the second storage in response to the business request.

[0087] S505: verifying the access token based on the public key

[0088] In one embodiment, the method comprises: configuring a second daemon process in the resource server;  enabling the second daemon to obtain the public key from the authentication server before receiving the business request, store the public key in the second storage, and obtain periodically an updated public key from the authentication server and update periodically the public key in the second storage based on the updated public key.

[0089] Fig. 6 is an exemplary structural diagram of a client according to an embodiment of the present disclosure. The client 600 comprises: an obtaining module 601, configured to obtain an access token from an authentication server before determining to access a resource server; a storing module 602, configured to store the access token in a first storage of the client; an acquiring module 603, configured to acquire access token from the first storage when determining to access the resource server; a generating module 604, configured to generate a business request carrying the access token; and a sending module 605, configured to send the business request to the resource server. the resource server verifies the access token based on a public key obtained from the authentication server before receiving the business request.

[0090] Fig. 7 is an exemplary structure diagram of a resource server according to an embodiment of the present disclosure. The resource server 700 comprises: an obtaining module 701, configured to obtain a public key from an authentication server before receiving a business request from a client; a storing module 702, configured to store the public key in a second storage of the resource server; a receiving module 703, configured to receive the business request from the client, wherein the business request carries an access token, which is obtained by the client from the authentication server before determining to access the resource server; an acquiring module 704, configured to acquire the public key from the second storage in response to the business request; and a verifying module 705, configured to verify the access token based on the public key.

[0091] To sum up, the system of present disclosure comprises a client, a resource server, and an authentication server. The client comprising a first storage, configured to obtain an access token from the authentication server before determining to access the resource server, store the access token in the first storage previously before sending business request, acquire the access token from the first storage when determining to access the resource server, generate a business request carrying the access token, and send the business request. The resource server comprising a second storage, configured to obtain a public key from the authentication server before receiving the business request, store the public key in the second storage, receive the business request, acquire the public key from the second storage, and verify the access token based on the public key. The authentication server is configured to provide the access token and the public key. Therefore, the client can previously request access token from the authentication server and store the access token in its local storage before sending a business request. When the client sends a business request, it only needs to read the access token obtained previously from the authentication server which is stored in the local storage of the client, instead of requesting an access token  from the authentication server at this time, which saves the client's business processing time and improves business availability (even if the authentication server cannot be accessed at this time, there is no need to worry about availability of access token) . In addition, the resource server also obtains and stores previously the public key in local storage of the resource server. When the resource server needs to use public key to verify access token, the resource server only needs to read the public key from the local storage of the resource server, which saves the business processing time of the resource server and improves the business availability (even if the authentication server cannot be accessed at this time, there is no need to worry about availability of public key) .

[0092] Embodiments of the present disclosure also propose an electronic device with a processor memory architecture. Fig. 8 is a structural diagram of an electronic device according to an embodiment of the present disclosure. As shown in Figure 8, electronic device 800 includes a processor 801, a memory 802, and a computer program stored on memory 802 that can run on processor 801. When the computer program is executed by processor 801, the authentication method as described above is implemented. Among them, memory 802 can be implemented as various storage media such as electrically erasable programmable read-only memory (EEPROM) , flash memory, programmable program read-only memory (PROM) , etc. Processor 801 can be implemented to include one or more central processors or one or more field programmable gate arrays, wherein the field programmable gate array integrates one or more central processor cores. Specifically, the central processing unit or core can be implemented as a CPU, MCU, DSP, and so on.

[0093] It should be noted that not all steps and modules in the above processes and structural diagrams are necessary, and some steps or modules can be ignored according to actual needs. The execution sequence of each step is not fixed and can be adjusted as needed. The division of each module is only for the convenience of describing the functional division used. In actual implementation, a module can be divided into multiple modules, and the functions of multiple modules can also be implemented by the same module. These modules can be in the same device or different devices.

[0094] The hardware modules in each implementation can be implemented mechanically or electronically. For example, a hardware module can include specially designed permanent circuits or logic devices (such as dedicated processors, such as FPGA or ASIC) to complete specific operations. Hardware modules can also include programmable logic devices or circuits temporarily configured by software (such as general-purpose processors or other programmable processors) for performing specific operations. As for the specific use of mechanical methods, either dedicated permanent circuits or temporarily configured circuits (such as software configuration) to implement hardware modules, it can be determined based on cost and time considerations.

[0095] The above is only a preferred embodiment of the present disclosure and is not intended to limit the scope of  protection of the present disclosure. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this disclosure shall be included within the scope of protection of this disclosure.

Claims

1.An authentication system, comprising a client (20) comprising a first storage (22) , a resource server (30) comprising a second storage (32) , and an authentication server (40) , wherein:the client (20) , configured to obtain an access token from the authentication server (40) before determining to access the resource server (30) , store the access token in the first storage (22) , acquire the access token from the first storage (22) when determining to access the resource server, generate a business request carrying the access token, and send the business request;the resource server (30) , configured to obtain a public key from the authentication server (40) before receiving the business request, store the public key in the second storage (32) , receive the business request, acquire the public key from the second storage (32) , and verify the access token based on the public key;the authentication server (40) , configured to provide the access token and the public key.2.The system of claim 1, wherein the client (20) comprises a first daemon process (23) ;the first daemon process (23) is configured to obtain the access token from the authentication server (40) before determining to access the resource server (30) , store the access token in the first storage (22) , determine periodically whether the access token in the first storage (22) has expired, obtain an updated access token from the authentication server (40) when it is determined that the access token has expired, and update the expired access token in the first storage (22) based on the updated access token.3.The system of claim 1, wherein the resource server (30) comprises a second daemon process (33) ;the second daemon process (33) is configured to obtain the public key from the authentication server (40) before receiving the business request, store the public key in the second storage (32) , obtain periodically an updated public key from the authentication server (40) , and update periodically the public key in the second storage (32) based on the updated public key.4.The system of claim 1, wherein the client (20) is configured to predict time point of accessing the resource server (30) based on historical behavior data of accessing the resource server (30) , and obtain the access token from the authentication server (40) before the predicted time point.5.An authentication method executed by a client, comprising:obtaining (S401) an access token from an authentication server before determining to access a resource server;storing (S402) the access token in a first storage of the client;acquiring (S403) the access token from the first storage when determining to access the resource server;generating (S404) a business request carrying the access token; andsending (S405) the business request to the resource server;wherein the resource server verifies the access token based on a public key obtained from the authentication server before receiving the business request.6.The method of claim 5, comprising:configuring a first daemon process in the client;enabling the first daemon to obtain the access token from the authentication server before determining to access the resource server, store the access token in the first storage, and determine periodically whether the access token in the first storage has expired;wherein enabling the first daemon to obtain an updated access token from the authentication server and update the expired access token in the first storage based on the updated access token when it is determined that the access token in the first storage has expired.7.The method of claim 5, comprising:predicting time point of accessing the resource server based on historical behavior data of accessing the resource server;obtaining the access token from the authentication server before the predicted time point.8.An authentication method executed by a resource server, comprising:obtaining (S501) a public key from an authentication server before receiving a business request from a client;storing (S502) the public key in a second storage of the resource server;receiving (S503) the business request from the client, wherein the business request carries an access token, which is obtained by the client from the authentication server before determining to access the resource server;acquiring (S504) the public key from the second storage in response to the business request; andverifying (S505) the access token based on the public key.9.The method of claim 8, comprising:configuring a second daemon process in the resource server;enabling the second daemon to obtain the public key from the authentication server before receiving the business request, store the public key in the second storage, and obtain periodically an updated public key from the authentication server and update periodically the public key in the second storage based on the updated public key.10.A client, comprising:an obtaining module (601) , configured to obtain an access token from an authentication server before determining to access a resource server;a storing module (602) , configured to store the access token in a first storage of the client;an acquiring module (603) , configured to acquire access token from the first storage when determining to access the resource server;a generating module (604) , configured to generate a business request carrying the access token; anda sending module (605) , configured to send the business request to the resource server;wherein the resource server verifies the access token based on a public key obtained from the authentication server before receiving the business request.11.A resource server, comprising:an obtaining module (701) , configured to obtain a public key from an authentication server before receiving a business request from a client;a storing module (702) , configured to store the public key in a second storage of the resource server;a receiving module (703) , configured to receive the business request from the client, wherein the business request carries an access token, which is obtained by the client from the authentication server before determining to access the resource server;an acquiring module (704) , configured to acquire the public key from the second storage in response to the business request; anda verifying module (705) , configured to verify the access token based on the public key.12.An electronic device, comprising a processor (801) and a memory (802) , wherein an application program executable by the processor (801) is stored in the memory (802) for causing the processor (801) to execute an authentication method according to any one of claims 5-7 or an authentication method according to any one of claims 8-9.13.A computer-readable medium comprising computer-readable instructions stored thereon, wherein the computer-readable instructions for executing an authentication method according to any one of claims 5-7 or an authentication method according to any one of claims 8-9.14.A computer program product comprising a computer program, upon the computer program is executed by a processor for executing an authentication method according to any one of claims 5-7 or an authentication method according to any one of claims 8-9.

Images