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

Abstract

A resource authorization access method and apparatus, a medium, an electronic device and a program product, the method comprising: in response to an access request for a first resource, sending an authentication request to an authentication server, and receiving a first credential returned by the authentication server; sending a registration request to an authorization server corresponding to the first resource based on the first credential, and receiving a second credential returned by the authorization server; wherein the second credential is used for acquiring an access credential for the first resource. According to the method, protected dynamic registration of clients such as the third-party application is realized, the registration efficiency and flexibility can be improved, the leakage risk of registration credentials can be reduced, and the resource security is further guaranteed.

Description

Technical Field

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

[0002] Application authorization processes allow resource owners to authorize third-party applications to access their protected data on resource servers without revealing their account passwords. Before initiating the application authorization process, the third-party application typically needs to be registered with the corresponding authorization server.

[0003] In related technologies, third-party applications and other clients are usually registered to the authorization server manually, or the client sends a registration request to the authorization server based on a manually issued registration token, which is cumbersome and inefficient. Summary of the Invention

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

[0005] Firstly, this disclosure provides a method for authorizing access to resources, the method comprising: In response to an access request to the first resource, an authentication request is sent to the authentication server, and the first credential returned by the authentication server is received. Based on the first credential, a registration request is sent to the authorization server corresponding to the first resource, and a second credential is returned by the authorization server; wherein, the second credential is used to obtain access credentials for the first resource.

[0006] Secondly, this disclosure provides a resource authorization access method applied to an authentication server, the method comprising: In response to the authentication request sent by the first requester, the first requester is authenticated, and the first credentials are returned after successful authentication; Wherein, after receiving the first credential, the first requester sends a registration request to the authorization server corresponding to the first resource based on the first credential, and receives the second credential returned by the authorization server, the second credential being used to obtain access credentials for the first resource.

[0007] Thirdly, this disclosure provides a resource authorization access method, applied to an authorization server corresponding to a first resource, the method comprising: In response to a registration request sent by a first requester based on a first credential, if it is determined that the authentication server that generated the first credential is trustworthy, the first requester is registered and a second credential is returned to the first requester. The first credential is returned by the authentication server to the first requester after the authentication request sent by the first requester has been successfully authenticated, and the second credential is used to obtain access credentials for the first resource.

[0008] Fourthly, 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 the first, second, or third aspects.

[0009] Fifthly, this disclosure provides an electronic device, comprising: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method described in the first, second, or third aspect.

[0010] In a sixth aspect, 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 the first, second, or third aspects.

[0011] The above technical solution involves sending an authentication request to an authentication server in response to an access request for a first resource, receiving a first credential returned by the authentication server, and then sending a registration request to the authorization server corresponding to the first resource based on the first credential. The authorization server then returns a second credential used to obtain access credentials for the first resource. This method enables protected dynamic registration for third-party applications and other clients. Compared to manual registration or manually issued registration credentials, this approach not only improves registration efficiency and flexibility but also reduces the risk of credential leakage, thereby ensuring resource security.

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

[0013] 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: Figure 1 This is a flowchart illustrating a resource authorization access method according to an exemplary embodiment.

[0014] Figure 2 This is an interactive schematic diagram illustrating a registration process according to an exemplary embodiment.

[0015] Figure 3 This is an interactive schematic diagram illustrating an authorization process according to an exemplary embodiment.

[0016] Figure 4 This is a flowchart illustrating a resource authorization access method according to an exemplary embodiment.

[0017] Figure 5 This is a flowchart illustrating a resource authorization access method according to an exemplary embodiment.

[0018] Figure 6 This is a schematic diagram of the structure of a resource authorization access device according to an exemplary embodiment.

[0019] Figure 7 This is a schematic diagram of the structure of a resource authorization access device according to an exemplary embodiment.

[0020] Figure 8 This is a schematic diagram of a resource authorization access device according to an exemplary embodiment.

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

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

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

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

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

[0026] 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".

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

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

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

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

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

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

[0033] OAuth 2.0 acts on behalf of users by organizing resource owners through approved interactions between them and HTTP (Hypertext Transfer Protocol) servers, or by allowing third-party applications to gain access on behalf of users. It also provides dedicated authentication processes for clients such as web applications, desktop applications, mobile phones, and smart home devices.

