Resource access method and device, readable medium, electronic equipment and program product

Abstract

The invention discloses a resource access method and device, a readable medium, electronic equipment and a program product. Relates to the technical field of information security. A client sends a resource access request message of a target application to gateway equipment, the resource access request message comprising a first access token issued by the client based on a private key in a service key pair and a session identifier of a session generated by a server based on a login request message sent by the client; sending the first access token and the session identifier to the gateway device, so that the gateway device performs identity authentication on the client through a binding relationship pre-established by the server according to the first access token and the session identifier, and requests a service resource of the target application based on the resource access request message in response to passing of the identity authentication on the client; wherein the binding relationship represents the relationship between the session and the trusted client of the target application. And on the basis of the binding relationship, the client sending the resource access request message can be confirmed to belong to a trusted client, so that Session theft prevention is realized, and the security of service data is improved.

Description

Technical Field

[0001] The present disclosure relates to the field of information security technology, and in particular, to a resource access method, apparatus, readable medium, electronic device, and program product. Background Art

[0002] Session (also known as "session"), as one of the core data of the system, is the only credential for marking a user's logged-in state. The system can confirm the user's identity through the Session. If the Session is stolen during this period, the corresponding account identity will also be taken over, so that the attacker can directly skip the authentication steps before the Session and directly access the core resources of the system, such as some enterprise documents, etc. This will obviously pose a threat to the enterprise's data security. Therefore, how to achieve Session anti-theft is an urgent problem to be solved in this field. Summary of the Invention

[0003] This Summary of the Invention section is provided to introduce concepts in a brief form that will be described in detail in the following Detailed Implementation section. This Summary of the Invention section is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to be used to limit the scope of the claimed technical solution.

[0004] In a first aspect, the present disclosure provides a resource access method, which is applied to a client, and the method includes: Obtain a resource access request message corresponding to a target application, where the resource access request message includes a first access token and a session identifier. The first access token is an access token issued by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of the target application; the session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to the target application; Send the resource access request message to a gateway device, so that the gateway device authenticates the client according to the first access token and the session identifier through a binding relationship pre-established by the server, and in response to successful authentication of the client, request the service resources of the target application based on the resource access request message; the binding relationship represents the binding relationship between the session and the trusted clients of the target application.

[0005] In a second aspect, the present disclosure provides a resource access method, which is applied to a gateway device, and the method includes: Receive a resource access request message sent by a client. The resource access request message includes a first access token and a session identifier. The first access token is an access token signed by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of the target application. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to the target application. Authenticate the client according to the binding relationship pre-established by the server based on the first access token and the session identifier. The binding relationship represents the binding relationship between the session and the trusted client of the target application. In response to successful authentication of the client, request the service resources of the target application based on the resource access request message.

[0006] In a third aspect, the present disclosure provides a resource access method applied to a server. The method includes: Receive a session identifier sent by a gateway device. The session identifier is an identifier included in a resource access request message sent by a client to the gateway device. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to a target application. The resource access request message further includes a first access token, and the first access token is an access token signed by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of the target application. Determine the public key information corresponding to the session according to the session identifier through the binding relationship. The binding relationship represents the binding relationship between the session and the trusted client of the target application. Send the public key information to the gateway device so that the gateway device authenticates the client according to the public key information and the first access token.

[0007] In a fourth aspect, the present disclosure provides a resource access device applied to a client. The device includes: An acquisition module, configured to acquire a resource access request message corresponding to a target application. The resource access request message includes a first access token and a session identifier. The first access token is an access token signed by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of the target application. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to the target application. A first sending module, configured to send the resource access request message to a gateway device, so that the gateway device authenticates the client according to a binding relationship pre-established by the server based on the first access token and the session identifier, and in response to successful authentication of the client, requests business resources of the target application based on the resource access request message; the binding relationship represents the binding relationship between the session and a trusted client of the target application.

[0008] In a fifth aspect, the present disclosure provides a resource access device, which is applied to a gateway device. The device includes: A first receiving module, configured to receive a resource access request message sent by a client. The resource access request message includes a first access token and a session identifier. The first access token is an access token signed by the client based on a private key in a business key pair, and the business key pair is generated by a business domain name of a target application; the session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to the target application. An authentication module, configured to authenticate the client according to a binding relationship pre-established by the server based on the first access token and the session identifier. The binding relationship represents the binding relationship between the session and a trusted client of the target application. A resource access module, configured to, in response to successful authentication of the client, request business resources of the target application based on the resource access request message.

[0009] In a sixth aspect, the present disclosure provides a resource access device, which is applied to a server. The device includes: A second receiving module, configured to receive a session identifier sent by a gateway device. The session identifier is an identifier included in a resource access request message sent by a client to the gateway device. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to a target application; the resource access request message further includes a first access token, and the first access token is an access token signed by the client based on a private key in a business key pair, and the business key pair is generated by the business domain name of the target application. A determination module, configured to determine public key information corresponding to the session according to the session identifier through a binding relationship. The binding relationship represents the binding relationship between the session and a trusted client of the target application. A second sending module, configured to send the public key information to the gateway device, so that the gateway device authenticates the client according to the public key information and the first access token.

[0010] In a seventh aspect, the present disclosure provides a computer-readable medium having stored thereon a computer program, which when executed by a processing device, implements the steps of the method according to any one of the first, second, and third aspects described above.

[0011] In an eighth aspect, the present disclosure provides an electronic device, including: a storage device having stored thereon a computer program; a processing device configured to execute the computer program in the storage device to implement the steps of the method according to any one of the first, second, and third aspects described above.

[0012] In a ninth aspect, the present disclosure provides a computer program product including a computer program, which when executed by a processor, implements the steps of the method according to any one of the first, second, and third aspects described above.

[0013] Through the above technical solution, the client sends a resource access request message corresponding to the target application to the gateway device. The resource access request message includes a first access token signed by the client based on the private key in the service key pair, and a session identifier of the session Session generated by the server based on the login request message sent by the client. The gateway device can authenticate the client according to the first access token and the session identifier through the binding relationship pre-established by the server. Since the binding relationship represents the binding relationship between the session Session and the trusted client of the target application, if the authentication of the client based on the binding relationship is passed, it can be confirmed that the client sending the resource access request message also belongs to the trusted client, thereby realizing Session anti-theft. In response to passing the authentication of the client, the business resources of the target application are requested based on the resource access request message, which can improve the security of business data.

[0014] Other features and advantages of the present disclosure will be described in detail in the subsequent specific implementation section. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In combination with the drawings and with reference to the following specific implementation, the above and other features, advantages, and aspects of the embodiments of the present disclosure will become more apparent. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the original elements and elements are not necessarily drawn to scale. In the drawings: Figure 1 is a flowchart of a resource access method shown according to an exemplary embodiment.

[0016] Figure 2 is according to Figure 1 the embodiment shown, a flowchart of a resource access method.

[0017] Figure 3 is a flowchart of a resource access method shown according to the Figure 1 illustrated embodiment.

[0018] Figure 4 is a flowchart of a certificate generation method shown according to an exemplary embodiment.

[0019] Figure 5 is a flowchart of a resource access method shown according to the Figure 1 illustrated embodiment.

[0020] Figure 6 is a flowchart of a resource access method shown according to an exemplary embodiment.

[0021] Figure 7 is a flowchart of a resource access method shown according to the Figure 6 illustrated embodiment.

[0022] Figure 8 is a flowchart of a resource access method shown according to the Figure 6 illustrated embodiment.

[0023] Figure 9 is a flowchart of a resource access method shown according to an exemplary embodiment.

[0024] Figure 10 is a flowchart of a resource access method shown according to the Figure 9 illustrated embodiment.

[0025] Figure 11 is a flowchart of a resource access method shown according to the Figure 9 illustrated embodiment.

[0026] Figure 12 is a block diagram of a resource access device shown according to an exemplary embodiment.

[0027] Figure 13 is a block diagram of a resource access device shown according to the Figure 12 illustrated embodiment.

[0028] Figure 14 is a block diagram of a resource access device shown according to the Figure 13 illustrated embodiment.

[0029] Figure 15 is a block diagram of a resource access device shown according to the Figure 12 illustrated embodiment.

[0030] Figure 16 is a block diagram of a resource access device shown according to an exemplary embodiment.

[0031] Figure 17 is a block diagram of a resource access device shown according to an exemplary embodiment.

[0032] Figure 18 is according to Figure 17 shown in the embodiment shown is a block diagram of a resource access device.

[0033] Figure 19 is a schematic structural diagram of an electronic device shown according to an exemplary embodiment. Detailed implementation manners

[0034] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. On the contrary, these embodiments are provided to more thoroughly and completely understand the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not used to limit the protection scope of the present disclosure.

[0035] It should be understood that the various steps recited in the method embodiments of the present disclosure can be executed in a different order and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this regard.

[0036] As used herein, the term "including" and its variations are open-ended, that is, "including but not limited to". The term "based on" is "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0037] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order of the functions executed by these devices, modules or units or the interdependent relationship.

[0038] It should be noted that the modifications of "one" and "plural" mentioned in the present disclosure are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly stated in the context, it should be understood as "one or more".

[0039] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only for illustrative purposes and are not used to limit the scope of these messages or information.

[0040] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, usage scopes, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to users and the authorization of users should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0041] For example, when responding to an active request from a user, a prompt message is sent to the user to clearly prompt the user that the operation requested by the user will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, an application program, a server, or a storage medium that performs the operations of the technical solutions of the present disclosure according to the prompt message.

[0042] As an optional but non-limiting implementation manner, the manner of sending a prompt message to the user in response to receiving an active request from the user may be, for example, in the form of a pop-up window, and the prompt message may be presented in text in the pop-up window. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0043] It is understandable that the above process of notifying and obtaining user authorization is only illustrative and does not limit the implementation manners of the present disclosure. Other manners that meet relevant laws and regulations can also be applied to the implementation manners of the present disclosure.

[0044] Meanwhile, it is understandable that the data involved in the present technical solution (including but not limited to the data itself, the acquisition or use of the data) should comply with the requirements of the corresponding laws, regulations and related provisions.

[0045] The present disclosure is mainly applied to the Session anti-theft scenario. When a user logs in to a target application, a login request needs to be sent to an authorization server. The authorization server establishes a Session (i.e., a session) for the login request, and the system determines the user identity through the Session. However, if the Session is stolen, the corresponding account identity will also be taken over, so that an attacker can directly skip the authentication steps before the Session and directly access the business resources of the target application, affecting data security.

