Secure access methods, devices, media, electronic equipment, and software products for resources

Abstract

A resource access method, apparatus, readable medium, electronic device, and program product are disclosed. This relates to the field of information security technology. A client sends a resource access request message for a target application to a gateway device. This resource access request message includes a first access token issued by the client based on the private key in a business key pair, and a session identifier generated by the server based on a login request message sent by the client. The gateway device then authenticates the client based on the first access token and the session identifier through a pre-established binding relationship on the server. Upon successful authentication, the gateway device requests business resources of the target application based on the resource access request message. The binding relationship represents the relationship between the session and a trusted client of the target application. Based on this binding relationship, it can be confirmed that the client sending the resource access request message is a trusted client, thereby preventing session theft and improving the security of business data.

Description

Technical Field

[0001] This disclosure relates to the field of information security technology, and more specifically, to a method, apparatus, medium, electronic device, and program product for secure access to resources. Background Technology

[0002] A session, as one of the core data sets of a system, serves as a unique credential identifying a user's login state. The system uses sessions to verify a user's identity. If a session is compromised, the corresponding account identity will also be taken over, allowing attackers to bypass the authentication process before the session and directly access core system resources, such as enterprise documents. This clearly poses a threat to enterprise data security. Therefore, how to prevent session theft is a pressing issue in this field. Summary of the Invention

[0003] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0004] In a first aspect, this disclosure provides a secure access method for resources, applied to a client, the method comprising:

[0005] 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 business key pair. The business key pair is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application.

[0006] The resource access request message is sent to the gateway device, so that the gateway device authenticates the client based on the first access token and session identifier through the binding relationship pre-established by the server, and in response to the client's successful authentication, 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.

[0007] Secondly, this disclosure provides a secure access method for resources, applied to a gateway device, the method comprising:

[0008] The server receives 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 issued by the client based on the private key in a business key pair, which 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. The login request message is used to request login to the target application.

[0009] The client is authenticated based on the first access token and session identifier through a pre-established binding relationship on the server. The binding relationship represents the binding relationship between the session and a trusted client of the target application.

[0010] In response to successful authentication of the client, the system requests the target application's business resources based on the resource access request message.

[0011] Thirdly, this disclosure provides a secure access method for resources, applied to a server, the method comprising:

[0012] The server receives a session identifier sent by the gateway device. The session identifier is an identifier contained in a resource access request message sent by the client to the gateway device. The session identifier is an identifier of the session generated by the server based on a login request message sent by the client. The login request message is used to request login to the target application. The resource access request message also includes a first access token, which is an access token issued by the client based on the private key in the business key pair. The business key pair is generated by the business domain name of the target application.

[0013] The public key information corresponding to the session is determined through the binding relationship based on the session identifier, and the binding relationship represents the binding relationship between the session and the trusted client of the target application;

[0014] The public key information is sent to the gateway device so that the gateway device can authenticate the client based on the public key information and the first access token.

[0015] Fourthly, this disclosure provides a secure access device for resources, applied to a client, the device comprising:

[0016] The acquisition module is used to acquire 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 business key pair. The business key pair is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application.

[0017] The first sending module is configured to send the resource access request message to the gateway device, so that the gateway device can authenticate the client based on the first access token and session identifier through the binding relationship pre-established by the server, and in response to the successful authentication of the client, request 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.

[0018] Fifthly, this disclosure provides a secure access device for resources, applied to a gateway device, the device comprising:

[0019] The first receiving module is used 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 issued by the client based on the private key in a business key pair. 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. The login request message is used to request login to the target application.

[0020] An authentication module is used to authenticate the client based on the first access token and session identifier through a pre-established binding relationship on the server, wherein the binding relationship represents the binding relationship between the session and a trusted client of the target application;

[0021] The resource access module is used to request the business resources of the target application based on the resource access request message in response to the client's successful authentication.

[0022] Sixthly, this disclosure provides a secure access device for resources, applied to a server, the device comprising:

[0023] The second receiving module is used to receive a session identifier sent by the gateway device. The session identifier is an identifier contained in a resource access request message sent by the client to the gateway device. The session identifier is an identifier of the session generated by the server based on a login request message sent by the client. The login request message is used to request login to the target application. The resource access request message also includes a first access token, which is an access token issued by the client based on the private key in the business key pair. The business key pair is generated by the business domain name of the target application.

[0024] The determination module is used to determine the public key information corresponding to the session based on the session identifier and the binding relationship, wherein the binding relationship represents the binding relationship between the session and the trusted client of the target application;

[0025] 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 based on the public key information and the first access token.

[0026] In a seventh aspect, this disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the methods described in any one of the first, second, and third aspects.

[0027] Eighthly, this disclosure provides an electronic device, comprising:

[0028] A storage device on which computer programs are stored;

[0029] A processing device for executing the computer program in the storage device to implement the steps of the method described in any one of the first, second, and third aspects.

[0030] Ninthly, this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods described in any one of the first, second, and third aspects.

[0031] Through the above technical solution, the client sends a resource access request message corresponding to the target application to the gateway device. This resource access request message includes a first access token issued by the client based on the private key in the business key pair, and a session identifier generated by the server based on the login request message sent by the client. The gateway device can authenticate the client based on the first access token and the session identifier through a pre-established binding relationship on the server. Since this binding relationship represents the binding relationship between the session and a trusted client of the target application, if the client's authentication based on this binding relationship is successful, it can be confirmed that the client sending the resource access request message is also a trusted client, thereby achieving session theft prevention. In response to successful client authentication, the client requests the business resources of the target application based on the resource access request message, which can improve the security of business data.

[0032] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0033] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale. In the drawings:

[0034] Figure 1 This is a flowchart illustrating a secure access method for a resource according to an exemplary embodiment.

[0035] Figure 2 It is based on Figure 1 The illustrated embodiment shows a flowchart of a secure access method for resources.

[0036] Figure 3 It is based on Figure 1 The illustrated embodiment shows a flowchart of a secure access method for resources.

[0037] Figure 4 This is a flowchart illustrating a certificate generation method according to an exemplary embodiment.

[0038] Figure 5 It is based on Figure 1 The illustrated embodiment shows a flowchart of a secure access method for resources.

[0039] Figure 6 This is a flowchart illustrating a secure access method for a resource according to an exemplary embodiment.

[0040] Figure 7 It is based on Figure 6The illustrated embodiment shows a flowchart of a secure access method for resources.

[0041] Figure 8 It is based on Figure 6 The illustrated embodiment shows a flowchart of a secure access method for resources.

[0042] Figure 9 This is a flowchart illustrating a secure access method for a resource according to an exemplary embodiment.

[0043] Figure 10 It is based on Figure 9 The illustrated embodiment shows a flowchart of a secure access method for resources.

[0044] Figure 11 It is based on Figure 9 The illustrated embodiment shows a flowchart of a secure access method for resources.

[0045] Figure 12 This is a block diagram illustrating a secure access device for a resource according to an exemplary embodiment.

[0046] Figure 13 It is based on Figure 12 The illustrated embodiment shows a block diagram of a secure access device for resources.

[0047] Figure 14 It is based on Figure 13 The illustrated embodiment shows a block diagram of a secure access device for resources.

[0048] Figure 15 It is based on Figure 12 The illustrated embodiment shows a block diagram of a secure access device for resources.

[0049] Figure 16 This is a block diagram illustrating a secure access device for a resource according to an exemplary embodiment.

[0050] Figure 17 This is a block diagram illustrating a secure access device for a resource according to an exemplary embodiment.

[0051] Figure 18 It is based on Figure 17 The illustrated embodiment shows a block diagram of a secure access device for resources.

[0052] Figure 19 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

[0053] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0054] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0055] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "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". Definitions of other terms will be given in the description below.

[0056] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0057] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0058] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0059] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0060] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0061] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0062] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0063] Meanwhile, it is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0064] This disclosure is primarily applied to Session theft prevention scenarios. When a user logs into a target application, they need to send a login request to the authorization server. The authorization server establishes a Session for this login request, and the system uses the Session to verify the user's identity. However, if the Session is stolen, the corresponding account identity will also be taken over, allowing attackers to skip the authentication steps before the Session and directly access the target application's business resources, thus affecting data security.