[0034] The core design of OAuth involves four main parties: the user (resource owner), who is the entity that grants access to the resource, usually the end user; the resource server, which is the entity that hosts the protected resource, usually the backend API (Application Programming Interface), and receives and verifies the access token when processing the resource request; the client, which is the application that needs to access the resource on behalf of the resource owner, and is equivalent to the resource requester, and achieves this by sending an access token to the resource server; and the authorization server, which is the entity that authenticates the resource owner and then issues the access token to the client.

[0035] In order for a client to use an authorization server, the client needs specific information to interact with the authorization server, including a client identifier used on that server. Related technologies allow third-party applications and other clients to be manually registered to the authorization server, or to register clients based on manually issued registration tokens. For example, to restrict dynamic client registration to trusted developers or clients and prevent unauthorized client registration, registration tokens can be issued to initiate the dynamic client registration process. Therefore, how to securely store and distribute registration tokens to clients wishing to register becomes a pressing issue. If registration tokens are leaked, malicious and unauthorized actors can create clients, leading to resource leaks. On the other hand, if the registration token has a short validity period, it needs to be frequently reissued, which is cumbersome and inefficient.

[0036] In view of this, the present disclosure provides a resource authorization access method, apparatus, medium, electronic device, and program product to solve the above-mentioned technical problems.

[0037] Figure 1 This is a flowchart illustrating a resource authorization access method according to an exemplary embodiment. For example... Figure 1 As shown, this method can be applied to the first requester and may include the following steps: S101: In response to the access request for the first resource, send an authentication request to the authentication server and receive the first credentials returned by the authentication server.

[0038] In this embodiment, the authentication server responds to the authentication request by authenticating the identity of the first requester and returns a first credential upon successful authentication. The first credential can be understood as a registration credential or initial access credential issued by the authentication server to the first requester for registration with the authorization server. It can be a token or other forms, and this disclosure does not impose any restrictions on it.

[0039] S102: Send a registration request to the authorization server corresponding to the first resource based on the first credential, and receive the second credential returned by the authorization server; wherein the second credential is used to obtain access credentials for the first resource.

[0040] In this embodiment, in response to a registration request, the authorization server verifies the first credential if it determines that the authentication server is trustworthy, and returns a second credential upon successful verification. The second credential can be understood as a credential issued by the authorization server to the first requester, indicating that the first requester is a registered client of the authorization server; that is, a client credential. It may include information such as a client identifier, client key, and client certificate indicating that the client registration is complete. Subsequently, the client credential can be used to request resource access credentials from the authorization server.

[0041] In the possible ways, the authentication server and the authorization server belong to different trust domains.

[0042] For example, such as Figure 2 As shown, assuming the client (i.e. the first requester, hereinafter the same) and the authentication server are in the first trust domain, and the authorization server and resource server of the first resource are in the second trust domain, the user agent initiates an access request for the first resource in the second trust domain to the first requester in the first trust domain. The user needs to trust the client or workload in the first trust domain and initiate a registration process and an authorization process to the authorization server in the second trust domain to achieve cross-trust domain resource access.

[0043] In one possible manner, the authentication request includes first information related to the authorization server; the first credentials include second information related to the authentication server.

[0044] like Figure 2As shown, the client initiates an authentication request to the authentication server, which requests the client's registration credentials from the authentication server. The authentication request may include the client's identity authentication information, such as proving the client's trustworthiness through remote authentication. The authentication request may also include relevant information about the authorization server, such as the authorization server corresponding to the first resource requested by the client being server x. The first piece of information may be server information that can characterize server x, such as the identification information of server x, URL (Uniform Resource Locator), etc. The specific information can be selected according to the requirements, and this disclosure does not impose any restrictions on it.

[0045] For example, the authentication server authenticates the first requester based on the identity authentication information. After successful authentication, it returns registration credentials. Registration credentials are equivalent to verifiable documents, such as JWT (SON Web Token) or SVID (SPIFFE Verifiable Identity File). They need to prove that the first requester is a trusted client of the authentication server, that the registration credentials are only used for dynamic client registration, and that the target audience is the authorization server (such as server x mentioned above). The specific configuration can be configured according to requirements, and this disclosure does not impose any restrictions on this.