[0046] The present disclosure can implement Session anti-theft using the DPoP (Demonstrating Proof of Possession) mechanism. Among them, DPoP describes a technology for encrypting and binding an access token to a specific client when issuing the access token. Based on the DPoP technology, an application using the access token can be required to prove that it possesses the same private key used when obtaining the access token, thereby enhancing the security of data access. In other words, based on the DPoP mechanism, the sender of the DPoP token can be restricted by the proof of possession of the public-private key pair, so that the token can be prevented from being used by an unauthorized third party, thereby enhancing security.

[0047] To achieve the above object, the present disclosure provides a resource access method, device, readable medium, electronic device and program product. The following will describe the specific embodiments of the present disclosure in detail with reference to the accompanying drawings.

[0048] Figure 1 It is a flowchart of a resource access method shown according to an exemplary embodiment, and this method can be applied to a client. As Figure 1 shown, the method includes the following steps: In step S101, obtain a resource access request message corresponding to the target application. The resource access request message includes a first access token and a session identifier. The first access token is an access token issued by the client based on the private key in the service key pair, and the service key pair is generated by the service domain name of the target application; the session identifier is an identifier of a session generated by the server based on the login request message sent by the client, and the login request message is used to request to log in to the target application.

[0049] Among them, the target application can be any application on the selected client, and the target application can be a mobile application or a Web application.

[0050] Generally, after the user logs in to the target application, the user can enter the business page of the target application. The user can operate on the business page based on their own needs. In this way, the client generates a business request message in response to the user's trigger operation on the business page. The business page can hook into the business request message based on the accessed security SDK (Software Development Kit), and then generate the resource access request message based on the business request message. The resource access request message is a request message for requesting access to the business resources corresponding to the target application.

[0051] In addition, the first access token refers to the access token issued by the client based on the private key in the service key pair, which is generated by the service domain name of the target application, and the service domain name is the domain name of the current service page of the target application. The service key pair may include a first public key and a first private key. In this way, the first access token can be issued based on the first private key, and the first private key is set on the client and cannot be exported. The first access token also carries the first public key, and the gateway device can determine that the first access token is issued by its corresponding first private key through the first public key carried in the first access token. Since the first private key cannot be exported, it can be determined that the first access token comes from the service domain name.

[0052] Among them, the first access token and the second access token, third access token, and fourth access token mentioned later can all be DPoP tokens (i.e., DPoP Token).

[0053] The session identifier is the identifier of the session generated by the server based on the login request message sent by the client, and the login request message is used to request to log in to the target application. Among them, the server may be the authorization server corresponding to the target application (also referred to as the "Passport server"). Among them, the Passport server refers to the server for authentication and authorization services, which is mainly used in online services to help developers manage and verify user identities. In response to the user logging in to the target application, the client can send a login request message to the authorization server, and the authorization server establishes a Session (i.e., a session) for the login request message. In this way, the system can determine the user identity through the Session.

[0054] In step S102, the resource access request message is sent to the gateway device, so that the gateway device authenticates the client according to the binding relationship pre-established by the server based on the first access token and the session identifier, and in response to successful authentication of the client, requests the business resources of the target application based on the resource access request message; the binding relationship represents the binding relationship between the session and the trusted client of the target application.

[0055] Among them, the gateway device refers to the device located between the client and the server. In the present disclosure, the authentication of the client sending the request message can be implemented through the gateway device.

[0056] By sending the resource access request message to the gateway device, the gateway device can authenticate the client according to the first access token and the session identifier carried in the resource access request message through the binding relationship pre-established by the server.

[0057] Among them, the binding relationship may include the binding relationship between the second public key and the session Session established by the server for the login request message. Among them, the second public key refers to the public key in the login key pair, and the login key pair is generated by the login domain name of the target application. The binding relationship is established by the authorization server when the user requests to log in to the target application. Therefore, by default, the generating party of the second public key recorded in the binding relationship is the login domain name of the target application on the trusted client.

[0058] The gateway device can obtain the public key corresponding to the private key used to sign the first access token, and obtain the second public key that has a binding relationship with the Session corresponding to the session identifier. The gateway device verifies whether the public key corresponding to the private key used to sign the first access token is consistent with the second public key to verify whether the identity of the client sending the resource access request message is legal. It can be understood that if the public key corresponding to the private key used to sign the first access token is consistent with the second public key, it indicates that the client using the first access token and the Session used to represent the user identity of logging in to the target application have the same private key, and the private key is set to be non-exportable on the client. Therefore, if the public key corresponding to the private key used to sign the first access token is consistent with the second public key, it indicates that the identity of the client sending the resource access request message is legal (that is, the authentication of the client passes).

[0059] In response to the authentication of the client passing, the gateway device can send the resource access request message to the business server corresponding to the target application, so as to access the business resources of the target application from the business server. In this way, the purpose of Session anti-theft can be achieved, and the security of data access to the business resources of the target application can be improved.

[0060] Using the above method, the client sends the resource access request message corresponding to the target application to the gateway device. The resource access request message includes the first access token signed by the client based on the private key in the business key pair, and the session identifier of the session Session generated by the server based on the login request message sent by the client. The gateway device can authenticate the client according to the first access token and the session identifier through the binding relationship pre-established by the server. Since the binding relationship represents the binding relationship between the session Session and the trusted client of the target application, in response to the authentication of the client passing based on the binding relationship, it can be ensured that the client sending the resource access request message also belongs to the trusted client, thus realizing Session anti-theft. That is to say, in response to the authentication of the client passing, requesting the business resources of the target application based on the resource access request message can improve the security of business data.

[0061] Figure 2 is based onFigure 1 The flowchart of a resource access method shown in the illustrated embodiment is as follows Figure 2 As shown, step S101 includes the following sub-steps: In step S1011, in response to obtaining a service request message for the target application, obtain the session identifier and the service key pair.

[0062] Among them, the service key pair can be generated by a service page (or a service intermediate page, where the service intermediate page has the same domain name as the service page but a different path) based on the accessed security SDK. If the target application is a mobile application, it can be generated based on the system's non-exportable private key infrastructure (such as keystore). If the target application is a Web application, it can be generated by web cryptoAPI. Among them, related infrastructure such as a device trusted credential management module based on TEE (Trusted Execution Environment), and TEE refers to a specific secure storage space of a device with a hardware security chip. "Non-exportable private key" can also be achieved through TPM or a hardware cryptographic machine. Among them, TPM (Trusted Platform Module) is a small chip that allows a computer to use advanced security functions and aims to protect hardware by integrating cryptographic keys.

[0063] The generated service key pair can be saved to the index DB. In this way, in this step, the service key pair can be obtained from the index DB.

[0064] It should be noted that storing the public-private key pair (including the service key pair and the login key pair in the following text) in the index DB, since the index DB is asynchronous and can persistently store data in the user's browser. Therefore, storing the public-private key pair in the index DB enables the client to obtain the previously generated public-private key pair even after the user exits and reopens the browser.

[0065] In addition, as described above, the session identifier is generated by the server, and the server can set the generated session identifier in the cookie and send it to the client for storage. In this way, the client can read the session identifier from the cookie.

[0066] In step S1012, generate the first access token according to the service key pair and the service request message.

[0067] Among them, the service key pair includes a first public key and a first private key.

[0068] In this step, a first payload can be constructed based on the service request message; the first private key is used to sign the first payload to obtain a first signature; a first access token is generated based on the first public key, the first payload, and the first signature.

[0069] Among them, the payload is the Payload. The specific content of the service request carried in the service request message can be processed in a structured manner to obtain structured data with different fields as the first payload. Common Payload fields can include, for example, "jti", "htm", "htu", "iat", "nonce". Among them, "jti" is a unique identifier that can be used to identify a specific DPoP token to prevent replay attacks. "htm" can be used to identify the HTTP (HyperText Transfer Protocol) method of the request. "htu" represents the address of the target URL or resource of the request to ensure that the request is sent to the correct URL (Uniform Resource Locator). "iat" represents a timestamp, and this field can be used to indicate the issuance time of the corresponding access token. The recipient can use the information in this field to determine the validity of the access token, such as determining whether a token has expired. "nonce" is a unique random string, usually used to prevent replay attacks. A new random nonce value is generated for each request to ensure that each request is unique, which can help the server identify and reject duplicate requests. It should be noted that "nonce" is an optional item. Usually, when the server returns an error and carries a nonce, it is required to carry the nonce field in the next request, and the nonce field can be the random string issued when the server reports an error, used to prevent replay attacks.

[0070] After constructing the first payload, the first private key can be used to sign the first payload to obtain a first signature signature, and then a JWT (JSON Web Token) is generated using the first public key, the first payload, and the first signature as the first access token.

[0071] In step S1013, after adding the session identifier and the first access token to the service request message, a resource access request message is generated.

[0072] In this step, the first access token can be added to the header (i.e., header) of the service request message, and after adding the session identifier to the service request message, the resource access request message is obtained.

[0073] Figure 3 is a flowchart of a resource access method shown according to the Figure 1 illustrated embodiment, as Figure 3 shown, the method further includes: In step S103, in response to obtaining a login request for the target application, send the login request message to the server according to the login request, the login request message includes a second access token, so that the server establishes the binding relationship based on the second access token, and the second access token is an access token issued by the client based on the private key in the login key pair, and the login key pair is generated by the login domain name of the target application.

[0074] Wherein, the login domain name may be the domain name of the login page of the target application.

[0075] During the execution of this step, the login key pair can be obtained, the login key pair includes a second private key and a second public key; generate the second access token according to the second private key, the second public key and the login request; after adding the second access token to the login request, obtain the login request message; send the login request message to the server.

[0076] Wherein, the login key pair can be generated by the login page based on the accessed security SDK. If the target application is a mobile application, it can be generated based on the system's private key non-exportable infrastructure (such as keystore). If the target application is a Web application, it can be generated by the web crypto API. The generated service key pair can be saved to the index DB. In this way, the login key pair can be obtained from the index DB. The login key pair can include a second public key and a second private key.

[0077] It should be noted that in order to avoid the attacker stealing the public and private key pairs and the public and private key pairs being valid for a long time, thereby increasing the risk of data leakage, a refresh mechanism for the public and private key pairs needs to be established. For the login page, in response to being in a non-login state currently, the login key pair needs to be refreshed. For the business page, the expiration time of the service key pair can be set on the business intermediate page. If the current time exceeds the expiration time (such as the expiration time is set to 1 day), a new service key pair needs to be regenerated.

[0078] After obtaining the login key pair, the second access token can be generated according to the second private key, the second public key and the login request in the following manner: Construct a second payload according to the login request; sign the second payload with the second private key to generate a second signature; generate the second access token according to the second public key, the second payload and the second signature.

[0079] Based on the information such as the username and password recorded in the login request, data can be structurally processed here to obtain structured data with different fields as the second payload. Then, the second private key is used to sign the second payload to obtain a second signature. Next, a JWT Token is generated using the second public key, the second payload, and the second signature as the second access token.