[0065] This disclosure utilizes the DPoP (Demonstrating Proof of Possession) mechanism to implement session theft prevention. DPoP describes a technique for cryptographically binding access tokens to a specific client when they are issued. Based on DPoP, applications using access tokens can be required to prove they possess the same private key used to obtain the token, thereby enhancing data access security. In other words, based on the DPoP mechanism, the sender of the DPoP token can be constrained through proof of possession of the public-private key pair, preventing unauthorized use of the token by a third party and thus enhancing security.

[0066] To achieve the above objectives, this disclosure provides a method, apparatus, medium, electronic device, and program product for secure access to resources. The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0067] Figure 1 This is a flowchart illustrating a secure access method for a resource according to an exemplary embodiment, which can be applied to a client. For example... Figure 1 As shown, the method includes the following steps:

[0068] In step S101, a resource access request message corresponding to the target application is obtained. 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 business key pair, which is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application.

[0069] The target application can be any application on the client selected by the user, and the target application can be a mobile application or a web application.

[0070] Typically, after logging into the target application, a user can access its business page. Users can then perform actions on this page based on their needs. In response, the client generates a business request message. This business page can hook into this request message using the integrated security SDK (Software Development Kit), and subsequently generate a resource access request message based on it. This resource access request message is the request message used to access the corresponding business resources of the target application.

[0071] Furthermore, the first access token refers to the access token issued by the client based on the private key in the business key pair. This business key pair is generated from the business domain name of the target application, which is the domain name of the current business page of the target application. The business key pair may include a first public key and a first private key. Thus, the first access token can be issued based on the first private key, which is set on the client and cannot be exported. The first access token also carries a first public key. The gateway device can determine that the first access token was 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 originates from the business domain name.

[0072] The first access token, as well as the second, third, and fourth access tokens mentioned later, can all be DPoP tokens (i.e., DPoP Tokens).

[0073] The session identifier is a session identifier generated by the server based on the login request message sent by the client, used to request login to the target application. This server can be the authorization server (also known as a "Passport server") corresponding to the target application. A Passport server is a server used for authentication and authorization services, primarily in online services, to help developers manage and verify user identities. In response to a user logging into the target application, the client can send a login request message to the authorization server. The authorization server establishes a session based on this login request message, allowing the system to determine the user's identity through the session.

[0074] In step S102, the resource access request message is sent to the gateway device so that the gateway device can authenticate the client based on the first access token and session identifier through the binding relationship pre-established by the server, and in response to the successful authentication of the client, request 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.

[0075] In this disclosure, the gateway device refers to the device located between the client and the server. The gateway device can be used to authenticate the client that sends the request message.

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

[0077] This binding relationship can include the binding between the second public key and the session established by the server in response to the login request message. The second public key refers to the public key in the login key pair, which is generated by the login domain of the target application. This binding relationship is established by the authorization server when a user requests to log in to the target application; therefore, by default, the generator of the second public key recorded in this binding relationship is the login domain of the target application on the trusted client.