[0046] In addition, the registration credentials generated by the authentication server also carry relevant information about the authentication server, such as its identification information, URL, etc. The specific details can be selected according to needs, and this disclosure does not impose any restrictions. This is so that the authorization server can subsequently determine the issuer of the registration credentials and perform the appropriate verification.

[0047] In one possible manner, a registration request is sent to the authorization server corresponding to the first resource based on the first credential, including: sending the registration request to the authorization server based on resource scope information representing the first resource and the first credential; the authorization server registers based on the resource scope information if its trusted list includes the second information and the first credential is verified, and returns the second credential after the registration is completed.

[0048] For example, such as Figure 2 As shown, after obtaining the registration credentials, the first requester initiates a dynamic client registration process based on the dynamic_client_registration (DCR) endpoint of the authorization server. The registration request needs to specify the first requester's identification information (such as name), callback address (such as client redirect URL (Uniform Resource Locator)) and required resource range (such as the first resource) to start the dynamic client registration process.

[0049] For example, the authentication server's information can be pre-added to the authorization server's trusted list to indicate that the authentication server is a trusted server of the authorization server. Accordingly, if the authorization server's trusted list includes the second information, it can determine that the authentication server that issued the first credential is trustworthy. Since the authentication server issues the first credential after the first requester's authentication is successful, the authorization server can determine that the first requester is also trustworthy. It then verifies the first credential, such as through token verification, and registers it based on resource scope information after successful verification, returning the credential to the client upon completion of registration.

[0050] For example, registration can be performed for different resource scopes to obtain corresponding client credentials, avoiding over-scope authorization and adapting to business scenarios with changing resources. For instance, user resource requests are flexible and varied; many resources may not be requested again after a single request or in the short term. In this case, historically registered client credentials can be deleted periodically to avoid data redundancy.

[0051] It should be understood that if the first requester requests the first resource again, the authorization process can be initiated directly based on the second credentials. If the first requester requests the second resource in the same trust domain as the authorization server, the dynamic client registration process needs to be re-initiated based on the first credentials to obtain client credentials for the second resource. This allows the first requester to initiate an authorization request based on the client credentials for the second resource to obtain access credentials for the second resource. If the first requester requests other resources in other trust domains, the dynamic client registration process needs to be re-initiated to request the corresponding registration credentials and client credentials. This embodiment is applicable to business scenarios with highly dynamic workloads such as IoT or AI agents. That is, as the workload changes, registration credentials can be quickly obtained for dynamic client registration, and then the authorization process can proceed.

[0052] Since the authentication server is a trusted server of the authorization server, it can realize protected dynamic client registration based on the registration credentials issued by the authentication server. Since the first requester is a trusted client of the authentication server, it can reduce resource security problems caused by the leakage of registration credentials.

[0053] Additionally, an expiration period can be set for registration credentials. Within this period, the first requester does not need to re-authenticate and can directly initiate the registration process with the authorization server based on the registration credentials. Even with a short expiration period, new registration credentials can be obtained quickly, and since the first requester and the authorization server are in the same trust domain, the security of registration credential storage and distribution can be effectively guaranteed.

[0054] Using the above method, an authentication request can be sent to the authentication server in response to a resource access request to obtain the first credential for registration. Then, based on the first credential, registration can be performed with the resource's authorization server, thereby realizing protected dynamic registration for third-party applications and other clients. Compared with manual registration or manually issued registration credentials, this method not only improves registration efficiency and flexibility but also reduces the risk of registration credential leakage, thus ensuring resource security.

[0055] In possible ways, sending an authentication request to an authentication server includes: sending an authentication request to an authentication server when the first previously obtained credential is not stored; the resource authorization access method also includes: sending a registration request to an authorization server based on the first previously obtained credential when the first previously obtained credential is stored but the second previously obtained credential is not stored.

[0056] For example, if the first requester has not authenticated with the authentication server to obtain registration credentials, or if the previously obtained registration credentials have expired, it needs to initiate an authentication request to the authentication server to obtain valid registration credentials. Conversely, if the first requester has already authenticated with the authentication server to obtain registration credentials, or if the previously obtained registration credentials are valid, it can directly initiate a registration request. Of course, if it has already completed registration and obtained client credentials, it can directly respond to the access request by initiating an authorization process with the authorization server to obtain resource access credentials for the first resource. Therefore, this embodiment allows for one-time authentication and multiple authorizations, achieving flexible, efficient, and protected dynamic client registration.