[0080] After the client generates the second access token under the login domain name of the target application, the second access token can be added to the header of the login request to obtain the login request message. The client sends the login request message to the server so that the server can build a binding relationship based on the second access token.

[0081] As described above, the target application can include a mobile application or a Web application. For a Web application, since the Web side cannot use index DB across domain names, that is, the content between different domain names cannot be shared. In an actual application scenario, the business page and the login page of the target application may use different domain names. The binding relationship stored in the server is the binding relationship between the public-private key pair generated by the login domain name and the session. For a Web application, it is necessary to solve the problem of how to bind the public-private key pair generated by a non-login page to the session. The present disclosure can extend the trust relationship from the login domain name to the business domain name through a certificate (Certificate) signed by the public-private key pair (i.e., the login key pair) generated by the login domain name.

[0082] In the present disclosure, in response to the target application being a Web application, the resource access request message may further include a certificate signed by the login domain name of the target application, and the certificate is used to authenticate whether the business domain name is trustworthy.

[0083] Figure 4 is a flowchart of a certificate generation method shown according to an exemplary embodiment. As Figure 4 shown, the client can generate the certificate through the following steps: In step S401, the private key in the business key pair generated using the business domain name is used to sign the third access token.

[0084] In this step, after signing the third payload with the first private key in the business key pair to generate a third signature, a JWT token is generated using the first public key, the third payload, and the third signature as the third access token. Among them, the third payload can be constructed based on the method of the business request, the URL of the business page, and the timestamp of the issuance of the third access token.

[0085] It should be noted that the business domain name generates a non-exportable business key pair with its own private key (i.e., the first private key). By executing this step, the business domain name can use the private key in the business key pair to sign and obtain the third access token, which contains the public key (i.e., the first public key) in the business key pair.

[0086] In a possible implementation, the present disclosure can converge the logic of key pair generation, storage, update, and exception handling to a business intermediate page by adding a business intermediate page, so as to achieve mutual isolation from the upstream business. By decoupling from the service layer, the business intermediate page logic can be independently controlled, and the release is not limited by the business party. It is also convenient to handle some exceptions. For example, if the reading and writing of the index DB is abnormal, the user can be prompted on the business intermediate page. Another example is that for the prompt information of signature verification failure caused by DPoP, it can be carried out on the business intermediate page, and the upstream business does not need to perceive it, thus avoiding the wrong impact on the business party. In this way, the resource access method can be applied to an architecture with multiple business lines running in parallel.

[0087] In this step, it is possible to jump from the business page of the target application to the business intermediate page, and then use the private key in the business key pair generated by the business domain name to sign the third access token on the business intermediate page.

[0088] In step S402, carry the third access token and jump from the business domain name to the login domain name.

[0089] In this step, on the business intermediate page, the business domain name can carry the third access token and jump to the login domain name, so as to attempt to establish a trust relationship with the server through the login domain name.

[0090] In order to handle the public key binding of the business domain name, the present disclosure can add a login binding page under the domain name of the login page (i.e., the login domain name). The login binding page is responsible for passing the third access token generated by the business domain name to the server for binding. It can also handle the binding result. For example, for the case of successful binding, the certificate Certificate can be carried in subsequent requests. For the case of binding failure, information prompts such as retry, logout, and check time can be provided on the login binding page.

[0091] In step S403, based on the login key pair generated by the login domain name, the login domain name signs the fourth access token.

[0092] Among them, the login key pair includes a second private key and a second public key.

[0093] In this step, the fourth payload can be signed with the second private key in the login key pair to generate a fourth signature, and then a JWT token can be generated using the second public key, the fourth payload, and the fourth signature as the fourth access token. Among them, the fourth payload can be constructed based on the requested HTTP method, the URL of the binding page, and the timestamp of the issuance of the fourth access token. In one implementation, the fourth access token can be issued under the login binding page.

[0094] In step S404, according to the third access token and the fourth access token, the certificate is issued under the login domain name based on the login key pair.

[0095] In this step, under the login domain name, the third access token and the fourth access token can be sent to the server, so that the server generates a certificate identifier in response to verifying that the business domain name is the preset business domain name of the target application according to the third access token and the fourth access token; receive the certificate identifier and the certificate issuance timestamp sent by the server; use the certificate identifier, the certificate issuance timestamp, the second public key, the first public key fingerprint of the public key of the business key pair, and the business domain name to create a Web token, and sign the Web token with the second private key under the login domain name to generate the certificate.

[0096] It should be noted that the certificate identifier can be received through the login binding page, and the Web token can be signed with the second private key under the login binding page to generate the certificate. After generating the certificate, the page can be redirected from the login binding page to the business intermediate page with the certificate, so that the certificate can be stored in the local storage space (such as Local Storage) corresponding to the business domain name on the business intermediate page. In this way, subsequent business request messages triggered based on the business domain name can carry the certificate to verify the legality of the business domain name through the certificate.

[0097] That is to say, for the resource access method provided by the present disclosure, after the client generates the certificate, it can carry the certificate and jump from the login domain name to the business domain name, and then store the certificate in the local storage space corresponding to the business domain name.

[0098] In addition, if the server returns a message indicating a binding failure (for example, when the server verifies that the business domain name is not the preset business domain name of the target application, the server will return a response message indicating a binding failure), the client can prompt the user through this login and binding page to guide the user to log in again. In another business scenario, during the process of signing the fourth access token based on the second private key in the login key pair on this login and binding page, if it is determined that the second private key does not exist in the index DB or the second private key has expired, the user can also be prompted on this login and binding page to guide the user to log in again.

[0099] As described above, the present disclosure can converge the logic of key pair generation, storage, update, and exception handling to a business intermediate page by adding a business intermediate page, so as to achieve mutual isolation from the upstream business. The business intermediate page refers to a page with the same domain name as the business page but a different path. That is, if the target application is a Web application, it can jump from the business page of the target application to the business intermediate page, and perform preset operations through the business intermediate page under this business domain name; where the preset operations include at least one of the following: generating the business key pair, storing the business key pair, storing the certificate, and handling signature verification exceptions.

[0100] Among them, for different exception situations, corresponding status codes are provided. In this way, the client can identify specific exception situations based on the status code and execute targeted exception handling strategies.

[0101] For example, the exception situations may include, for example, failure to obtain DPoP on the login page, the server fails to establish a binding relationship successfully, there is a business DPoP and the login DPoP is cleared, the key pairs of the first access token and the certificate are inconsistent, the absolute value of the difference between the signature time of the first access token and the current time exceeds a preset time threshold (i.e., timeout), and the signature of the first access token does not match the public key in the header file or the first access token has no signature, etc. For the situation where the key pairs of the first access token and the certificate are inconsistent, the corresponding exception handling strategy may be, for example, "go through the binding process"; for the exception situation where the absolute value of the difference between the signature time of the first access token and the current time exceeds the preset time threshold, the corresponding exception handling strategy may be, for example, "guide the user to check the time"; for the exception situation where the signature of the first access token does not match the public key in the header file or the first access token has no signature, the corresponding exception handling strategy may be, for example, "the current environment is abnormal, prompt that the header file has been rewritten". The above examples are only for illustration.

[0102] Figure 5 is according to Figure 1 shown in the flowchart of a resource access method according to the embodiments shown, asFigure 5 As shown, the method further includes the following steps: In step S104, in response to the target application being a mobile application, set the field value of at least one first preset field in the header of the request message to a default value, and / or set the field value of at least one second preset field in the payload of the access token carried in the request message to a default value.

[0103] Wherein, the request message includes the login request message and / or the resource access request message.

[0104] Considering the actual application scenario, the DPoP public protocol requires signature addition for each network request, and the DPoP token always includes Header and payload fields. The mobile network environment is relatively complex, and the volume of network requests may affect the interface response time, thereby affecting the user experience. In order to minimize the volume of network requests on the premise of verifying the access token, the present disclosure allows the omission of limited fields in the header of the request message.

[0105] In one embodiment, the field value of at least one first preset field in the header of the request message can be set to a default value. For example, the first preset field may include fields such as typ field, alg field, jwk.kty field, and jwk.crv field. Among them, the default value of the typ field can be "dpop+jwt", the default value of the alg field can be "ES256", the default value of the jwk.kty field can be "EC", and the default value of the jwk.crv field can be "P-256". In addition, the json hierarchical structure of the header of the request message itself needs to remain unchanged. After the above omission, when using ES256 and P256 as encryption algorithms, the header only contains two valid fields, jwk.x and jwk.y, which can compress the packet volume of the network request. At the same time, when the server deserializes the header, it only needs to specify the default value of the default field without making other changes.

[0106] In addition, considering that in scenarios such as cold start and page entry of the mobile client App, there may be a situation where a large number of network requests are sent simultaneously. If signature addition is performed independently for each request, it may have a greater impact on performance. Therefore, in another embodiment, the field value of at least one second preset field in the payload of the access token carried in the request message can be set to a default value, which can reduce the signature addition pressure on the mobile side.

[0107] Exemplarily, in a service scenario with high security level requirements, only the jti field in the payload of the access token can be omitted. The second preset field includes the jti field. In this way, when the server determines that the jti field is set to the default value, it can determine whether the interface signature verification passes based on the iat, htm, and htu fields. If the signature verification passes, and the iat time has not expired, and the network request also meets the restrictions of htm and htu, it is considered that the interface signature verification passes.

[0108] In a service scenario with low security level requirements, in addition to omitting the jti field in the payload of the access token, the htm field and the htu field can be further omitted. The second preset field includes the jti field, the htm field, and the htu field. In this scenario, when the server determines that both the htm field and the htu field are omitted, it can not judge the corresponding restrictions.

[0109] In an actual application scenario, the second preset field can be set according to actual business requirements (for example, configured through a server).

[0110] In another embodiment of the present disclosure, in order to further reduce the signature addition pressure on the mobile side, for multiple request messages with the same field values of the first preset specified field in the payload, the access tokens carried in the multiple request messages can be set to be the same.

[0111] Exemplarily, for multiple request messages with the same field values of the htm field and the htu field in the payload obtained within a preset time period (such as 2 seconds), the multiple request messages can reuse the same DPoP Token. The client can perform short-term memory caching for this situation to avoid frequent signature addition.

[0112] In step S105, if the at least one second preset field includes a second preset specified field, the access tokens carried in the request messages within the preset time period are set to be the same.

[0113] In a possible implementation manner of the present disclosure, in order to minimize the signature addition pressure on the client, in response to determining that the at least one second preset field to be omitted includes a second preset specified field, the request messages obtained within the preset time period can all carry the same access token. For example, the second preset specified field can include the htm field and the htu field.