[0078] The gateway device can obtain the public key corresponding to the private key used to issue the first access token, and obtain the second public key that is bound to the Session corresponding to the session identifier. The gateway device verifies the legitimacy of the client sending the resource access request message by comparing whether the public key corresponding to the private key used to issue the first access token and the second public key are consistent. It is understood that if the public key corresponding to the private key used to issue the first access token is consistent with the second public key, it indicates that the client using the first access token has the same private key as the Session used to identify the user logging into the target application. Since the private key is set on the client and cannot be exported, if the public key corresponding to the private key used to issue the first access token is consistent with the second public key, it indicates that the client sending the resource access request message is legitimate (i.e., the client's authentication has been successful).

[0079] Once the gateway device successfully authenticates the client, it can send the resource access request message to the business server corresponding to the target application, enabling access to the target application's business resources from that server. This achieves session theft prevention and enhances the security of data access to the target application's business resources.

[0080] Using the above method, the client sends a resource access request message corresponding to the target application to the gateway device. This resource access request message includes a first access token issued by the client based on the private key in the business key pair, and a session identifier generated by the server based on the login request message sent by the client. The gateway device can authenticate the client based on the first access token and the session identifier through a pre-established binding relationship on the server. Since this binding relationship represents the relationship between the session and a trusted client of the target application, successful authentication of the client based on this binding relationship ensures that the client sending the resource access request message is also a trusted client, thereby achieving session theft prevention. In other words, in response to successful client authentication, requesting the target application's business resources based on the resource access request message improves the security of business data.

[0081] Figure 2 It is based on Figure 1 The illustrated embodiment presents a flowchart of a secure access method for resources, as shown below. Figure 2 As shown, step S101 includes the following sub-steps:

[0082] In step S1011, in response to receiving a service request message for the target application, the session identifier and the service key pair are obtained.

[0083] The business key pair can be generated by the business page (or a business intermediary page, which shares the same domain name 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 a keystore). If the target application is a web application, it can be generated by the web cryptoAPI. Relevant infrastructure includes, for example, a device trusted credential management module based on a TEE (Trusted Execution Environment). A TEE refers to a device-specific secure storage space equipped with a hardware security chip. "Non-exportable private keys" can also be achieved through a TPM (Trusted Platform Module) or a hardware cryptographic machine. A TPM is a small chip that allows computers to use advanced security features, designed to protect hardware through integrated cryptographic keys.

[0084] The generated business key pair can be saved to the index database. This allows the business key pair to be retrieved from the index database during this step.

[0085] It should be noted that storing the public and private key pairs (including the business key pair and the login key pair mentioned later) in the index DB is done asynchronously. Since the index DB can persistently store data in the user's browser, storing the public and private key pairs in the index DB allows the client to obtain the previously generated public and private key pairs even after the user exits and reopens the browser.

[0086] Additionally, as mentioned above, the session identifier is generated by the server. The server can set the generated session identifier in a cookie and send it to the client for storage. In this way, the client can read the session identifier from the cookie.

[0087] In step S1012, the first access token is generated based on the service key pair and the service request message.

[0088] The business key pair includes a first public key and a first private key.

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

[0090] The payload is the data structured data carried in the business request message, resulting in structured data with different fields, which serves as the first payload. Common payload fields include "jti", "htm", "htu", "iat", and "nonce". "jti" is a unique identifier used to identify a specific DPoP token, preventing replay attacks. "htm" identifies the HTTP (Hypertext Transfer Protocol) method of the request. "htu" represents the target URL or resource address, ensuring the request is sent to the correct URL (Uniform Resource Locator). "iat" is a timestamp, indicating the issuance time of the corresponding access token, which the recipient can use to determine the token's validity, such as whether it has expired. "nonce" is a unique random string, typically used to prevent replay attacks. A new random nonce value is generated for each request to ensure each request is unique, helping the server identify and reject duplicate requests. It should be noted that "nonce" is an optional field. It is usually required to be included in the next request only when the server returns an error and carries a nonce. The nonce field can be a random string sent by the server when it reports an error, in order to prevent replay attacks.

[0091] After constructing the first payload, the first private key can be used to sign the first payload to obtain the first signature. Then, the first public key, the first payload, and the first signature are used to generate a JWT (JSON Web Token) as the first access token.

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

[0093] In this step, the first access token can be added to the header of the service request message, and the session identifier can be added to the end of the service request message to obtain the resource access request message.

[0094] Figure 3 It is based on Figure 1 The illustrated embodiment presents a flowchart of a secure access method for resources, as shown below. Figure 3 As shown, the method also includes:

[0095] In step S103, in response to receiving a login request for the target application, a login request message is sent to the server based on the login request. The login request message includes a second access token so that the server can establish the binding relationship based on the second access token. The second access token is an access token issued by the client based on the private key in the login key pair. The login key pair is generated by the login domain name of the target application.

[0096] The login domain name can be the domain name of the login page of the target application.

[0097] During this step, the login key pair, which includes a second private key and a second public key, can be obtained; based on the second private key, the second public key, and the login request, the second access token is generated; after adding the second access token to the login request, the login request message is obtained; and the login request message is sent to the server.

[0098] 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 non-exportable private key infrastructure (such as a keystore); if the target application is a web application, it can be generated by the web crypto API. The generated business key pair can be saved to the index database. This allows the login key pair to be retrieved from the index database. The login key pair may include a second public key and a second private key.

[0099] It's important to note that to prevent attackers from stealing public-private key pairs and allowing them to remain valid indefinitely, thus increasing the risk of data leakage, a public-private key pair refresh mechanism is necessary. For login pages, the login key pair needs to be refreshed in response to the user being logged in. For business pages, an expiration time for the business key pair can be set on the business interface. If the current time exceeds this expiration time (e.g., set to 1 day), a new business key pair needs to be generated.

[0100] After obtaining the login key pair, the second access token can be generated using the second private key, the second public key, and the login request in the following manner:

[0101] Construct a second payload based on the login request; use the second private key to sign the second payload to generate a second signature; generate the second access token based on the second public key, the second payload, and the second signature.

[0102] Here, the username, password, and other information recorded in the login request can be used to perform structured data processing 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 the second signature. Finally, the second public key, the second payload, and the second signature are used to generate a JWT token as the second access token.

[0103] After generating the second access token under the target application's login domain, the client can add this second access token to the login request header to obtain the login request message. The client then sends this login request message to the server, allowing the server to establish a binding relationship based on the second access token.

[0104] As mentioned above, the target application can include mobile applications or web applications. For web applications, since the web client cannot use the index database across domains, content cannot be shared between different domains. In practical application scenarios, the business pages and login pages of the target application may use different domains. The binding relationship stored on the server is the binding relationship between the public and private key pair generated by the login domain and the session. For web applications, it is necessary to solve the problem of how to bind the public and private key pair generated by non-login pages with the session. This disclosure can extend the trust relationship from the login domain to the business domain through a certificate issued by the public and private key pair (i.e., login key pair) generated by the login domain.

[0105] In this disclosure, in response to the target application being a web application, the resource access request message may also include a certificate issued by the login domain of the target application, which is used to authenticate whether the business domain is trustworthy.

[0106] Figure 4 This is a flowchart illustrating a certificate generation method according to an exemplary embodiment, such as... Figure 4 As shown, the client can generate the certificate through the following steps:

[0107] In step S401, a third access token is issued using the private key in the business key pair generated using the business domain name.

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

[0109] It should be noted that the business domain name generates its own private key (i.e., the first private key) that cannot be exported as a business key pair. By performing this step, the business domain name can use the private key in the business key pair to sign the third access token, which contains the public key (i.e., the first public key) in the business key pair.

[0110] In one possible implementation, this disclosure can consolidate the logic for key pair generation, storage, updating, and handling of exceptions into a new business intermediary page, thereby achieving isolation from upstream services. By decoupling from the service layer, the logic of the business intermediary page can be independently controlled, releases are not limited by the business side, and it facilitates handling some exceptions. For example, if there are anomalies in index DB read / write operations, the user can be notified on this business intermediary page. Furthermore, for example, notifications for signature verification failures due to DPoP can be displayed on this business intermediary page, without the upstream business needing to be aware of them, thus avoiding erroneous impact on the business side. In this way, the secure access method for this resource can be applied to architectures with multiple parallel business lines.

[0111] In this step, you can jump from the target application's business page to a business intermediary page, and then use the private key in the business key pair generated by the business domain name to issue a third access token on the business intermediary page.

[0112] In step S402, the third access token is carried and redirected from the business domain name to the login domain name.

[0113] In this step, the business domain can carry the third access token to the login domain on the business intermediate page, thereby attempting to establish a trust relationship with the server through the login domain.

[0114] This disclosure allows for the handling of public key binding for business domains by adding a login binding page under the login domain (i.e., the login domain). This login binding page is responsible for passing the third-party access token generated by the business domain to the server for binding. It can also process the binding results; for example, if the binding is successful, the certificate can be included in subsequent requests; if the binding fails, the login binding page can provide information such as retry, logout, and check time.

[0115] In step S403, a fourth access token is issued using the login key pair generated based on the login domain name.

[0116] The login key pair includes a second private key and a second public key.

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

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

[0119] In this step, the third access token and the fourth access token can be sent to the server under the login domain name, so that the server responds by verifying that the business domain name is the preset business domain name of the target application based on the third access token and the fourth access token, and generates a certificate identifier; receives the certificate identifier and certificate issuance timestamp sent by the server; uses 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 signs the Web token using the second private key under the login domain name to generate the certificate.

[0120] It should be noted that the certificate identifier can be received through the login binding page, and the Web token can be signed using the second private key on 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 intermediary page, 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 intermediary page. In this way, subsequent business request messages triggered based on the business domain name can carry the certificate to verify the legitimacy of the business domain name.

[0121] In other words, the secure access method for the resources provided in this disclosure allows the client to carry the certificate from the login domain to the business domain after generating the certificate, and then store the certificate in the local storage space corresponding to the business domain.

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

[0123] As described above, this disclosure allows for the consolidation of key pair generation, storage, updating, and anomaly handling logic into a new intermediate business page, thereby achieving isolation from upstream services. This intermediate business page refers to a page with the same domain name but a different path than the business page. In other words, if the target application is a web application, users can navigate from the target application's business page to the intermediate business page, where preset operations can be performed under that business domain. These 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 anomalies.

[0124] Different status codes correspond to different abnormal situations, allowing the client to identify specific abnormal situations based on the status code and execute targeted exception handling strategies.

[0125] For example, such exceptions may include: failure to obtain a DPoP on the login page; failure to establish a binding relationship on the server; the existence of a business DPoP, but the login DPoP being cleared; inconsistency between the key pair of the first access token and the key pair of the certificate; the absolute value of the difference between the signature time of the first access token and the current time exceeding a preset time threshold (i.e., timeout); and the first access token's signature not matching the public key in the header file, or the first access token not being signed. For the case where the key pair of the first access token does not match the key pair of the certificate, the corresponding exception handling strategy could be, for example, "proceeding with the binding process"; for the exception where the absolute value of the difference between the signature time of the first access token and the current time exceeds a preset time threshold, the corresponding exception handling strategy could be, for example, "guiding the user to check the time"; for the exception where the first access token's signature does not match the public key in the header file, or the first access token not being signed, the corresponding exception handling strategy could be, for example, "current environment is abnormal, indicating that the header file has been rewritten." The above examples are merely illustrative.

[0126] Figure 5 It is based on Figure 1 The illustrated embodiment presents a flowchart of a secure access method for resources, as shown below. Figure 5 As shown, the method also includes the following steps:

[0127] In step S104, in response to the target application being a mobile application, the field value of at least one first preset field in the header of the request message is set to a default value, and / or the field value of at least one second preset field in the payload of the access token carried in the request message is set to a default value.

[0128] The request message includes the login request message and / or the resource access request message.

[0129] Considering practical application scenarios, the DPoP public protocol requires each network request to be signed, and DPoP tokens always include Header and payload fields. Mobile network environments are complex, and the size of network requests can impact interface response time, thus affecting user experience. To minimize network request size while still verifying access tokens, this disclosure allows for the omission of a limited number of fields in the request message header.

[0130] In one embodiment, the values ​​of at least one first preset field in the header of the request message can be set to default values. For example, the first preset field may include a typ field, an alg field, ajwk.kty field, and a jwk.crv field. 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". Furthermore, the JSON hierarchy of the request message header itself must remain unchanged. After the above omissions, 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 size of the network request. Simultaneously, when the server deserializes the header, it only needs to specify the default values ​​of the default fields without making other modifications.

[0131] Furthermore, considering that mobile client apps may send a large number of network requests simultaneously during cold starts and page entry scenarios, signing each request independently could significantly impact performance. Therefore, in another embodiment, 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 signing burden on the mobile device.

[0132] For example, in business scenarios with high security requirements, the `jti` field in the access token payload can be omitted. This second preset field includes the `jti` field. Thus, when the server determines that the `jti` field is set to its default value, it can use the `iat`, `htm`, and `htu` fields to determine if the interface signature verification is successful. If the signature verification is successful, the `iat` time has not expired, and the network request also meets the restrictions of `htm` and `htu`, the interface signature verification is considered successful.

[0133] For business scenarios with low security requirements, in addition to omitting the `jti` field in the access token payload, the `htm` and `htu` fields can be further omitted. This second set of preset fields includes the `jti`, `htm`, and `htu` fields. In this scenario, the server response confirms that the `htm` and `htu` fields have been omitted, and does not need to check the corresponding restrictions.

[0134] In practical applications, this second preset field can be set according to actual business needs (e.g., configured via the server).

[0135] In another embodiment of this disclosure, in order to further reduce the signing pressure on the mobile terminal, the access tokens carried in multiple request messages with the same field value of the first preset specified field in the payload can be set to be the same.

[0136] For example, multiple request messages whose payloads contain the same values ​​for both the htm and htu fields within a preset time period (e.g., 2 seconds) can reuse the same DPoP token. Clients can implement short-term memory caching for this situation to avoid frequent signatures.

[0137] In step S105, if the at least one second preset field includes a second preset specified field, the access token carried by the request message located within the preset time period is set to be the same.

[0138] In one possible implementation of this disclosure, to minimize the signing pressure on the client, in response to determining that the at least one omitted second preset field includes a second preset specified field, the same access token can be carried for all request messages obtained within a preset time period. For example, the second preset specified field may include an htm field and an htu field.

[0139] Figure 6 This is a flowchart illustrating a secure access method for a resource according to an exemplary embodiment. This method can be applied to a gateway device, which is a device located between a client and a server. Figure 6 As shown, the method includes the following steps:

[0140] In step S601, a resource access request message sent by a 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 issued by the client based on the private key in the business key pair, which is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application.

[0141] The target application can be any application on the client selected by the user, and it can be a mobile application or a web application. Furthermore, the first access token refers to an access token issued by the client based on the private key in a business key pair. This business key pair is generated from the business domain name of the target application, which is the domain name of the current business page of the target application. The business key pair can include a first public key and a first private key, allowing the first access token to be issued based on the first private key, which is set on the client and cannot be exported. The first access token also carries a first public key. The gateway device can determine that the first access token was issued by its corresponding first private key through the first public key carried in the first access token. Since the first private key is not exportable, it can be determined that the first access token originates from the business domain name.

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

[0143] The session identifier is a session identifier generated by the server based on the login request message sent by the client, used to request login to the target application. This server can be the authorization server (also known as a "Passport server") corresponding to the target application. A Passport server is a server used for authentication and authorization services, primarily in online services, to help developers manage and verify user identities. In response to a user logging into the target application, the client can send a login request message to the authorization server. The authorization server establishes a session based on this login request message, allowing the system to determine the user's identity through the session.

[0144] In step S602, the client is authenticated based on the first access token and session identifier through a pre-established binding relationship on the server. This binding relationship represents the binding relationship between the session and the trusted client of the target application.

[0145] This binding relationship can include the binding between the second public key and the session established by the server in response to the login request message. The second public key refers to the public key in the login key pair, which is generated by the login domain of the target application. This binding relationship is established by the authorization server when a user requests to log in to the target application; therefore, by default, the generator of the second public key recorded in this binding relationship is the login domain of the target application on the trusted client.

[0146] Figure 7 It is based on Figure 6 The illustrated embodiment presents a flowchart of a secure access method for resources, as shown below. Figure 7 As shown, step S602 includes the following sub-steps:

[0147] In step S6021, 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 binding relationship according to the session identifier.

[0148] 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 the second public key. The second public key is the public key in the login key pair, which is generated by the client based on the login domain name of the target application.

[0149] In step S6022, the public key information sent by the server is received.

[0150] In step S6023, the client is authenticated based on the public key information and the first access token.

[0151] During this step, a first public key can be obtained from the first access token, which is the public key in the business key pair; the first public key is used to verify the signature of the first access token, and after the signature is verified, the first public key is verified to be consistent with the second public key fingerprint; in response to the first public key being consistent with the second public key, the authentication of the client is confirmed to be successful.

[0152] For example, the gateway device can determine whether the first access token was issued by its corresponding first private key using the first public key carried in the first access token. For instance, if the first access token is successfully verified using the first public key, it indicates that the first access token was issued by its corresponding first private key. Since the first private key is generated by the business domain name and is not exportable from the client, it can be determined that the first access token was issued by that business domain name. In 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 business key pair generated by the business domain name. Therefore, in 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 has the same private key as the Session used to identify the user's identity when logging into the target application. This allows it to be determined that the client sending the resource access request message is legitimate (i.e., the client's identity authentication is successful).