[0057] In one possible manner, the method further includes: sending an authorization request for the first resource to an authorization server based on a second credential, and receiving a third credential returned by the authorization server; wherein the third credential is a credential used to access the first resource; sending an access request to a resource server of the first resource based on the third credential, and receiving the first resource returned by the resource server.

[0058] After completing the dynamic client registration process, the first requester will obtain a set of client credentials, which can be used to initiate actions such as... Figure 3 The OAuth 2.0 authorization flow shown obtains the user's consent to access protected resources on behalf of the user by trusting credentials issued by the authorization server, and obtains resource access credentials issued by the authorization server to access the user's protected resources on behalf of the user.

[0059] like Figure 3As shown, the client (i.e., the first requester, hereinafter the same) initiates the authorization process by redirecting the user to the authorization server. The request may include the client's identifier and key (client credentials returned after registration), the scope of the requested resource, the client's redirect URL, and the response type. The authorization server returns a redirect to the login page with the request identifier (such as an ID) to the client. The user directly authenticates with the authorization server (never sharing credentials with the client), views the requested permissions, and decides whether to grant or deny access. The authorization server verifies the user's identity and authorization, and then redirects back to the client using an authorization code. Alternatively, the user can directly access the resource access credentials here.

[0060] Taking the authorization code process as an example, the client also needs to send a reverse channel request to the authorization server to exchange the authorization code for resource access credentials. The request includes the authorization code, client identifier, client key, and a redirect URL for verification. The authorization server verifies the authorization code and client credentials, and then issues a resource access credential to the client with a specific resource scope and expiration time. When the client sends an access request to the resource server to access the protected resource owned by the resource server, it includes the resource access credential in the authorization header. The resource server verifies the resource access credential by verifying its signature (for JWT tokens) or by making an introspection call to the authorization server, and then checks whether the resource access credential has the required resource scope. If the resource access credential is valid and has sufficient permissions, the resource server returns the protected resource to the client; if verification fails, it returns an error.

[0061] Furthermore, when a client's resource access credentials expire, it can use refresh credentials to obtain new resource access credentials from the authorization server, thus avoiding the need to re-authenticate the user. Throughout this process, the resource owner's credentials are never exposed to the client, maintaining security through delegated authorization rather than credential sharing.

[0062] Using the above method, there is no need to manually issue registration credentials to initiate dynamic client registration, thus avoiding obstacles to the client registration process. It also enables secure, efficient, and flexible storage and distribution of client registration credentials, preventing malicious and unauthorized client creation due to credential leakage. Furthermore, it allows clients from one identity provider to generate registration credentials and dynamically register on another identity provider to access protected resource servers. It also allows clients from one trust domain to dynamically register on another trust domain without maintaining multiple sets of client credentials for different trust domains. It enables clients from one trust domain to access resources in another trust domain without converting all resource servers in the accessed trust domain to tokens from the client's trust domain, simplifying access between different trust domains. Finally, it allows clients from one trust domain to obtain user authorization in another trust domain to access applications within that trust domain.

[0063] Figure 4 This is a flowchart illustrating a resource authorization access method according to an exemplary embodiment. For example... Figure 4 As shown, this method, applied to an authentication server, may include the following steps: S401: In response to the authentication request sent by the first requester, authenticate the first requester and return the first credential after successful authentication; wherein, after receiving the first credential, the first requester sends a registration request to the authorization server corresponding to the first resource based on the first credential, and receives the second credential returned by the authorization server, the second credential being used to obtain access credentials for the first resource.

[0064] The authentication request may include the identity authentication information of the first requester, such as proving the trustworthiness of the first requester through remote authentication. The authentication request may also include relevant information that can characterize the authorization server requested by the first requester.

[0065] For example, an authentication request is sent by a first requester in response to an access request for a first resource. Information about the authentication server can be pre-added to the authorization server's trusted list to indicate that the authentication server is a trusted server of the authorization server. Accordingly, if the authorization server's trusted list includes the authentication server's information, it can determine that the authentication server that issued the first credential is trustworthy. Since the authentication server issues the first credential after the first requester's authentication is successful, the authorization server can determine that the first requester is also trustworthy. The first credential is then verified, for example, through token verification, and upon successful verification, registration is performed based on resource scope information. After registration, the client's credentials are returned.