[0114] Figure 6 It is a flowchart of a resource access method shown according to an exemplary embodiment. This method can be applied to a gateway device, which refers to a device located between the client and the server. As Figure 6 shown, the method includes the following steps: In step S601, a resource access request message sent by the client is received. The resource access request message includes a first access token and a session identifier. The first access token is an access token signed by the client based on the private key in the service key pair, and the service key pair is generated by the service domain name of the target application. The session identifier is the identifier of a session generated by the server based on the login request message sent by the client, and the login request message is used to request to log in to the target application.

[0115] Among them, the target application can be any application on the selected client, and the target application can be a mobile application or a Web application. In addition, the first access token refers to an access token signed by the client based on the private key in the service key pair, and the service key pair is generated by the service domain name of the target application, and the service domain name is the domain name of the current service page of the target application. The service key pair may include a first public key and a first private key. In this way, the first access token can be signed based on the first private key, and the first private key is set on the client and cannot be exported. The first public key is also carried in the first access token, and the gateway device can determine that the first access token is signed by its corresponding first private key through the first public key carried in the first access token. Since the first private key cannot be exported, it can be determined that the first access token comes from the service domain name.

[0116] The first access token, the second access token, the third access token, and the fourth access token involved in this disclosure can all be DPoP tokens.

[0117] The session identifier is the identifier of a session generated by the server based on the login request message sent by the client, and the login request message is used to request to log in to the target application. Among them, the server can be the authorization server corresponding to the target application (also referred to as the "Passport server"). The Passport server is a server used for authentication and authorization services, mainly used in online services to help developers manage and verify user identities. In response to the user logging in to the target application, the client can send a login request message to the authorization server, and the authorization server establishes a Session (i.e., a session) for the login request message. In this way, the system can determine the user identity through the Session.

[0118] In step S602, the client is authenticated according to the binding relationship pre-established by the server based on the first access token and the session identifier, and the binding relationship represents the binding relationship between the session and the trusted client of the target application.

[0119] Among them, the binding relationship may include the binding relationship between the second public key and the session established by the server for the login request message. Among them, the second public key refers to the public key in the login key pair, and the login key pair is generated by the login domain name of the target application. The binding relationship is established by the authorization server when the user requests to log in to the target application. Therefore, by default, the generation party of the second public key recorded in the binding relationship is the login domain name of the target application on the trusted client.

[0120] Figure 7 is based on Figure 6 The flowchart of a resource access method shown in the illustrated embodiment is as follows Figure 7 shown, step S602 includes the following sub-steps: In step S6021, send the session identifier to the server so that the server determines the public key information corresponding to the session based on the binding relationship according to the session identifier.

[0121] Among them, the public key information includes the second public key fingerprint stored in the session entity of the session. The second public key fingerprint is the public key fingerprint of the second public key. The second public key is the public key in the login key pair, and the login key pair is generated by the client based on the login domain name of the target application.

[0122] In step S6022, receive the public key information sent by the server.

[0123] In step S6023, authenticate the client according to the public key information and the first access token.

[0124] During the execution of this step, the first public key can be obtained from the first access token. The first public key is the public key in the service key pair; use the first public key to verify the signature of the first access token, and after the signature verification passes, verify whether the first public key is consistent with the second public key according to the second public key fingerprint; in response to the first public key being consistent with the second public key, determine that the authentication of the client passes.

[0125] Exemplarily, the gateway device can determine whether the first access token is issued by its corresponding first private key based on the first public key carried in the first access token. For example, if the signature verification of the first access token using the first public key passes, it indicates that the first access token is issued by its corresponding first private key. Since the first private key is generated by the service domain name and is not exportable on the client side, it can be determined that the first access token is issued by the service domain name. For the case where the target application is a mobile application, the login key pair generated by the login domain name of the target application can be the same as the service key pair generated by the service domain name. Therefore, for the case where the target application is a mobile application, if it is determined that the first public key is the same as the second public key in the login key pair, it indicates that the client using the first access token and the Session used to represent the user identity for logging in to the target application have the same private key. Furthermore, the identity of the client sending the resource access request message can be determined to be legal (i.e., the authentication of the client passes).

[0126] If the target application is a Web application, the resource access request message further includes a certificate issued by the login domain name of the target application. Considering that for Web applications, since the Web side cannot use index DB across domain names, that is, the content between different domain names cannot be shared. In an actual application scenario, the business page and the login page of the target application may use different domain names. The binding relationship stored in the server is the binding relationship between the public-private key pair generated by the login domain name and the session Session. For Web applications, it is necessary to solve the problem of how to bind the public-private key pair generated by the non-login page to the session Session. The present disclosure can extend the trust relationship from the login domain name to the service domain name through a certificate (Certificate) issued by the public-private key pair (i.e., the login key pair) generated by the login domain name.

[0127] In this way, during the execution of step S602, the identity of the client can be authenticated based on the first access token, the session identifier, and the certificate through the binding relationship pre-established by the server.

[0128] Figure 8 is a flowchart of a resource access method shown in the embodiments as Figure 6 shown. As Figure 8 shown, step S602 further includes the following sub-steps: In step S6024, the session identifier is sent to the server so that the server can determine the public key information corresponding to the session based on the session identifier and the binding relationship.

[0129] Among them, the public key information includes a second public key fingerprint stored in the session entity of the session. The second public key fingerprint is the public key fingerprint of a second public key, and the second public key is the public key in the login key pair. The login key pair is generated by the client based on the login domain name of the target application.

[0130] In step S6025, receive the public key information sent by the server.

[0131] In step S6026, authenticate the client according to the public key information, the first access token, and the certificate.

[0132] During the execution of this step, the second public key and the first public key fingerprint of the first public key in the service key pair can be obtained from the certificate; the first public key can be obtained from the first access token; in response to the first public key fingerprint matching the first public key and the second public key fingerprint matching the second public key, it is determined that the authentication of the client is passed.

[0133] Among them, the certificate is created by the client under the login domain name by using the certificate identifier sent by the server, the certificate issuance timestamp, the second public key, the first public key fingerprint of the public key of the service key pair, and the service domain name, and the Web token is signed with the second private key under the login domain name. The gateway device can authenticate the client by performing the following steps: 1. After receiving the resource access request message, the gateway device can read the first access token and the certificate from the header of the resource access request message, and read the session identifier from the resource access request message. Then, based on the first public key carried in the first access token, it can be determined whether the first access token is signed by its corresponding first private key. If it is determined that the first access token is signed by its corresponding first private key, since the first private key cannot be exported, it can be determined that the first access token comes from the service domain name itself.

[0134] 2. The gateway device can determine whether the certificate is signed by its corresponding second private key through the second public key carried in the certificate. If it is determined that the certificate is signed by its corresponding second private key, since the private key cannot be exported, it can be determined that the second public key carried in the certificate is trustworthy.

[0135] 3. The gateway device can determine whether the second public key in the certificate comes from the login domain name that issued the session (that is, whether the second public key fingerprint matches the second public key in the certificate) based on the obtained second public key fingerprint. If the second public key in the certificate comes from the login domain name that issued the session, it is determined that the certificate itself is trustworthy.

[0136] 4. The gateway device can report the certificate identifier to the risk control system and at the same time confirm whether the field value of the iat field is within the preset validity period, so as to judge the validity of the certificate.

[0137] 5. The gateway device can judge whether the first public key carried in the first access token is trusted through the first public key fingerprint in the certificate (that is, if the first public key fingerprint matches the first public key, confirm that the first public key carried in the first access token is trusted).

[0138] 6. The gateway device can also judge whether the first access token is valid under the current resource access request through the issuance time, token identifier, request method, etc. of the first access token.

[0139] If the gateway device determines that the above several verification steps all pass the verification, the identity authentication of the client passes.

[0140] In step S603, in response to the successful authentication of the client, request the business resources of the target application based on the resource access request message.

[0141] In this step, the gateway device can send the resource access request message to the business server to access the business resources of the target application from the business server. In this way, the purpose of Session anti-theft can be achieved, and the security of data access to the business resources of the target application can be improved.

[0142] By adopting the above method, the gateway device receives the resource access request message corresponding to the target application sent by the client. The resource access request message includes the first access token signed by the private key in the business key pair by the client, and the session identifier of the session Session generated by the server based on the login request message sent by the client. In this way, the gateway device can authenticate the client according to the binding relationship pre-established by the server through the first access token and the session identifier. Since the binding relationship represents the binding relationship between the session Session and the trusted client of the target application, if the authentication of the client based on the binding relationship passes, it can be confirmed that the client sending the resource access request message also belongs to the trusted client, thus realizing Session anti-theft. In response to the successful authentication of the client, request the business resources of the target application based on the resource access request message, which can improve the security of business data.

[0143] Figure 9 It is a flowchart of a resource access method shown according to an exemplary embodiment, and this method can be applied to a server. As Figure 9 shown, this method includes the following steps: In step S901, a session identifier sent by a gateway device is received. The session identifier is an identifier included in a resource access request message sent by a client to the gateway device. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client. The login request message is used to request to log in to a target application. The resource access request message further includes a first access token. The first access token is an access token signed by the client based on the private key in a service key pair. The service key pair is generated by the service domain name of the target application.

[0144] Among them, the target application can be any application program on the client selected by the user, and the target application can be a mobile application or a Web application. In addition, the first access token refers to an access token signed by the client based on the private key in a service key pair. The service key pair is generated by the service domain name of the target application. The service domain name is the domain name of the current service page of the target application. The service key pair may include a first public key and a first private key. In this way, the first access token can be signed based on the first private key, and the first private key is set on the client and cannot be exported. The first access token also carries the first public key. The gateway device can determine that the first access token is signed by its corresponding first private key through the first public key carried in the first access token. Since the first private key cannot be exported, it can be determined that the first access token comes from the service domain name.

[0145] The session identifier is an identifier of a session generated by the server based on a login request message sent by the client. The login request message is used to request to log in to the target application. Among them, the server can be the authorization server corresponding to the target application (also called the "Passport server"). The Passport server is a server used for authentication and authorization services, mainly used in online services to help developers manage and verify user identities. In response to the user logging in to the target application, the client can send a login request message to the authorization server. The authorization server establishes a Session (i.e., a session) for the login request message. In this way, the system can determine the user identity through the Session.

[0146] In step S902, according to the session identifier, the public key information corresponding to the session is determined through a binding relationship. The binding relationship represents the binding relationship between the session and the trusted client of the target application.