[0153] If the target application is a web application, the resource access request message also includes a certificate issued by the login domain of the target application. Considering that web applications cannot use index databases across domains (i.e., content cannot be shared between different domains), and in practical applications, the target application's business pages and login pages may use different domains, the binding relationship stored on the server is the binding relationship between the public / private key pair generated by the login domain and the session. For web applications, it is necessary to solve the problem of how to bind the public / private key pair generated by non-login pages to the session. This disclosure extends the trust relationship from the login domain to the business domain by using a certificate issued by a public / private key pair (i.e., login key pair) generated by the login domain.

[0154] Thus, during the execution of step S602, 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.

[0155] Figure 8 It is based on Figure 6 The illustrated embodiment presents a flowchart of a secure access method for resources, as shown below. Figure 8 As shown, step S602 further includes the following sub-steps:

[0156] 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 binding relationship according to the session identifier.

[0157] 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 the second public key. The second public key is the public key in the login key pair, which is generated by the client based on the login domain name of the target application.

[0158] In step S6025, the public key information sent by the server is received.

[0159] In step S6026, the client is authenticated based on the public key information, the first access token, and the certificate.

[0160] During this step, the second public key and the first public key fingerprint of the first public key in the business 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 client's identity authentication is successful.

[0161] The certificate is generated by the client under the login domain 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 business key pair, and the business domain to create a Web token, and then signing the Web token using the second private key under the login domain. The gateway device can authenticate the client's identity by performing the following steps:

[0162] 1. Upon 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 also 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 determine whether the first access token was issued by its corresponding first private key. If it is determined that the first access token was issued by its corresponding first private key, since the first private key cannot be derived, it can be determined that the first access token originated from the business domain name itself.

[0163] 2. The gateway device can determine whether the certificate was issued by its corresponding second private key by using the second public key carried in the certificate. If it is determined that the certificate was issued 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.

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

[0165] 4. The gateway device can report the certificate identifier to the risk control system and confirm whether the value of the iat field is within the preset validity period to determine the validity of the certificate.

[0166] 5. The gateway device can determine whether the first public key carried in the first access token is trusted by the first public key fingerprint in the certificate (that is, if the first public key fingerprint matches the first public key, the first public key carried in the first access token is confirmed to be trustworthy).

[0167] 6. The gateway device can also determine whether the first access token is valid under the current resource access request by using the issuance time, token identifier, request method, etc. of the first access token.

[0168] If the gateway device determines that all of the above verification steps have passed, then the client's identity authentication is successful.

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

[0170] In this step, the gateway device can send the resource access request message to the business server to access the target application's business resources. This serves as a session theft prevention measure, enhancing the security of data access to the target application's business resources.

[0171] Using the above method, the gateway device receives a resource access request message corresponding to the target application sent by the client. This resource access request message includes a first access token issued by the client based on the private key in the business key pair, and a session identifier generated by the server based on the login request message sent by the client. Thus, the gateway device can authenticate the client based on the first access token and the session identifier through a pre-established binding relationship on the server. Since this binding relationship represents the binding relationship between the session and a trusted client of the target application, if the client's authentication based on this binding relationship is successful, it can be confirmed that the client sending the resource access request message is also a trusted client, thereby achieving session theft prevention. In response to successful client authentication, the gateway device requests the business resources of the target application based on the resource access request message, which can improve the security of business data.

[0172] Figure 9 This is a flowchart illustrating a secure access method for a resource according to an exemplary embodiment, which can be applied to a server. For example... Figure 9 As shown, the method includes the following steps:

[0173] In step S901, a session identifier sent by the gateway device is received. This session identifier is an identifier contained in a resource access request message sent by the client to the gateway device. The session identifier is the identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application. The resource access request message also includes a first access token, which is an access token issued by the client based on the private key in the business key pair. The business key pair is generated by the business domain name of the target application.

[0174] The target application can be any application on the client selected by the user, and it can be a mobile application or a web application. Furthermore, the first access token refers to an access token issued by the client based on the private key in a business key pair. This business key pair is generated from the business domain name of the target application, which is the domain name of the current business page of the target application. The business key pair can include a first public key and a first private key, allowing the first access token to be issued based on the first private key, which is set on the client and cannot be exported. The first access token also carries a first public key. The gateway device can determine that the first access token was issued by its corresponding first private key through the first public key carried in the first access token. Since the first private key is not exportable, it can be determined that the first access token originates from the business domain name.

[0175] The session identifier is generated by the server based on the login request message sent by the client, which is used to request login to the target application. This server can be the authorization server (also known as a "Passport server") corresponding to the target application. A Passport server is a server used for authentication and authorization services, primarily in online services, to help developers manage and verify user identities. In response to a user logging into the target application, the client can send a login request message to the authorization server. The authorization server establishes a session based on this login request message, allowing the system to determine the user's identity through the session.

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