[0066] An authentication server can quickly authenticate the first requester and issue registration credentials upon successful authentication, enabling the first requester to initiate a dynamic client registration process based on these credentials. Since the authentication server is a trusted server of the authorization server, protected dynamic client registration can be achieved based on the registration credentials issued by the authentication server. Furthermore, the fact that the first requester is a trusted client of the authentication server reduces resource security issues caused by the leakage of registration credentials.

[0067] Using the above method, an authentication request can be sent to the authentication server in response to a resource access request to obtain the first credential for registration. Then, based on the first credential, registration can be performed with the resource's authorization server, thereby realizing protected dynamic registration for third-party applications and other clients. Compared with manual registration or manually issued registration credentials, this method not only improves registration efficiency and flexibility but also reduces the risk of registration credential leakage, thus ensuring resource security.

[0068] The above-described method embodiments of the authentication server have been applied to the resource authorization access method for the first requester and Figure 2 The details are explained in the literature, and will not be repeated here.

[0069] Figure 5 This is a flowchart illustrating a resource authorization access method according to an exemplary embodiment. For example... Figure 4 As shown, this method, applied to the authorization server corresponding to the first resource, may include the following steps: S501: In response to the registration request sent by the first requester based on the first credential, if it is determined that the authentication server that generated the first credential is trustworthy, the first requester is registered and a second credential is returned to the first requester; wherein, the first credential is returned to the first requester by the authentication server after the authentication request sent by the first requester is successfully authenticated, and the second credential is used to obtain access credentials for the first resource.

[0070] In one possible manner, the registration request includes resource scope information representing a first resource and a first credential. Registering the first requester includes: registering the first requester based on the resource scope information if the first credential verification is successful, and returning a second credential upon completion of registration.

[0071] In this embodiment, the authorization server can issue the registration credentials of the first requester based on a trusted authentication server, thereby initiating the dynamic client registration process and improving its flexibility and efficiency. The second credential can be understood as a credential issued by the authorization server to the first requester, indicating that the first requester is a registered client of the authorization server; that is, a client credential. This credential may include information such as client identifier, client key, and client certificate indicating that client registration is complete. Subsequently, the client credential can be used to request resource access credentials from the authorization server.

[0072] Using the above method, an authentication request can be sent to the authentication server in response to a resource access request to obtain the first credential for registration. Then, based on the first credential, registration can be performed with the resource's authorization server, thereby realizing protected dynamic registration for third-party applications and other clients. Compared with manual registration or manually issued registration credentials, this method not only improves registration efficiency and flexibility but also reduces the risk of registration credential leakage, thus ensuring resource security.

[0073] In one possible approach, the method further includes: in response to a trusted configuration operation on the authentication server, writing second information related to the authentication server into a trusted list of the authorization server. The first credential includes the second information related to the authentication server; determining that the authentication server that generated the first credential is trusted includes: if the trusted list includes the second information, determining that the authentication server is trusted.

[0074] For example, the administrator of the authorization server can store the URL corresponding to the authentication server in a trusted list, making it a trusted issuer for potential clients to register for dynamic clients. In this way, the authentication server becomes a trusted server of the authorization server, enabling the issuance of registration credentials based on the trusted authentication server and achieving an efficient and flexible dynamic client registration process.

[0075] For example, the authenticity of the authentication server and the authenticity of the first requester can be determined based on the first credentials. If the authentication server is found to be trustworthy and the first requester is a trusted client of the authentication server, the first requester can be registered to prevent untrusted clients from registering and improve resource security.

[0076] The above-described method embodiments of the authorization server have been applied to the resource authorization access method for the first requester and Figure 2 The details are explained in the literature, and will not be repeated here.

[0077] Figure 6 This is a schematic diagram illustrating the structure of a resource authorization access device according to an exemplary embodiment. For example... Figure 6 As shown, the resource authorization access device 600 includes: The first sending module 601 is used to send an authentication request to the authentication server in response to an access request to the first resource, and to receive the first credential returned by the authentication server. The second sending module 602 is used to send a registration request to the authorization server corresponding to the first resource based on the first credential, and to receive a second credential returned by the authorization server; wherein the second credential is used to obtain access credentials for the first resource.