[0147] In this step, the session entity corresponding to the session identifier can be determined based on the binding relationship; the public key information is read from the session entity. Among them, the public key information includes a second public key fingerprint. The second public key fingerprint is the public key fingerprint of a second public key. The second public key is the public key in a login key pair. The login key pair is generated by the login domain name of the target application.

[0148] In step S903, send the public key information to the gateway device so that the gateway device authenticates the client according to the public key information and the first access token.

[0149] Figure 10 is based on Figure 9 shown in the embodiments, a flowchart of a resource access method. In the present disclosure, the server may establish the binding relationship based on Figure 10 the steps S904 - S905 shown. As Figure 10 shown, the method further includes the following steps: In step S904, receive a login request message for the target application sent by the client. The login request message includes a second access token, and the second access token is an access token signed by the client based on the private key in the login key pair, and the login key pair is generated by the login domain name of the target application.

[0150] In step S905, establish the binding relationship based on the second access token.

[0151] In this step, the second public key may be determined according to the second access token, and the second public key is the public key in the login key pair; use the second public key to verify the second access token; after the verification of the second access token passes, record the second public key fingerprint of the second public key in the session entity of the login request message. By recording the second public key fingerprint of the second public key in the session entity, the binding relationship between the second public key and the session can be established.

[0152] Figure 11 is based on Figure 9 shown in the embodiments, a flowchart of a resource access method. As Figure 11 shown, the method further includes the following steps: In step S906, receive a third access token and a fourth access token sent by the client. The third access token is an access token signed by the client using the private key in the service key pair under the service domain name, and the fourth access token is an access token signed by the client based on the private key in the login key pair generated by the login domain name of the target application under the login domain name of the target application.

[0153] In step S907, in response to verifying that the service domain name is the preset service domain name of the target application according to the third access token and the fourth access token, generate a certificate identifier.

[0154] In step S908, the certificate identifier and the certificate issuance timestamp are sent to the client, so that the client generates a certificate based on the certificate identifier and the certificate issuance timestamp. In response to the target application being a Web application, the certificate is used to authenticate whether the business domain name is trustworthy.

[0155] Using the above method, after receiving the session identifier sent by the gateway device, the server can determine the public key information corresponding to the session according to the session identifier through the binding relationship, and send the binding relationship to the gateway device. The binding relationship represents the binding relationship between the session and the trusted client of the target application. In this way, the gateway device can authenticate the identity of the client according to the first access token and the session identifier through the binding relationship pre-established by the server. Since the binding relationship represents the binding relationship between the session and the trusted client of the target application, if the identity authentication of the client is passed based on the binding relationship, it can be confirmed that the client sending the resource access request message also belongs to the trusted client, thus realizing Session anti-theft. In response to the identity authentication of the client being passed, the business resources of the target application are requested based on the resource access request message, which can improve the security of business data.

[0156] Figure 12 It is a block diagram of a resource access device shown according to an exemplary embodiment. The device can be applied to a client. As Figure 12 shown, the device includes: An obtaining module 1201, configured to obtain a resource access request message corresponding to a target application. The resource access request message includes a first access token and a session identifier. The first access token is an access token signed by the client based on the private key in the business key pair, and the business key pair is generated by the business domain name of the target application. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to the target application; A first sending module 1202, configured to send the resource access request message to a gateway device, so that the gateway device authenticates the identity of the client according to the first access token and the session identifier through a binding relationship pre-established by the server, and in response to the identity authentication of the client being passed, requests the business resources of the target application based on the resource access request message. The binding relationship represents the binding relationship between the session and the trusted client of the target application.

[0157] Optionally, the obtaining module 1201 is configured to, in response to obtaining a service request message for the target application, obtain the session identifier and the service key pair; generate the first access token according to the service key pair and the service request message; and generate the resource access request message after adding the session identifier and the first access token to the service request message.

[0158] Optionally, the service key pair includes a first public key and a first private key; The obtaining module 1201 is configured to construct a first payload according to the service request message; sign the first payload with the first private key to obtain a first signature; and generate the first access token according to the first public key, the first payload, and the first signature.

[0159] Optionally, the first sending module 1202 is further configured to, in response to obtaining a login request for the target application, send the login request message to the server according to the login request, where the login request message includes a second access token, so that the server establishes the binding relationship based on the second access token, and the second access token is an access token signed by the private key in the login key pair, and the login key pair is generated by the login domain name of the target application.

[0160] Optionally, the first sending module 1202 is configured to obtain the login key pair, where the login key pair includes a second private key and a second public key; generate the second access token according to the second private key, the second public key, and the login request; obtain the login request message after adding the second access token to the login request; and send the login request message to the server.

[0161] Optionally, the first sending module 1202 is configured to construct a second payload according to the login request; sign the second payload with the second private key to generate a second signature; and generate the second access token according to the second public key, the second payload, and the second signature.

[0162] Optionally, in response to the target application being a Web application, the resource access request message further includes a certificate issued by the login domain name of the target application; and the certificate is used to authenticate whether the service domain name is trustworthy.

[0163] Optionally, Figure 13 is a block diagram of a resource access device shown in the Figure 12 illustrated embodiment, as Figure 13 shown, the device further includes: a certificate issuing module 1203, configured to generate the certificate in the following manner: Sign a third access token with the private key in the business key pair generated using the business domain name; Carry the third access token and jump from the business domain name to the login domain name; Sign a fourth access token through the login domain name based on the login key pair generated by the login domain name; Based on the third access token and the fourth access token, sign the certificate under the login domain name based on the login key pair.

[0164] Optionally, the login key pair includes a second private key and a second public key; the certificate issuance module 1203 is configured to, under the login domain name, send the third access token and the fourth access token to the server, so that the server generates a certificate identifier in response to verifying that the business domain name is the preset business domain name of the target application according to the third access token and the fourth access token; receive the certificate identifier and the certificate issuance timestamp sent by the server; create a Web token using the certificate identifier, the certificate issuance timestamp, the second public key, the first public key fingerprint of the public key of the business key pair, and the business domain name, and generate the certificate after signing the Web token with the second private key under the login domain name.

[0165] Optionally, after generating the certificate, the certificate issuance module 1203 is further configured to carry the certificate and jump from the login domain name to the business domain name; store the certificate in the local storage space corresponding to the business domain name.

[0166] Optionally, Figure 14 is a block diagram of a resource access device shown according to Figure 13 the embodiment shown, as Figure 14 shown, the device further includes: A page jump module 1204, configured to, in response to the target application being a Web application, jump from the business page of the target application to a business intermediate page, where the business intermediate page is a page with the same domain name as the business page but a different path; perform a preset operation through the business intermediate page under the business domain name; where the preset operation includes at least one of the following: generating the business key pair, storing the business key pair, storing the certificate, and handling the signature verification exception situation.

[0167] Optionally, Figure 15 is a block diagram of a resource access device shown according to Figure 12 the embodiment shown, as Figure 15 shown, the device further includes: A field setting module 1205, configured to, in response to the target application being a mobile application, set the field value of at least one first preset field in the header of the request message to a default value, and / or set the field value of at least one second preset field in the payload of the access token carried in the request message to a default value; wherein the request message includes the login request message and / or the resource access request message.

[0168] Optionally, for multiple request messages with the same field value of the first preset designated field in the payload, the access tokens carried in the multiple request messages are the same.

[0169] Optionally, the field setting module 1205 is further configured to, if at least one of the second preset fields includes a second preset designated field, set the access tokens carried in the request messages within a preset time period to be the same.

[0170] Figure 16 It is a block diagram of a resource access device shown according to an exemplary embodiment. This device can be applied to a gateway device. As Figure 16 shown, the device includes: A first receiving module 1301, configured to receive a resource access request message sent by a client. The resource access request message includes a first access token and a session identifier. The first access token is an access token signed by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of the target application. The session identifier is an identifier of a session generated by the server based on the login request message sent by the client, and the login request message is used to request to log in to the target application. An authentication module 1302, configured to authenticate the identity of the client according to the binding relationship pre-established by the server based on the first access token and the session identifier. The binding relationship represents the binding relationship between the session and the trusted clients of the target application. A resource access module 1303, configured to, in response to successful authentication of the client, request the service resources of the target application based on the resource access request message.

[0171] Optionally, the authentication module 1302 is configured to send the session identifier to the server, so that the server determines the public key information corresponding to the session based on the session identifier according to the binding relationship; receive the public key information sent by the server; and authenticate the identity of the client according to the public key information and the first access token.

[0172] Optionally, the public key information includes a second public key fingerprint stored in the session entity of the session. The second public key fingerprint is the public key fingerprint of a second public key, and the second public key is the public key in the login key pair, where the login key pair is generated by the login domain name of the target application. The authentication module 1302 is configured to obtain a first public key from the first access token, where the first public key is the public key in the service key pair; verify the signature of the first access token using the first public key, and after the signature verification passes, verify whether the first public key is consistent with the second public key according to the second public key fingerprint; in response to the first public key being consistent with the second public key, determine that the identity authentication of the client passes.

[0173] Optionally, in response to the target application being a Web application, the resource access request message further includes a certificate issued by the login domain name of the target application. The authentication module 1302 is configured to authenticate the identity of the client according to the first access token, the session identifier, and the certificate through a binding relationship pre-established by the server.

[0174] Optionally, the authentication module 1302 is configured to send the session identifier to the server, so that the server determines the public key information corresponding to the session based on the binding relationship according to the session identifier; receive the public key information sent by the server; authenticate the identity of the client according to the public key information, the first access token, and the certificate.

[0175] Optionally, the public key information includes a second public key fingerprint stored in the session entity of the session. The second public key fingerprint is the public key fingerprint of a second public key, and the second public key is the public key in the login key pair, where the login key pair is generated by the login domain name of the target application. The authentication module 1302 is configured to obtain the second public key and the first public key fingerprint of the first public key in the service key pair from the certificate; obtain the first public key from the first access token; in response to the first public key fingerprint matching the first public key and the second public key fingerprint matching the second public key, determine that the identity authentication of the client passes.

[0176] Figure 17 is a block diagram of a resource access device shown according to an exemplary embodiment. The device can be applied to a server. As Figure 17 shown, the device includes: A second receiving module 1401, configured to receive a session identifier sent by a gateway device, where the session identifier is an identifier included in a resource access request message sent by a client to the gateway device, and the session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to a target application; the resource access request message further includes a first access token, and the first access token is an access token signed by the client based on a private key in a service key pair, and the service key pair is generated by a service domain name of the target application; A determining module 1402, configured to determine public key information corresponding to the session according to the session identifier through a binding relationship, where the binding relationship represents a binding relationship between the session and a trusted client of the target application; A second sending module 1403, configured to send the public key information to the gateway device, so that the gateway device authenticates the client according to the public key information and the first access token.