[0177] 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, wherein the public key information includes a second public key fingerprint, 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 login domain name of the target application.

[0178] In step S903, the public key information is sent to the gateway device so that the gateway device can authenticate the client based on the public key information and the first access token.

[0179] Figure 10 It is based on Figure 9 The illustrated embodiment presents a flowchart of a secure access method for resources. In this disclosure, the server can be based on... Figure 10 The steps S904-S905 shown establish this binding relationship. For example... Figure 10 As shown, the method also includes the following steps:

[0180] In step S904, a login request message for the target application sent by the client is received. The login request message includes a second access token, which is an access token issued by the client based on the private key in the login key pair. The login key pair is generated by the login domain name of the target application.

[0181] In step S905, the binding relationship is established based on the second access token.

[0182] In this step, a second public key can be determined based on the second access token. This second public key is the public key in the login key pair. The second access token is then verified using this second public key. After successful verification of the second access token, the second public key fingerprint of the second public key is recorded in the session entity corresponding to the login request message. By recording the second public key fingerprint of the second public key in the session entity, a binding relationship can be established between the second public key and the session.

[0183] Figure 11 It is based on Figure 9 The illustrated embodiment presents a flowchart of a secure access method for resources, as shown below. Figure 11 As shown, the method also includes the following steps:

[0184] In step S906, the client sends a third access token and a fourth access token. 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. The fourth access token is an access token issued by the client under the login domain name of the target application using the private key in the login key pair generated by the login domain name.

[0185] In step S907, in response to verifying that the business domain name is the preset business domain name of the target application based on the third access token and the fourth access token, a certificate identifier is generated.

[0186] In step S908, the certificate identifier and certificate issuance timestamp are sent to the client so that the client can generate a certificate based on the certificate identifier and 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.

[0187] Using the above method, after receiving the session identifier from the gateway device, the server can determine the public key information corresponding to the session based on the session identifier and the binding relationship, and send the binding relationship to the gateway device. This 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 client based on the first access token and the session identifier through the binding relationship pre-established by the server. Since this binding relationship represents the binding relationship between the session and the trusted client of the target application, if the client authentication based on this binding relationship is successful, it can be confirmed that the client sending the resource access request message is also a trusted client, thereby achieving session theft prevention. In response to successful client authentication, the server can request the business resources of the target application based on the resource access request message, which can improve the security of business data.

[0188] Figure 12 This is a block diagram illustrating a secure access device for a resource according to an exemplary embodiment, which can be applied to a client. For example... Figure 12 As shown, the device includes:

[0189] The acquisition module 1201 is used to acquire 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 business key pair. The business key pair is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application.

[0190] The first sending module 1202 is used to send the resource access request message to the gateway device, so that the gateway device can authenticate the client based on the first access token and the session identifier through the binding relationship pre-established by the server, and in response to the client's successful authentication, request 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.

[0191] Optionally, the acquisition module 1201 is configured to, in response to acquiring a service request message for the target application, acquire the session identifier and the service key pair; generate the first access token based on 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.

[0192] Optionally, the business key pair includes a first public key and a first private key;

[0193] The acquisition module 1201 is used to construct a first payload based on the business request message; sign the first payload using the first private key to obtain a first signature; and generate the first access token based on the first public key, the first payload, and the first signature.

[0194] Optionally, the first sending module 1202 is further configured to, in response to receiving a login request for the target application, send a login request message to the server according to the login request, the login request message including a second access token, so that the server establishes the binding relationship based on the second access token, the second access token being an access token issued by the client based on the private key in the login key pair, the login key pair being generated by the login domain name of the target application.

[0195] Optionally, the first sending module 1202 is configured to obtain the login key pair, the login key pair including a second private key and a second public key; generate a second access token based on the second private key, the second public key and the login request; obtain the login request message by adding the second access token to the login request; and send the login request message to the server.

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

[0197] 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 of the target application; the certificate is used to authenticate whether the business domain is trustworthy.

[0198] Optionally, Figure 13 It is based on Figure 12 The illustrated embodiment shows a block diagram of a secure access device for resources, such as Figure 13 As shown, the device also includes a certificate issuance module 1203, used to generate the certificate in the following manner:

[0199] A third access token is issued using the private key in the business key pair generated by the business domain name;

[0200] The third access token is carried to redirect from the business domain to the login domain;

[0201] A fourth access token is issued using the login key pair generated based on the login domain name.

[0202] The certificate is issued under the login domain name based on the login key pair, according to the third access token and the fourth access token.

[0203] Optionally, the login key pair includes a second private key and a second public key; the certificate issuance module 1203 is used to send the third access token and the fourth access token to the server under the login domain name, so that the server, in response to verifying that the business domain name is a preset business domain name of the target application based on the third access token and the fourth access token, generates a certificate identifier; receives the certificate identifier and certificate issuance timestamp sent by the server; uses 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 after signing the Web token using the second private key under the login domain name, generates the certificate.

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

[0205] Optionally, Figure 14 It is based on Figure 13 The illustrated embodiment shows a block diagram of a secure access device for resources, such as Figure 14 As shown, the device also includes:

[0206] The page redirection module 1204 is used to redirect from the business page of the target application to a business intermediate page in response to the target application being a web application. The business intermediate page is a page with the same domain name as the business page but a different path. Under the business domain name, a preset operation is performed through the business intermediate page. 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 signature verification exceptions.

[0207] Optionally, Figure 15 It is based on Figure 12 The illustrated embodiment shows a block diagram of a secure access device for resources, such as Figure 15 As shown, the device also includes:

[0208] The field setting module 1205 is 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.

[0209] Optionally, for multiple request messages in the payload that have the same field value in the first preset specified field, the access tokens carried in the multiple request messages are the same.

[0210] Optionally, the field setting module 1205 is further configured to set the access token carried by the request message within a preset time period to be the same if the at least one second preset field includes a second preset specified field.

[0211] Figure 16 This is a block diagram illustrating a secure access device for a resource according to an exemplary embodiment, which can be applied to a gateway device. Figure 16 As shown, the device includes:

[0212] The first receiving module 1301 is used 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 issued by the client based on the private key in the business key pair. The business key pair is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application.

[0213] The authentication module 1302 is used to authenticate the client based on the first access token and the session identifier through a binding relationship pre-established by the server, wherein the binding relationship represents the binding relationship between the session and the trusted client of the target application;

[0214] The resource access module 1303 is used to request the business resources of the target application based on the resource access request message in response to the client's successful authentication.

[0215] Optionally, the authentication module 1302 is configured to send the session identifier to the server, so that the server can determine 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; and authenticate the client's identity based on the public key information and the first access token.

[0216] Optionally, the public key information includes a second public key fingerprint stored in the session entity of the session, the second public key fingerprint being the public key fingerprint of a second public key, the second public key being the public key in the login key pair, and the login key pair being generated by the login domain name of the target application; the authentication module 1302 is used to obtain a first public key from the first access token, the first public key being the public key in the business key pair; to verify the signature of the first access token using the first public key, and after the signature verification is successful, to verify whether the first public key and the second public key are consistent based on the second public key fingerprint; in response to the first public key and the second public key being consistent, to determine that the client's identity authentication is successful.

[0217] Optionally, in response to the target application being a web application, the resource access request message may also include a certificate issued by the login domain of the target application;

[0218] The authentication module 1302 is used to authenticate the client's identity based on the first access token, the session identifier, and the certificate, through a binding relationship pre-established by the server.

[0219] Optionally, the authentication module 1302 is configured to send the session identifier to the server, so that the server can determine 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; and perform identity authentication on the client based on the public key information, the first access token, and the certificate.

[0220] Optionally, the public key information includes a second public key fingerprint stored in the session entity of the session, the second public key fingerprint being the public key fingerprint of a second public key, the second public key being the public key in the login key pair, and the login key pair being generated by the login domain name of the target application;

[0221] 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 business key pair from the certificate; obtain the first public key from the first access token; and determine that the client's identity authentication is successful in response to the first public key fingerprint matching the first public key and the second public key fingerprint matching the second public key.

[0222] Figure 17 This is a block diagram illustrating a secure access device for a resource according to an exemplary embodiment, which can be applied to a server. Figure 17 As shown, the device includes:

[0223] The second receiving module 1401 is used to receive a session identifier sent by the gateway device. The session identifier is an identifier included in a resource access request message sent by the 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 login to the target application. The resource access request message also includes a first access token, which is an access token issued by the client based on the private key in a business key pair. The business key pair is generated by the business domain name of the target application.