[0078] Optionally, the authentication request includes first information related to the authorization server; the first credential includes second information related to the authentication server.

[0079] Optionally, the second sending module 602 is used to: The registration request is sent to the authorization server based on the resource scope information representing the first resource and the first credential; if the authorization server includes the second information in its trusted list and the first credential is verified, it registers based on the resource scope information and returns the second credential after registration is completed.

[0080] Optionally, the first sending module 601 is configured to: send the authentication request to the authentication server if the first credential obtained in the past is not stored; The resource authorization access device 600 further includes a third sending module, configured to send a registration request to the authorization server based on the historically obtained first credential when the first credential obtained in the past is stored but the second credential obtained in the past is not stored.

[0081] Optionally, the resource authorization access device 600 further includes a fourth sending module, used for: Based on the second credential, an authorization request for the first resource is sent to the authorization server, and a third credential is returned by the authorization server; wherein, the third credential is a credential used to access the first resource; Based on the third credential, an access request is sent to the resource server of the first resource, and the first resource is returned by the resource server.

[0082] Optionally, the authentication server and the authorization server belong to different trust domains.

[0083] Figure 7 This is a schematic diagram illustrating the structure of a resource authorization access device according to an exemplary embodiment. For example... Figure 7 As shown, the resource authorization access device 700 is applied to an authentication server, and the resource authorization access device 700 includes: The authentication module 701 is used to respond to the authentication request sent by the first requester, authenticate the first requester, and return the first credential after successful authentication; Wherein, after receiving the first credential, the first requester sends a registration request to the authorization server corresponding to the first resource based on the first credential, and receives the second credential returned by the authorization server, the second credential being used to obtain access credentials for the first resource.

[0084] Figure 8 This is a schematic diagram illustrating the structure of a resource authorization access device according to an exemplary embodiment. For example... Figure 8 As shown, the resource authorization access device 800 is applied to the authorization server corresponding to the first resource, and the resource authorization access device 800 includes: The registration module 801 is used to respond to a registration request sent by the first requester based on the first credential, and, if it is determined that the authentication server that generated the first credential is trustworthy, register the first requester and return the second credential to the first requester. The first credential is returned by the authentication server to the first requester after the authentication request sent by the first requester has been successfully authenticated, and the second credential is used to obtain access credentials for the first resource.

[0085] Optionally, the resource authorization access device 800 further includes: A configuration module is used to write second information related to the authentication server into the trusted list of the authorization server in response to a trusted configuration operation on the authentication server. The registration module 801 is used to determine that the authentication server is trustworthy when the trusted list includes the second information.

[0086] The method logic executed by each functional module of the resource authorization access device in the above embodiments has been described in detail in the section on methods, and will not be repeated here.

[0087] Based on the same concept, embodiments of this disclosure also provide a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of any of the resource authorization access methods described above.

[0088] Based on the same concept, this disclosure also provides an electronic device that may include: A storage device on which computer programs are stored; A processing device for executing a computer program in a storage device to implement the steps of any of the above-described resource authorization access methods.

[0089] Based on the same concept, embodiments of this disclosure also provide a computer program product, including a computer program that, when executed by a processor, implements any of the above-described steps for authorized access to resources.

[0090] The following is for reference. Figure 9 The diagram illustrates a structural schematic of an electronic device 900 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 9 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0091] like Figure 9 As shown, electronic device 900 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 901, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 902 or a program loaded from storage device 908 into random access memory (RAM) 903. RAM 903 also stores various programs and data required for the operation of electronic device 900. Processing device 901, ROM 902, and RAM 903 are interconnected via bus 904. Input / output (I / O) interface 905 is also connected to bus 904.

[0092] Typically, the following devices can be connected to I / O interface 905: input devices 906 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 907 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 908 including, for example, magnetic tapes, hard disks, etc.; and communication devices 909. Communication device 909 allows electronic device 900 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 9 An electronic device 900 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.

[0093] 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 a communication device 909, or installed from a storage device 908, or installed from a ROM 902. When the computer program is executed by a processing device 901, it performs the functions defined in the methods of embodiments of this disclosure.

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