[0177] Optionally, the determining module 1402 is configured to determine a session entity of the session corresponding to the session identifier based on the binding relationship; read the public key information from the session entity, where the public key information includes a second public key fingerprint, and the second public key fingerprint is a public key fingerprint of a second public key, and the second public key is a public key in a login key pair, and the login key pair is generated by a login domain name of the target application.

[0178] Optionally, Figure 18 is a block diagram of a resource access device shown in the embodiment shown in Figure 17 , and the second receiving module 1401 is further configured to receive a login request message for the target application sent by the client, where the login request message includes a second access token, and the second access token is an access token signed by the client based on a private key in a login key pair, and the login key pair is generated by a login domain name of the target application; as Figure 18 shown, the device further includes a relationship establishing module 1404, configured to establish the binding relationship based on the second access token.

[0179] Optionally, the relationship establishing module 1404 is configured to determine a second public key according to the second access token, where the second public key is a public key in the login key pair; use the second public key to verify the second access token; and after the verification of the second access token passes, record the second public key fingerprint of the second public key in the session entity of the login request message.

[0180] Optionally, the second receiving module 1401 is further configured to receive a third access token and a fourth access token sent by the client, where the third access token is an access token signed by the client with the private key in the service key pair under the service domain name, and the fourth access token is an access token signed by the client with the private key in the login key pair generated based on the login domain name under the login domain name of the target application; in response to verifying that the service domain name is the preset service domain name of the target application according to the third access token and the fourth access token, generate a certificate identifier; send the certificate identifier and the certificate issuance timestamp to the client, so that the client generates a certificate according to the certificate identifier and the certificate issuance timestamp, and in response to the target application being a Web application, the certificate is used to authenticate whether the service domain name is trustworthy.

[0181] Reference is made below to Figure 19 , which shows a schematic structural diagram of an electronic device 1500 suitable for implementing embodiments of the present disclosure. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Tablet Computers), PMPs (Portable Multimedia Players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 19 The electronic device shown is only an example and should not impose any limitation on the functions and usage scope of the embodiments of the present disclosure.

[0182] As Figure 19 shown, the electronic device 1500 may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 1601, which may perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1502 or a program loaded from a storage device 1508 into a random access memory (RAM) 1503. In the RAM 1503, various programs and data required for the operation of the electronic device 1500 are also stored. The processing device 1501, the ROM 1502, and the RAM 1503 are connected to each other through a bus 1504. An input / output (I / O) interface 1505 is also connected to the bus 1504.

[0183] Generally, the following devices may be connected to the I / O interface 1505: an input device 1506 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 1507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1508 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1509. The communication device 1509 may allow the electronic device 1500 to communicate with other devices wirelessly or wiredly to exchange data. AlthoughFigure 19 An electronic device 1500 is shown with various devices, but it should be understood that it is not required to implement or have all the shown devices. Instead, more or fewer devices may be implemented or had.

[0184] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product that includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes program code for performing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication device 1509, or installed from the storage device 1508, or installed from the ROM 1502. When the computer program is executed by the processing device 1501, the above functions defined in the methods of the embodiments of the present disclosure are performed.

[0185] It should be noted that the computer-readable medium in the present disclosure can be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. And in the present disclosure, the computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, and the computer-readable signal medium can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0186] In some embodiments, the client and the server can communicate using any currently known or future-developed network protocol such as HTTP (HyperText Transfer Protocol), and can be interconnected with digital data communication in any form or medium (e.g., a communication network). Examples of communication networks include local area networks ("LANs"), wide area networks ("WANs"), the Internet (e.g., the Internet), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0187] The above computer-readable medium can be included in the above electronic device; or it can exist separately and not be assembled into the electronic device.

[0188] The above computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: obtain a resource access request message corresponding to a target application, the resource access request message including a first access token and a session identifier, the first access token being an access token issued by the client based on the private key in a service key pair, the service key pair being generated from the service domain name of the target application; the session identifier being an identifier of a session generated by the server based on a login request message sent by the client, the login request message being used to request login to the target application; send the resource access request message to a gateway device, so that the gateway device authenticates the client according to the first access token and the session identifier through a binding relationship pre-established by the server, and in response to successful authentication of the client, request the service resources of the target application based on the resource access request message; the binding relationship representing the binding relationship between the session and the trusted clients of the target application.

[0189] Alternatively, the above computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: receive a resource access request message sent by a client, the resource access request message including a first access token and a session identifier, the first access token being an access token issued by the client based on the private key in a service key pair, the service key pair being generated from the service domain name of the target application; the session identifier being an identifier of a session generated by the server based on a login request message sent by the client, the login request message being used to request login to the target application; authenticate the client according to the first access token and the session identifier through a binding relationship pre-established by the server, the binding relationship representing the binding relationship between the session and the trusted clients of the target application; and in response to successful authentication of the client, request the service resources of the target application based on the resource access request message.

[0190] Alternatively, the above computer-readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: receive a session identifier sent by a gateway device, where the session identifier is an identifier included in a resource access request message sent by a client to the gateway device, and the session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to a target application; the resource access request message further includes a first access token, where the first access token is an access token signed by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of the target application; determine public key information corresponding to the session according to the session identifier through a binding relationship, where the binding relationship represents the binding relationship between the session and a trusted client of the target application; and send the public key information to the gateway device so that the gateway device authenticates the client according to the public key information and the first access token.

[0191] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages or combinations thereof. The above programming languages include, but are not limited to, object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., by using an Internet service provider to connect through the Internet).

[0192] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a portion of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0193] The modules involved in the embodiments described in the present disclosure can be implemented in software or in hardware. Among them, the name of the module does not constitute a limitation on the module itself in some cases. For example, the acquisition module can also be described as "the module for acquiring a resource access request".

[0194] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that can be used include: Field Programmable Gate Arrays (FPGA), Application Specific Integrated Circuits (ASIC), Application Specific Standard Products (ASSP), System on a Chip (SOC), Complex Programmable Logic Devices (CPLD), and so on.

[0195] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM or Flash Memory), an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0196] According to one or more embodiments of the present disclosure, Example 1 provides a resource access method, which is applied to a client and includes: obtaining a resource access request message corresponding to a target application, where the resource access request message includes a first access token and a session identifier, the first access token is an access token issued by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of the target application; the session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to the target application; sending the resource access request message to a gateway device, so that the gateway device authenticates the client according to the first access token and the session identifier through a binding relationship pre-established by the server, and in response to successful authentication of the client, requests the service resources of the target application based on the resource access request message; the binding relationship represents the binding relationship between the session and a trusted client of the target application.

[0197] According to one or more embodiments of the present disclosure, Example 2 provides the method of Example 1, and the obtaining a resource access request message corresponding to a target application includes: in response to obtaining a service request message for the target application, obtaining the session identifier and the service key pair; generating the first access token according to the service key pair and the service request message; generating the resource access request message after adding the session identifier and the first access token to the service request message.

[0198] According to one or more embodiments of the present disclosure, Example 3 provides the method of Example 2, the service key pair includes a first public key and a first private key; the generating the first access token according to the service key pair and the service request message includes: constructing a first payload according to the service request message; signing the first payload with the first private key to obtain a first signature; generating the first access token according to the first public key, the first payload, and the first signature.

[0199] According to one or more embodiments of the present disclosure, Example 4 provides the method of Example 1, and the method further includes: In response to obtaining a login request for the target application, sending the login request message to the server according to the login request, where the login request message includes a second access token, so that the server establishes the binding relationship based on the second access token, and the second access token is an access token issued by the client based on the private key in a login key pair, and the login key pair is generated by the login domain name of the target application.

[0200] According to one or more embodiments of the present disclosure, Example 5 provides the method of Example 4. The sending of the login request message to the server according to the login request includes: Obtain the login key pair, where the login key pair includes a second private key and a second public key; Generate the second access token according to the second private key, the second public key, and the login request; After adding the second access token to the login request, obtain the login request message; Send the login request message to the server.

[0201] According to one or more embodiments of the present disclosure, Example 6 provides the method of Example 5. The generating of the second access token according to the second private key, the second public key, and the login request includes: Construct a second payload according to the login request; Sign the second payload with the second private key to generate a second signature; Generate the second access token according to the second public key, the second payload, and the second signature.

[0202] According to one or more embodiments of the present disclosure, Example 7 provides the method of any one of Examples 1-6. In response to the target application being a Web application, the resource access request message further includes a certificate issued by the login domain name of the target application; the certificate is used to authenticate whether the service domain name is trustworthy.

[0203] According to one or more embodiments of the present disclosure, Example 8 provides the method of Example 7. The client generates the certificate in the following manner: Sign a third access token with the private key in the service key pair generated using the service domain name; Carry the third access token and jump from the service domain name to the login domain name; Sign a fourth access token through the login domain name based on the login key pair generated by the login domain name; Sign the certificate under the login domain name based on the login key pair according to the third access token and the fourth access token.

[0204] According to one or more embodiments of the present disclosure, Example 9 provides the method of Example 8. The login key pair includes a second private key and a second public key; the signing of the certificate under the login domain name based on the login key pair according to the third access token and the fourth access token includes: Under the login domain name, send the third access token and the fourth access token to the server, so that the server generates a certificate identifier in response to verifying that the business domain name is the preset business domain name of the target application according to the third access token and the fourth access token; Receive the certificate identifier and the certificate issuance timestamp sent by the server; Create a Web token using the certificate identifier, the certificate issuance timestamp, the second public key, the first public key fingerprint of the public key of the business key pair, and the business domain name, and after signing the Web token with the second private key under the login domain name, generate the certificate.

[0205] According to one or more embodiments of the present disclosure, Example 10 provides the method of Example 8, and the method further includes: After generating the certificate, jump from the login domain name to the business domain name with the certificate; Store the certificate in the local storage space corresponding to the business domain name.

[0206] According to one or more embodiments of the present disclosure, Example 11 provides the method of Example 7, and the method further includes: In response to the target application being a Web application, jump from the business page of the target application to a business intermediate page, where the business intermediate page is a page with the same domain name as the business page but different paths; Under the business domain name, perform a preset operation through the business intermediate page; Wherein, the preset operation includes at least one of the following: Generate the business key pair, store the business key pair, store the certificate, and handle the signature verification exception situation.

[0207] According to one or more embodiments of the present disclosure, Example 12 provides the method of Example 1, and the method further includes: In response to the target application being a mobile application, set the field value of at least one first preset field in the header of the request message to a default value, and / or set the field value of at least one second preset field in the payload of the access token carried in the request message to a default value; Wherein, the request message includes the login request message and / or the resource access request message.