[0224] The determining module 1402 is used to determine the public key information corresponding to the session based on the session identifier through the binding relationship, wherein the binding relationship represents the binding relationship between the session and the trusted client of the target application;

[0225] The second sending module 1403 is used to send the public key information to the gateway device so that the gateway device can authenticate the client based on the public key information and the first access token.

[0226] Optionally, the determining module 1402 is used to determine the session entity of the session corresponding to the session identifier based on the binding relationship; and read the public key information from the session entity, wherein 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 the login key pair, and the login key pair is generated by the login domain name of the target application.

[0227] Optionally, Figure 18 It is based on Figure 17 The illustrated embodiment shows a block diagram of a secure access device for a resource. The second receiving module 1401 is further configured to receive a login request message for the target application sent by a client. The login request message includes a second access token, which is an access token issued by the client based on the private key in a login key pair. The login key pair is generated from the login domain name of the target application. Figure 18 As shown, the device also includes a relationship establishment module 1404 for establishing the binding relationship based on the second access token.

[0228] Optionally, the relationship establishment module 1404 is used to determine a second public key based on the second access token, wherein the second public key is the public key in the login key pair; to verify the second access token using the second public key; and after the second access token is verified, to record the second public key fingerprint of the second public key in the session entity of the login request message.

[0229] Optionally, the second receiving module 1401 is further configured to 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 using 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 based on the third access token and the fourth access token, a certificate identifier is generated; the certificate identifier and 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, and in response to the target application being a web application, the certificate is used to authenticate whether the business domain name is trustworthy.

[0230] The following is for reference. Figure 19 The diagram illustrates a structural schematic 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, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 19 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0231] like Figure 19 As shown, electronic device 1500 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 1601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1502 or a program loaded from storage device 1508 into random access memory (RAM) 1503. The RAM 1503 also stores various programs and data required for the operation of electronic device 1500. The processing device 1501, ROM 1502, and RAM 1503 are interconnected via bus 1504. Input / output (I / O) interface 1505 is also connected to bus 1504.

[0232] Typically, the following devices can be connected to I / O interface 1505: input devices 1506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1509. Communication device 1509 allows electronic device 1500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 19 An electronic device 1500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

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

[0234] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A 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 thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0235] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0236] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0237] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes one or more of these programs, the electronic device causes the following: It acquires 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 issued by the client based on a private key in a business key pair, where 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, whereby the login request message is used to request login to the target application. The electronic device then sends the resource access request message to a gateway device, causing the gateway device to authenticate the client based on the first access token and the session identifier through a pre-established binding relationship by the server. Upon successful authentication of the client, the gateway device 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.

[0238] Alternatively, the aforementioned computer-readable medium carries one or more programs that, 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 a private key in a business key pair, the business key pair being generated by the 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; authenticate the client's identity based on the first access token and the session identifier through a pre-established binding relationship by the server, the binding relationship representing the binding relationship between the session and a trusted client of the target application; and, in response to successful authentication of the client, request business resources of the target application based on the resource access request message.

[0239] Alternatively, the aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: receive a session identifier sent by a gateway device, the session identifier being an identifier contained in a resource access request message sent by a client to the gateway device, 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 a target application; the resource access request message further including a first access token, the first access token being an access token signed by the client based on a private key in a business key pair, the business key pair being generated by the business domain name of the target application; determine the public key information corresponding to the session through a binding relationship based on the session identifier, the binding relationship representing 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 can authenticate the client based on the public key information and the first access token.

[0240] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0241] 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 this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in 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 using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0242] The modules described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a module does not necessarily limit the module itself; for example, an acquisition module can also be described as a "module for acquiring resource access requests".

[0243] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0244] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction 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 be, 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 machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0245] According to one or more embodiments of this disclosure, Example 1 provides a secure access method for resources, applied to a client, comprising: obtaining 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 a private key in a business key pair, the business key pair being generated by the business domain name of the 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; sending the resource access request message to a gateway device, so that the gateway device authenticates the client based on 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 business resources of the target application based on the resource access request message; the binding relationship characterizing the binding relationship between the session and a trusted client of the target application.

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

[0247] According to one or more embodiments of this disclosure, Example 3 provides the method of Example 2, wherein the business key pair includes a first public key and a first private key; the step of generating the first access token based on the business key pair and the business request message includes: constructing a first payload based on the business request message; signing the first payload using the first private key to obtain a first signature; and generating the first access token based on the first public key, the first payload, and the first signature.

[0248] According to one or more embodiments of this disclosure, Example 4 provides the method of Example 1, the method further comprising:

[0249] In response to receiving a login request for the target application, a login request message is sent 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. The second access token is an access token issued by the client based on the private key in the login key pair, which is generated by the login domain name of the target application.

[0250] According to one or more embodiments of this disclosure, Example 5 provides the method of Example 4, wherein sending the login request message to the server according to the login request includes:

[0251] Obtain the login key pair, which includes a second private key and a second public key;

[0252] The second access token is generated based on the second private key, the second public key, and the login request;

[0253] After adding the second access token to the login request, the login request message is obtained;

[0254] Send the login request message to the server.

[0255] According to one or more embodiments of this disclosure, Example 6 provides the method of Example 5, wherein generating the second access token based on the second private key, the second public key, and the login request includes:

[0256] Construct a second payload based on the login request;

[0257] The second payload is signed using the second private key to generate a second signature;

[0258] The second access token is generated based on the second public key, the second payload, and the second signature.

[0259] According to one or more embodiments of this disclosure, Example 7 provides a method of any one of Examples 1-6, wherein, 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 business domain name is trustworthy.

[0260] According to one or more embodiments of this disclosure, Example 8 provides the method of Example 7, wherein the client generates the certificate in the following manner:

[0261] A third access token is issued using the private key in the business key pair generated by the business domain name;

[0262] The third access token is carried to redirect from the business domain to the login domain;

[0263] A fourth access token is issued using the login key pair generated based on the login domain name.

[0264] The certificate is issued under the login domain name based on the login key pair, according to the third access token and the fourth access token.

[0265] According to one or more embodiments of this disclosure, Example 9 provides the method of Example 8, wherein the login key pair includes a second private key and a second public key; the step of issuing the certificate based on the login key pair under the login domain name according to the third access token and the fourth access token includes:

[0266] Under the login domain name, the third access token and the fourth access token are sent to the server, so that the server responds by verifying that the business domain name is the preset business domain name of the target application based on the third access token and the fourth access token, and generates a certificate identifier;

[0267] Receive the certificate identifier and certificate issuance timestamp sent by the server;

[0268] 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. After the Web token is signed using the second private key under the login domain name, the certificate is generated.

[0269] According to one or more embodiments of this disclosure, Example 10 provides the method of Example 8, the method further comprising:

[0270] After the certificate is generated, the user is redirected from the login domain to the business domain with the certificate in hand.

[0271] The certificate is stored in the local storage space corresponding to the business domain name.

[0272] According to one or more embodiments of this disclosure, Example 11 provides the method of Example 7, the method further comprising:

[0273] In response to the fact that the target application is a web application, the user is redirected from the business page of the target application to a business intermediate page, which is a page with the same domain name as the business page but a different path.

[0274] Under the business domain name, a preset operation is performed through the business intermediate page;

[0275] The preset operation includes at least one of the following:

[0276] Generate the business key pair, store the business key pair, store the certificate, and handle signature verification exceptions.

[0277] According to one or more embodiments of this disclosure, Example 12 provides the method of Example 1, the method further comprising:

[0278] In response to the target application being a mobile application, the field value of at least one first preset field in the header of the request message is set to a default value, and / or the field value of at least one second preset field in the payload of the access token carried in the request message is set to a default value.

[0279] The request message includes the login request message and / or the resource access request message.

[0280] According to one or more embodiments of this disclosure, Example 13 provides the method of Example 12, the method further comprising:

[0281] For multiple request messages in the payload that have the same field value in the first preset specified field, the access tokens carried in the multiple request messages are the same.

[0282] According to one or more embodiments of this disclosure, Example 14 provides the method of Example 12, the method further comprising:

[0283] If the at least one second preset field includes a second preset specified field, the access token carried by the request message located within the preset time period is set to be the same.

[0284] According to one or more embodiments of this disclosure, Example 15 provides a secure access method for resources, applied to a gateway device, the method comprising:

[0285] The server receives 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 issued by the client based on the private key in a business key pair, which 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. The login request message is used to request login to the target application.

[0286] The client is authenticated based on the first access token and session identifier through a pre-established binding relationship on the server. The binding relationship represents the binding relationship between the session and a trusted client of the target application.

[0287] In response to successful authentication of the client, the system requests the target application's business resources based on the resource access request message.

[0288] According to one or more embodiments of this disclosure, Example 16 provides the method of Example 15, wherein authenticating the client based on the first access token and session identifier through a pre-established binding relationship on the server includes:

[0289] 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 binding relationship according to the session identifier;

[0290] Receive the public key information sent by the server;

[0291] The client is authenticated based on the public key information and the first access token.

[0292] According to one or more embodiments of this disclosure, Example 17 provides the method of Example 16, wherein the public key information includes a second public key fingerprint stored in the session entity of the session, the second public key fingerprint being a public key fingerprint of a second public key, the second public key being a public key in a login key pair, the login key pair being generated by the login domain name of the target application;

[0293] The step of authenticating the client's identity based on the public key information and the first access token includes:

[0294] Obtain the first public key from the first access token, wherein the first public key is the public key in the business key pair;

[0295] The first public key is used to verify the first access token, and after the verification is successful, the first public key and the second public key are verified to be consistent based on the fingerprint of the second public key.

[0296] If the first public key matches the second public key, the authentication of the client is confirmed to be successful.

[0297] According to one or more embodiments of this disclosure, Example 18 provides the method of Example 15, wherein, in response to the target application being a web application, the resource access request message further includes a certificate issued by the login domain of the target application;

[0298] The step of authenticating the client based on the first access token and session identifier through a pre-established binding relationship on the server includes:

[0299] The client is authenticated based on the first access token, the session identifier, and the certificate, through a pre-established binding relationship on the server.

[0300] According to one or more embodiments of this disclosure, Example 19 provides the method of Example 18, wherein authenticating the client based on the first access token, the session identifier, and the certificate through a pre-established binding relationship by the server includes:

[0301] 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 binding relationship according to the session identifier;

[0302] Receive the public key information sent by the server;

[0303] The client is authenticated based on the public key information, the first access token, and the certificate.

[0304] According to one or more embodiments of this disclosure, Example 20 provides the method of Example 19, wherein the public key information includes a second public key fingerprint stored in the session entity of the session, the second public key fingerprint being a public key fingerprint of a second public key, the second public key being a public key in a login key pair, the login key pair being generated by the login domain name of the target application;

[0305] The step of authenticating the client's identity based on the public key information, the first access token, and the certificate includes:

[0306] Obtain the second public key and the first public key fingerprint of the first public key in the business key pair from the certificate;

[0307] Obtain the first public key from the first access token;

[0308] 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 client's identity authentication is successful.

[0309] According to one or more embodiments of this disclosure, Example 21 provides a secure access method for a resource, applied to a server, the method comprising:

[0310] The server receives a session identifier sent by the gateway device. The session identifier is an identifier contained in a resource access request message sent by the client to the gateway device. The session identifier is an identifier of the session generated by the server based on a login request message sent by the client. The login request message is used to request login to the target application. The resource access request message also includes a first access token, which is an access token issued by the client based on the private key in the business key pair. The business key pair is generated by the business domain name of the target application.

[0311] The public key information corresponding to the session is determined through the binding relationship based on the session identifier, and the binding relationship represents the binding relationship between the session and the trusted client of the target application;

[0312] The public key information is sent to the gateway device so that the gateway device can authenticate the client based on the public key information and the first access token.

[0313] According to one or more embodiments of this disclosure, Example 22 provides the method of Example 21, wherein determining the public key information corresponding to the session based on the session identifier through the binding relationship includes:

[0314] The session entity corresponding to the session identifier is determined based on the binding relationship;

[0315] 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 the public key fingerprint of a 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 login domain name of the target application.

[0316] According to one or more embodiments of this disclosure, Example 23 provides the method of Example 21, the method further comprising:

[0317] The system receives a login request message for the target application sent by a client. The login request message includes a second access token, which is an access token issued by the client based on the private key in the login key pair. The login key pair is generated by the login domain name of the target application.

[0318] The binding relationship is established based on the second access token.

[0319] According to one or more embodiments of this disclosure, Example 24 provides the method of Example 23, wherein establishing the binding relationship based on the second access token includes:

[0320] A second public key is determined based on the second access token, and the second public key is the public key in the login key pair;

[0321] The second access token is verified using the second public key;

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

[0323] According to one or more embodiments of this disclosure, Example 25 provides the method of Example 21, the method further comprising:

[0324] The system receives 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 using the private key in the login key pair generated by the login domain name.

[0325] In response to verifying that the business domain name is a preset business domain name of the target application based on the third access token and the fourth access token, a certificate identifier is generated;

[0326] The certificate identifier and certificate issuance timestamp are sent to the client so that the client can generate a certificate based on the certificate identifier and 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.

[0327] According to one or more embodiments of this disclosure, Example 26 provides a secure access device for a resource, applied to a client, the device comprising:

[0328] The acquisition module is used to acquire 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 business key pair. The business key pair is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application.

[0329] The first sending module is configured to send the resource access request message to the gateway device, so that the gateway device can authenticate the client based on the first access token and session identifier through the binding relationship pre-established by the server, and in response to the successful authentication of the client, request 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.

[0330] According to one or more embodiments of this disclosure, Example 27 provides a secure access device for resources, applied to a gateway device, the device comprising:

[0331] The first receiving module is used 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 issued by the client based on the private key in a business key pair. 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. The login request message is used to request login to the target application.

[0332] An authentication module is used to authenticate the client based on the first access token and session identifier through a pre-established binding relationship on the server, wherein the binding relationship represents the binding relationship between the session and a trusted client of the target application;

[0333] The resource access module is used to request the business resources of the target application based on the resource access request message in response to the client's successful authentication.

[0334] According to one or more embodiments of this disclosure, Example 28 provides a secure access device for a resource, applied to a server, the device comprising:

[0335] The second receiving module is used to receive a session identifier sent by the gateway device. The session identifier is an identifier contained in a resource access request message sent by the client to the gateway device. The session identifier is an identifier of the session generated by the server based on a login request message sent by the client. The login request message is used to request login to the target application. The resource access request message also includes a first access token, which is an access token issued by the client based on the private key in the business key pair. The business key pair is generated by the business domain name of the target application.

[0336] The determination module is used to determine the public key information corresponding to the session based on the session identifier and the binding relationship, wherein the binding relationship represents the binding relationship between the session and the trusted client of the target application;

[0337] 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 based on the public key information and the first access token.

[0338] According to one or more embodiments of the present disclosure, Example 29 provides a computer-readable medium having a computer program stored thereon that, when executed by a processing device, implements the steps of the method described in any one of Examples 1-14, 15-20, or 21-25.

[0339] According to one or more embodiments of this disclosure, Example 30 provides an electronic device comprising:

[0340] A storage device on which computer programs are stored;

[0341] A processing device for executing the computer program in the storage device to implement the steps of the method described in any one of Examples 1-14, 15-20, or 21-25.

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

[0343] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

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

[0345] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.

Claims

1. A method for secure access to a resource, characterized in that, Applied to a client, the method includes: 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 business key pair. The business key pair is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application. The resource access request message is sent to the gateway device, so that the gateway device authenticates the client based on the first access token and session identifier through the binding relationship pre-established by the server, and in response to the client's successful authentication, 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; The method further includes: In response to receiving a login request for the target application, a login request message is sent 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. The second access token is an access token issued by the client based on the private key in the login key pair, which is generated by the login domain name of the target application.

2. The method according to claim 1, characterized in that, The process of obtaining the resource access request message corresponding to the target application includes: In response to receiving a service request message for the target application, the session identifier and the service key pair are obtained; The first access token is generated based on 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 step of generating the first access token based on the service key pair and the service request message includes: Construct a first payload based on the business request message; The first payload is signed using the first private key to obtain the first signature; The first access token is generated based on the first public key, the first payload, and the first signature.

4. The method according to claim 1, characterized in that, Sending the login request message to the server according to the login request includes: Obtain the login key pair, which includes a second private key and a second public key; The second access token is generated based on the second private key, the second public key, and the login request; After adding the second access token to the login request, the login request message is obtained; Send the login request message to the server.