[0095] In some implementations, communication can be conducted using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol), and can be interconnected 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 end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

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

[0097] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: in response to an access request to a first resource, send an authentication request to an authentication server and receive a first credential returned by the authentication server; send a registration request to an authorization server corresponding to the first resource based on the first credential and receive a second credential returned by the authorization server; wherein the second credential is used to obtain access credentials for the first resource.

[0098] Alternatively, the aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: authenticate the first requester in response to an authentication request sent by the first requester, and return a first credential upon successful authentication; wherein, after receiving the first credential, the first requester sends a registration request to an authorization server corresponding to the first resource based on the first credential, and receives a second credential returned by the authorization server, the second credential being used to obtain access credentials for the first resource.

[0099] Alternatively, the aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: in response to a registration request sent by a first requester based on a first credential, register the first requester if it is determined that the authentication server that generated the first credential is trustworthy, and return a second credential to the first requester; wherein the first credential is returned to the first requester by the authentication server after the authentication request sent by the first requester has been successfully authenticated, and the second credential is used to obtain access credentials for the first resource.

[0100] 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).

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

[0102] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules are not, in some cases, intended to limit the functionality of the module itself.

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

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

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

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

[0107] 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 authorizing access to resources, characterized in that, The method includes: In response to an access request to the first resource, an authentication request is sent to the authentication server, and the first credential returned by the authentication server is received. Based on the first credential, a registration request is sent to the authorization server corresponding to the first resource, and a second credential is returned by the authorization server; wherein, the second credential is used to obtain access credentials for the first resource.

2. The resource authorization access method according to claim 1, characterized in that, The authentication request includes first information related to the authorization server; The first credential includes second information related to the authentication server.

3. The resource authorization access method according to claim 2, characterized in that, Sending a registration request to the authorization server corresponding to the first resource based on the first credential includes: The registration request is sent to the authorization server based on the resource scope information representing the first resource and the first credential; if the authorization server includes the second information in its trusted list and the first credential is verified, it registers based on the resource scope information and returns the second credential after registration is completed.

4. The resource authorization access method according to any one of claims 1-3, characterized in that, Sending the authentication request to the authentication server includes: sending the authentication request to the authentication server when the first credential obtained in the past is not stored; The method further includes: if the first credential obtained in the past is stored but the second credential obtained in the past is not stored, sending a registration request to the authorization server based on the first credential obtained in the past.

5. The resource authorization access method according to any one of claims 1-3, characterized in that, The method further includes: Based on the second credential, an authorization request for the first resource is sent to the authorization server, and a third credential is returned by the authorization server; wherein, the third credential is a credential used to access the first resource; Based on the third credential, an access request is sent to the resource server of the first resource, and the first resource is returned by the resource server.

6. The resource authorization access method according to any one of claims 1-3, characterized in that, The authentication server and the authorization server belong to different trust domains.

7. A method for authorizing access to resources, characterized in that, Applied to an authentication server, the method includes: In response to the authentication request sent by the first requester, the first requester is authenticated, and the first credentials are returned after successful authentication; Wherein, after receiving the first credential, the first requester sends a registration request to the authorization server corresponding to the first resource based on the first credential, and receives the second credential returned by the authorization server, the second credential being used to obtain access credentials for the first resource.

8. A method for authorizing access to resources, characterized in that, Applied to the authorization server corresponding to the first resource, the method includes: In response to a registration request sent by a first requester based on a first credential, if it is determined that the authentication server that generated the first credential is trustworthy, the first requester is registered and a second credential is returned to the first requester. The first credential is returned by the authentication server to the first requester after the authentication request sent by the first requester has been successfully authenticated, and the second credential is used to obtain access credentials for the first resource.

9. The resource authorization access method according to claim 8, characterized in that, The method further includes: In response to a trusted configuration operation on the authentication server, second information related to the authentication server is written into the trusted list of the authorization server; The first credential includes second information related to the authentication server, and determining that the authentication server that generated the first credential is trustworthy includes: If the trusted list includes the second information, the authentication server is determined to be trustworthy.

10. 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 according to any one of claims 1-9.

11. An electronic device, characterized in that, include: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of claims 1-9.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-9.

Images