[0208] According to one or more embodiments of the present disclosure, Example 13 provides the method of Example 12, and the method further includes: For multiple request messages with the same field value of the first preset specified field in the payload, the access tokens carried in the multiple request messages are the same.

[0209] According to one or more embodiments of the present disclosure, Example 14 provides the method of Example 12, and the method further includes: If a second preset specified field is included in the at least one second preset field, set the access tokens carried by the request messages within a preset time period to be the same.

[0210] According to one or more embodiments of the present disclosure, Example 15 provides a resource access method applied to a gateway device, and the method includes: Receive a resource access request message sent by a client, where the resource access request message includes a first access token and a session identifier. The first access token is an access token signed by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of a target application; the session identifier is an identifier of a session generated by a server based on a login request message sent by the client, and the login request message is used to request to log in to the target application; Authenticate the client according to a binding relationship pre-established by the server based on the first access token and the session identifier, where the binding relationship represents the binding relationship between the session and a trusted client of the target application; In response to successful authentication of the client, request business resources of the target application based on the resource access request message.

[0211] According to one or more embodiments of the present disclosure, Example 16 provides the method of Example 15, and the authenticating the client according to the binding relationship pre-established by the server based on the first access token and the session identifier includes: Send the session identifier to the server so that the server determines public key information corresponding to the session based on the session identifier according to the binding relationship; Receive the public key information sent by the server; Authenticate the client according to the public key information and the first access token.

[0212] According to one or more embodiments of the present disclosure, Example 17 provides the method of Example 16, where the public key information includes a second public key fingerprint stored in a session entity of the session, the second public key fingerprint is a public key fingerprint of a second public key, and the second public key is a public key in a login key pair, and the login key pair is generated by the login domain name of the target application; The authenticating the client according to the public key information and the first access token includes: Obtain a first public key from the first access token, and the first public key is a public key in the service key pair; Verify the signature of the first access token using the first public key, and after the signature verification passes, verify whether the first public key is consistent with the second public key according to the second public key fingerprint; In response to the first public key being consistent with the second public key, determine that the authentication of the client has passed.

[0213] According to one or more embodiments of the present disclosure, Example 18 provides the method of Example 15. In response to the target application being a Web application, the resource access request message further includes a certificate issued by the login domain name of the target application; The authenticating the client according to the binding relationship pre-established by the server through the first access token and the session identifier includes: Authenticate the client according to the binding relationship pre-established by the server through the first access token, the session identifier, and the certificate.

[0214] According to one or more embodiments of the present disclosure, Example 19 provides the method of Example 18. The authenticating the client according to the binding relationship pre-established by the server through the first access token, the session identifier, and the certificate includes: Send the session identifier to the server so that the server determines the public key information corresponding to the session based on the binding relationship according to the session identifier; Receive the public key information sent by the server; Authenticate the client according to the public key information, the first access token, and the certificate.

[0215] According to one or more embodiments of the present disclosure, Example 20 provides the method of Example 19. The public key information includes the second public key fingerprint stored in the session entity of the session. The second public key fingerprint is the public key fingerprint of the second public key, and the second public key is the public key in the login key pair, and the login key pair is generated by the login domain name of the target application; The authenticating the client according to the public key information, the first access token, and the certificate includes: Obtain the second public key and the first public key fingerprint of the first public key in the service key pair from the certificate; Obtain the first public key from the first access token; In response to the first public key fingerprint matching the first public key and the second public key fingerprint matching the second public key, determine that the authentication of the client has passed.

[0216] According to one or more embodiments of the present disclosure, Example 21 provides a resource access method applied to a server. The method includes: Receiving a session identifier sent by a gateway device. The session identifier is an identifier included in a resource access request message sent by a client to the gateway device. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to a target application. The resource access request message further includes a first access token, and the first access token is an access token signed by the client based on a private key in a service key pair, and the service key pair is generated by a service domain name of the target application; Determining public key information corresponding to the session according to the session identifier through a binding relationship, where the binding relationship represents a binding relationship between the session and a trusted client of the target application; Sending the public key information to the gateway device so that the gateway device authenticates the client according to the public key information and the first access token.

[0217] According to one or more embodiments of the present disclosure, Example 22 provides the method of Example 21. The determining public key information corresponding to the session according to the session identifier through the binding relationship includes: Determining a session entity of the session corresponding to the session identifier based on the binding relationship; Reading the public key information from the session entity, where the public key information includes a second public key fingerprint, and the second public key fingerprint is a public key fingerprint of a second public key, and the second public key is a public key in a login key pair, and the login key pair is generated by a login domain name of the target application.

[0218] According to one or more embodiments of the present disclosure, Example 23 provides the method of Example 21. The method further includes: Receiving a login request message for the target application sent by the client. The login request message includes a second access token, and the second access token is an access token signed by the client based on a private key in a login key pair, and the login key pair is generated by a login domain name of the target application; Establishing the binding relationship based on the second access token.

[0219] According to one or more embodiments of the present disclosure, Example 24 provides the method of Example 23. The establishing the binding relationship based on the second access token includes: Determining a second public key according to the second access token, where the second public key is a public key in the login key pair; Verifying the second access token using the second public key; After the second access token is successfully verified, record the second public key fingerprint of the second public key in the session entity of the login request message.

[0220] According to one or more embodiments of the present disclosure, Example 25 provides the method of Example 21, the method further comprising: Receiving a third access token and a fourth access token sent by the client, wherein the third access token is an access token signed by the client using the private key in the service key pair under the service domain name, and the fourth access token is an access token signed by the client using the private key in the login key pair generated based on the login domain name under the login domain name of the target application; In response to verifying that the service domain name is the preset service domain name of the target application according to the third access token and the fourth access token, generating a certificate identifier; Sending the certificate identifier and the certificate issuance timestamp to the client, so that the client generates a certificate according to the certificate identifier and the certificate issuance timestamp, and in response to the target application being a Web application, the certificate is used to authenticate whether the service domain name is trustworthy.

[0221] According to one or more embodiments of the present disclosure, Example 26 provides a resource access device, which is applied to a client, and the device includes: An acquisition module, configured to acquire a resource access request message corresponding to a target application, where the resource access request message includes a first access token and a session identifier, the first access token is an access token signed by the client using the private key in the service key pair, and the service key pair is generated by the service domain name of the target application; the session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to the target application; A first sending module, configured to send the resource access request message to a gateway device, so that the gateway device authenticates the client according to a binding relationship pre-established by the server based on the first access token and the session identifier, and in response to successfully authenticating the client, request the service resource of the target application based on the resource access request message; the binding relationship represents the binding relationship between the session and the trusted client of the target application.

[0222] According to one or more embodiments of the present disclosure, Example 27 provides a resource access device, which is applied to a gateway device, and the device includes: A first receiving module, configured to receive a resource access request message sent by a client, where the resource access request message includes a first access token and a session identifier. The first access token is an access token signed by the client based on the private key in a service key pair, and the service key pair is generated by a service domain name of a target application. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to the target application. An authentication module, configured to authenticate the identity of the client according to the first access token and the session identifier through a binding relationship pre-established by the server. The binding relationship represents the binding relationship between the session and a trusted client of the target application. A resource access module, configured to, in response to successful authentication of the client, request business resources of the target application based on the resource access request message.

[0223] According to one or more embodiments of the present disclosure, Example 28 provides a resource access device applied to a server. The device includes: A second receiving module, configured to receive a session identifier sent by a gateway device. The session identifier is an identifier included in a resource access request message sent by a client to the gateway device. The session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request to log in to a target application. The resource access request message further includes a first access token, and the first access token is an access token signed by the client based on the private key in a service key pair, and the service key pair is generated by the service domain name of the target application. A determination module, configured to determine public key information corresponding to the session according to the session identifier through a binding relationship. The binding relationship represents the binding relationship between the session and a trusted client of the target application. A second sending module, configured to send the public key information to the gateway device so that the gateway device authenticates the identity of the client according to the public key information and the first access token.

[0224] According to one or more embodiments of the present disclosure, Example 29 provides a computer-readable medium, on which a computer program is stored. When the computer program is executed by a processing device, the steps of the method described in any one of Examples 1-14 or 15-20 or 21-25 are implemented.

[0225] According to one or more embodiments of the present disclosure, Example 30 provides an electronic device, including: A storage device, on which a computer program is stored; A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of Examples 1-14 or 15-20 or 21-25.

[0226] According to one or more embodiments of the present disclosure, Example 31 provides a computer program product including a computer program which, when executed by a processor, implements the steps of the method according to any one of Examples 1-14 or 15-20 or 21-25.

[0227] The above description is only a preferred embodiment of the present disclosure and an illustration of the applied technical principles. Those skilled in the art should understand that the scope of the disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above technical features, and should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosure concept. For example, the technical solutions formed by mutually replacing the above features with the technical features (but not limited to) having similar functions disclosed in the present disclosure.

[0228] In addition, although the operations are depicted in a particular order, this should not be construed as requiring that the operations be performed in the particular order shown or in sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the present disclosure. Certain features described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0229] Although the subject matter has been described in language specific to structural features and / or methodological logical acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. On the contrary, the specific features and acts described above are merely example forms for implementing the claims. Regarding the device in the above embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method, and will not be elaborated herein.

Claims

1. A resource access method, characterized in that: Applied to a client, the method comprises: Obtain a resource access request message corresponding to the target application, the resource access request message including a first access token and a session identifier, the first access token being an access token issued by the client based on a private key in a business key pair, the business key pair being generated by a business domain name of the target application; the session identifier being an identifier of a session generated by the server based on a login request message sent by the client, the login request message being used to request login to the target application; The resource access request message is sent to a gateway device, so that the gateway device authenticates the client according to the first access token and the session identifier through the binding relationship pre-established by the server, and in response to the identity authentication of the client, requests the business resources of the target application based on the resource access request message; the binding relationship represents the binding relationship between the session and the trusted client of the target application.

2. The method according to claim 1, characterized in that The obtaining of the resource access request message corresponding to the target application includes: In response to obtaining a service request message for the target application, obtaining the session identifier and the service key pair; Generate the first access token according to the business key pair and the business request message; After adding the session identifier and the first access token to the service request message, the resource access request message is generated.

3. The method according to claim 2, characterized in that The business key pair includes a first public key and a first private key; The generating the first access token according to the service key pair and the service request message comprises: Constructing a first payload according to the service request message; Sign the first payload using the first private key to obtain a first signature; The first access token is generated according to the first public key, the first payload, and the first signature.

4. The method according to claim 1, characterized in that The method further comprises: In response to obtaining a login request for the target application, the login request message is sent to the server according to the login request, and the login request message includes a second access token, so that the server establishes the binding relationship based on the second access token, and the second access token is an access token issued by the client based on the private key in the login key pair, and the login key pair is generated by the login domain name of the target application.