5. The method according to claim 4, characterized in that, The step of generating the second access token based on the second private key, the second public key, and the login request includes: Construct a second payload based on the login request; The second payload is signed using the second private key to generate a second signature; The second access token is generated based on the second public key, the second payload, and the second signature.

6. The method according to any one of claims 1-5, characterized in that, In response to the target application being a web application, the resource access request message also includes a certificate issued by the login domain of the target application; the certificate is used to authenticate whether the business domain is trustworthy.

7. The method according to claim 6, characterized in that, The client generates the certificate in the following manner: A third access token is issued using the private key in the business key pair generated by the business domain name; The third access token is carried to redirect from the business domain to the login domain; A fourth access token is issued using the login key pair generated based on the login domain name. The certificate is issued under the login domain name based on the login key pair, according to the third access token and the fourth access token.

8. The method according to claim 7, characterized in that, The login key pair includes a second private key and a second public key; The step of issuing the certificate based on the login key pair under the login domain name according to the third access token and the fourth access token includes: Under the login domain name, the third access token and the fourth access token are sent to the server, so that the server responds by verifying that the business domain name is the preset business domain name of the target application based on the third access token and the fourth access token, and generates a certificate identifier; Receive the certificate identifier 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. After the Web token is signed using the second private key under the login domain name, the certificate is generated.

9. The method according to claim 7, characterized in that, The method further includes: After the certificate is generated, the user is redirected from the login domain to the business domain with the certificate in hand. The certificate is stored in the local storage space corresponding to the business domain name.

10. The method according to claim 6, characterized in that, The method further includes: In response to the fact that the target application is a web application, the user is redirected from the business page of the target application to a business intermediate page, which is a page with the same domain name as the business page but a different path. Under the business domain name, a preset operation is performed 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 signature verification exceptions.

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

12. The method according to claim 11, characterized in that, The method further includes: For multiple request messages in the payload that have the same field value in the first preset specified field, the access token carried in the multiple request messages is set to be the same.

13. The method according to claim 11, characterized in that, The method further includes: If the at least one second preset field includes a second preset specified field, the access token carried by the request message located within the preset time period is set to be the same.

14. A method for secure access to a resource, characterized in that, Applied to a gateway device, the method includes: The server receives 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 issued by the client based on the private key in a business key pair, which 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. The login request message is used to request login to the target application. The login request message also includes a second access token, which is an access token issued by the client based on the private key in a login key pair, which is generated by the login domain name of the target application. The client is authenticated based on the first access token and session identifier through a pre-established binding relationship on the server. The binding relationship represents the binding relationship between the session and a trusted client of the target application. In response to the client's successful authentication, the system requests the target application's business resources based on the resource access request message. The step of authenticating the client based on the first access token and session identifier through a pre-established binding relationship on the server includes: 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 binding relationship according to the session identifier; 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 the second public key, the second public key is the public key in the login key pair, the binding relationship includes the binding relationship between the second public key and the session, and the server establishes the binding relationship based on the second access token; Receive the public key information sent by the server; The client is authenticated based on the public key information and the first access token.

15. The method according to claim 14, characterized in that, The step of authenticating the client's identity based on the public key information and the first access token includes: Obtain the first public key from the first access token, wherein the first public key is the public key in the business key pair; The first public key is used to verify the first access token, and after the verification is successful, the first public key and the second public key are verified to be consistent based on the fingerprint of the second public key. If the first public key matches the second public key, the authentication of the client is confirmed to be successful.

16. The method according to claim 14, characterized in that, In response to the target application being a web application, the resource access request message also includes a certificate issued by the login domain of the target application; The step of authenticating the client based on the first access token and session identifier through a pre-established binding relationship on the server includes: The client is authenticated based on the first access token, the session identifier, and the certificate, through a pre-established binding relationship on the server.

17. The method according to claim 16, characterized in that, The step of authenticating the client's identity based on the first access token, the session identifier, and the certificate through a pre-established binding relationship on the server includes: 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 binding relationship according to the session identifier; Receive the public key information sent by the server; The client is authenticated based on the public key information, the first access token, and the certificate.

18. The method according to claim 17, characterized in that, The step of authenticating the client's identity based on 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 business 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, it is determined that the client's identity authentication is successful.

19. A method for secure access to a resource, characterized in that, Applied to a server, the method includes: The system receives a session identifier sent by a gateway device, wherein the session identifier is included in a resource access request message sent by the 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, the login request message being used to request login to the target application; the resource access request message also includes a first access token, the first access token being an access token signed by the client based on the private key in a business key pair, the business key pair being generated by the business domain name of the target application; The public key information corresponding to the session is determined through the binding relationship based on the session identifier, and the binding relationship represents the binding relationship between the session and the trusted client of the target application; The public key information is sent to the gateway device so that the gateway device can authenticate the client based on the public key information and the first access token; The method further includes: The system receives a login request message for the target application sent by a client. The login request message includes a second access token, which is an access token issued by the client based on the private key in the login key pair. The login key pair is generated by the login domain name of the target application. The binding relationship is established based on the second access token.

20. The method according to claim 19, characterized in that, The step of determining the public key information corresponding to the session based on the session identifier and binding relationship includes: The session entity corresponding to the session identifier is determined 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 the public key fingerprint of a 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 login domain name of the target application.

21. The method according to claim 19, characterized in that, The process of establishing the binding relationship based on the second access token includes: A second public key is determined based on the second access token, and the second public key is the public key in the login key pair; The second access token is verified 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.

22. The method according to claim 19, characterized in that, The method further includes: The system receives 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 using 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 based on the third access token and the fourth access token, a certificate identifier is generated; The certificate identifier and certificate issuance timestamp are sent to the client so that the client can generate a certificate based on the certificate identifier and 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.

23. A secure access device for a resource, characterized in that, Applied to a client, the device includes: The acquisition module is used to acquire 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 business key pair. The business key pair is generated by the business domain name of the target application. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application. The first sending module is configured to send the resource access request message to the gateway device, so that the gateway device can authenticate the client based on the first access token and session identifier through the binding relationship pre-established by the server, and in response to the successful authentication of the client, request 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; The first sending module is further configured to respond to receiving a login request for the target application, and send a 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. The second access token is an access token issued by the client based on the private key in the login key pair. The login key pair is generated by the login domain name of the target application.

24. A secure access device for a resource, characterized in that, Applied to a gateway device, the device includes: A first receiving module is 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 issued by the client based on the private key in a business key pair, which 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. The login request message is used to request login to the target application. The login request message also includes a second access token, which is an access token issued by the client based on the private key in a login key pair, which is generated by the login domain name of the target application. An authentication module is used to authenticate the client based on the first access token and session identifier through a pre-established binding relationship on the server, wherein the binding relationship represents the binding relationship between the session and a trusted client of the target application; The resource access module is used to request the business resources of the target application based on the resource access request message in response to the client's successful authentication. The authentication module is used to send the session identifier to the server, so that the server can determine the public key information corresponding to the session based on the binding relationship according to the session identifier; 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 the second public key, the second public key is the public key in the login key pair, the binding relationship includes the binding relationship between the second public key and the session, the server establishes the binding relationship based on the second access token; receives the public key information sent by the server; and performs identity authentication on the client according to the public key information and the first access token.

25. A secure access device for a resource, characterized in that, Applied to a server, the device includes: The second receiving module is used to receive a session identifier sent by the gateway device. The session identifier is included in the resource access request message sent by the client to the gateway device. The session identifier is an identifier of the session generated by the server based on the login request message sent by the client. The login request message is used to request login to the target application. The resource access request message also includes a first access token, which is an access token issued by the client based on the private key in the business key pair. The business key pair is generated by the business domain name of the target application. The determination module is used to determine the public key information corresponding to the session based on the session identifier and the binding relationship, wherein the binding relationship represents the binding relationship between the session and the 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 based on the public key information and the first access token; The second receiving module is further configured to receive a login request message for the target application sent by the client. The login request message includes a second access token, which is an access token issued by the client based on the private key in the login key pair. The login key pair is generated by the login domain name of the target application. The device further includes a relationship establishment module for establishing the binding relationship based on the second access token.

26. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by a processing device, the computer program performs the steps of the method described in any one of claims 1-13, 14-18, or 19-22.

27. An electronic device, characterized in that, include: A storage device on which computer programs are stored; A processing apparatus for executing the computer program in the storage device to implement the steps of the method according to any one of claims 1-13, 14-18, or 19-22.

28. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1-13, 14-18, or 19-22.

Images