5. The method according to claim 4, characterized in that The sending the login request message to the server according to the login request comprises: Acquire the login key pair, wherein the login key pair includes a second private key and a second public key; Generate the second access token according to the second private key, the second public key and the login request; After adding the second access token to the login request, obtaining the login request message; Sending the login request message to the server.

6. The method according to claim 5, characterized in that The generating the second access token according to the second private key, the second public key and the login request includes: constructing a second payload according to the login request; Sign the second payload using the second private key to generate a second signature; The second access token is generated according to the second public key, the second payload, and the second signature.

7. The method according to any one of claims 1 to 6, characterized in that: In response to the target application being a Web application, the resource access request message further includes a certificate issued by a login domain name of the target application; the certificate is used to authenticate whether the business domain name is credible.

8. The method according to claim 7, characterized in that The client generates the certificate in the following manner: Issue a third access token using the private key in the business key pair generated by the business domain name; Carrying the third access token, jumping from the business domain name to the login domain name; issuing a fourth access token based on a login key pair generated by the login domain name through the login domain name; The certificate is issued based on the login key pair under the login domain name according to the third access token and the fourth access token.

9. The method according to claim 8, characterized in that The login key pair includes a second private key and a second public key; The issuing of the certificate based on the login key pair under the login domain name according to the third access token and the fourth access token comprises: Under the login domain name, sending the third access token and the fourth access token to the server, so that the server generates a certificate identifier in response to verifying that the business domain name is a preset business domain name of the target application according to the third access token and the fourth access token; Receiving the certificate identification and certificate issuance timestamp sent by the server; A Web token is created using the certificate identifier, the certificate issuance timestamp, the second public key, the first public key fingerprint of the public key of the business key pair, and the business domain name, and the certificate is generated after the Web token is signed using the second private key under the login domain name.

10. The method according to claim 8, characterized in that The method further comprises: After generating the certificate, jump from the login domain name to the business domain name with the certificate; The certificate is stored in the local storage space corresponding to the business domain name.

11. The method according to claim 7, characterized in that The method further comprises: In response to the target application being a Web application, jumping from the business page of the target application to a business intermediate page, the business intermediate page being a page having the same domain name as the business page but a different path; Under the business domain name, perform preset operations through the business intermediate page; The preset operation includes at least one of the following: Generate the business key pair, store the business key pair, store the certificate, and handle abnormal signature verification situations.

12. The method according to claim 1, characterized in that The method further comprises: In response to the target application being a mobile application, setting a field value of at least one first preset field in a header of the request message to a default value, and / or setting a field value of at least one second preset field in a payload of an access token carried in the request message to a default value; The request message includes the login request message and / or the resource access request message.

13. The method according to claim 12, characterized in that The method further comprises: For multiple request messages having the same field value of the first preset designated field in the payload, the access tokens carried in the multiple request messages are the same.

14. The method according to claim 12, characterized in that The method further comprises: If the at least one second preset field includes a second preset designated field, the access tokens carried by the request messages within a preset time period are set to be the same.

15. A resource access method, characterized in that: Applied to a gateway device, the method comprises: Receive a resource access request message sent by a client, the resource access request message including a first access token and a session identifier, the first access token being an access token issued by the client based on a private key in a business key pair, the business key pair being generated by a business domain name of a target application; the session identifier being an identifier of a session generated by a server based on a login request message sent by the client, the login request message being used to request login to the target application; authenticating the client through a binding relationship pre-established by the server according to the first access token and the session identifier, wherein the binding relationship represents a binding relationship between the session and a trusted client of the target application; In response to the client being authenticated successfully, a service resource of the target application is requested based on the resource access request message.

16. The method according to claim 15, characterized in that The authenticating the client according to the first access token and the session identifier through the binding relationship pre-established by the server includes: Sending the session identifier to the server, so that the server determines the public key information corresponding to the session based on the binding relationship according to the session identifier; Receiving the public key information sent by the server; The client is authenticated according to the public key information and the first access token.

17. The method according to claim 16, characterized in that The public key information includes a second public key fingerprint stored in the session entity of the session, where the second public key fingerprint is a public key fingerprint of a second public key, where the second public key is a public key in a login key pair, where the login key pair is generated by a login domain name of the target application; The authenticating the client according to the public key information and the first access token includes: Acquire a first public key from the first access token, where the first public key is a public key in the business key pair; Use the first public key to verify the signature of the first access token, and after the signature verification is passed, verify whether the first public key is consistent with the second public key according to the second public key fingerprint; In response to the first public key being consistent with the second public key, it is determined that the identity authentication of the client is successful.

18. The method according to claim 15, characterized in that In response to the target application being a Web application, the resource access request message further includes a certificate issued by a login domain name of the target application; The authenticating the client according to the first access token and the session identifier through the binding relationship pre-established by the server includes: According to the first access token, the session identifier and the certificate, the client is authenticated through the binding relationship pre-established by the server.

19. The method according to claim 18, characterized in that The performing identity authentication on the client according to the first access token, the session identifier and the certificate through the binding relationship pre-established by the server includes: Sending the session identifier to the server, so that the server determines the public key information corresponding to the session based on the binding relationship according to the session identifier; Receiving the public key information sent by the server; The client is authenticated according to the public key information, the first access token and the certificate.

20. The method according to claim 19, characterized in that The public key information includes a second public key fingerprint stored in the session entity of the session, where the second public key fingerprint is a public key fingerprint of a second public key, where the second public key is a public key in a login key pair, where the login key pair is generated by a login domain name of the target application; The performing identity authentication on the client according to the public key information, the first access token and the certificate comprises: Obtaining the second public key and a first public key fingerprint of the first public key in the business key pair from the certificate; Obtaining the first public key from the first access token; In response to the first public key fingerprint matching the first public key, and the second public key fingerprint matching the second public key, it is determined that the identity authentication of the client is successful.

21. A resource access method, characterized in that: Applied to a server, the method comprises: Receive a session identifier sent by a gateway device, wherein the session identifier is an identifier included in a resource access request message sent by a client to the gateway device, and the session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request login to a target application; the resource access request message also includes a first access token, and the first access token is an access token issued by the client based on a private key in a business key pair, and the business key pair is generated by a business domain name of the target application; Determining the public key information corresponding to the session through a binding relationship according to the session identifier, wherein the binding relationship represents a binding relationship between the session and a trusted client of the target application; The public key information is sent to the gateway device so that the gateway device performs identity authentication on the client according to the public key information and the first access token.

22. The method according to claim 21, characterized in that Determining the public key information corresponding to the session through a binding relationship according to the session identifier includes: Determine a session entity of the session corresponding to the session identifier based on the binding relationship; The public key information is read from the session entity, wherein the public key information includes a second public key fingerprint, the second public key fingerprint is a public key fingerprint of a second public key, the second public key is a public key in a login key pair, and the login key pair is generated by a login domain name of the target application.

23. The method according to claim 21, characterized in that The method further comprises: Receive a login request message for the target application sent by a client, wherein the login request message includes a second access token, where the second access token is an access token issued by the client based on a private key in a login key pair, and the login key pair is generated by a login domain name of the target application; The binding relationship is established based on the second access token.

24. The method according to claim 23, characterized in that The establishing the binding relationship based on the second access token comprises: Determine a second public key according to the second access token, where the second public key is a public key in the login key pair; Verify the second access token using the second public key; After the second access token is verified, the second public key fingerprint of the second public key is recorded in the session entity of the login request message.

25. The method according to claim 21, characterized in that The method further comprises: Receive a third access token and a fourth access token sent by the client, wherein the third access token is an access token issued by the client under the business domain name using the private key in the business key pair, and the fourth access token is an access token issued by the client under the login domain name of the target application based on the private key in the login key pair generated by the login domain name; In response to verifying that the business domain name is a preset business domain name of the target application according to the third access token and the fourth access token, generating a certificate identifier; The certificate identifier and the certificate issuance timestamp are sent to the client so that the client generates a certificate according to the certificate identifier and the certificate issuance timestamp. In response to the target application being a Web application, the certificate is used to authenticate whether the business domain name is credible.

26. A resource access device, characterized in that: Applied to a client, the device comprises: An acquisition module is used to acquire a resource access request message corresponding to a target application, wherein the resource access request message includes a first access token and a session identifier, wherein the first access token is an access token issued by the client based on a private key in a business key pair, wherein the business key pair is generated by a business domain name of the target application; the session identifier is an identifier of a session generated by a server based on a login request message sent by the client, wherein the login request message is used to request to log in to the target application; The first sending module is used to send the resource access request message to the gateway device, so that the gateway device authenticates the client according to the first access token and the session identifier through the binding relationship pre-established by the server, and in response to the identity authentication of the client, requests the business resources of the target application based on the resource access request message; the binding relationship represents the binding relationship between the session and the trusted client of the target application.

27. A resource access device, characterized in that: Applied to a gateway device, the device comprises: A first receiving module is used to receive a resource access request message sent by a client, wherein the resource access request message includes a first access token and a session identifier, wherein the first access token is an access token issued by the client based on a private key in a business key pair, and the business key pair is generated by a business domain name of a target application; the session identifier is an identifier of a session generated by a server based on a login request message sent by the client, and the login request message is used to request to log in to the target application; an authentication module, configured to authenticate the client according to the first access token and the session identifier through a binding relationship pre-established by the server, wherein the binding relationship represents a binding relationship between the session and a trusted client of the target application; The resource access module is used to request the service resources of the target application based on the resource access request message in response to the identity authentication of the client.

28. A resource access device, characterized in that: Applied to a server, the device comprises: A second receiving module is configured to receive a session identifier sent by a gateway device, wherein the session identifier is an identifier included in a resource access request message sent by a client to a gateway device, and the session identifier is an identifier of a session generated by the server based on a login request message sent by the client, and the login request message is used to request login to a target application; the resource access request message also includes a first access token, and the first access token is an access token issued by the client based on a private key in a business key pair, and the business key pair is generated by a business domain name of the target application; A determination module, configured to determine the public key information corresponding to the session through a binding relationship according to the session identifier, wherein the binding relationship represents a binding relationship between the session and a trusted client of the target application; The second sending module is used to send the public key information to the gateway device, so that the gateway device can authenticate the client according to the public key information and the first access token.

29. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processing device, the steps of the method described in any one of claims 1-14 or 15-20 or 21-25 are implemented.

30. An electronic device, characterized in that: include: a storage device having a computer program stored thereon; A processing device, used to execute the computer program in the storage device to implement the steps of the method in any one of claims 1-14 or 15-20 or 21-25.

31. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method described in any one of claims 1-14, 15-20 or 21-25 are implemented.

Images