Resource calling method and device

Abstract

The present disclosure provides a resource invocation method and apparatus, relating to the field of mobile communication technology. The method includes a resource owner receiving a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, the resource authorization request being used to request, set, or modify a resource of the resource owner, sending an authorization code request to a first entity, the authorization code request being used to request an authorization code, and the resource owner sending the authorization code received from the first entity to the API caller. According to the technical solution of the present disclosure, in a invocation scenario, a UE authorizes the API caller to request a resource of the UE, and data tampering by the resource owner during the authorization process can be avoided.

Description

[Technical Field]

[0001] The present disclosure relates to the field of mobile communication technology, and in particular to a resource calling method and apparatus. [Background technology]

[0002] One of the security research goals for subscriber-aware Northbound API access (SNA) is obtaining resource owner authorization. Related technologies allow user equipment (UE) to provide or revoke authorization for information sharing with third parties. In this case, the UE is the resource owner, and an application programming interface (API) caller must obtain authorization from the UE before requesting a resource (e.g., a specific UE's location information). However, in an API call scenario, there is no mechanism that allows the UE to authorize the API caller to request that resource. Summary of the Invention [Problem to be solved by the invention]

[0003] The present disclosure provides a resource invocation method and apparatus, allowing a UE to authorize an API caller to request resources of the UE in a calling scenario. [Means for solving the problem]

[0004] An embodiment of a first aspect of the present disclosure provides a resource invocation method performed by a resource owner, the method including: receiving a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, where the resource authorization request is used to request, set, or modify a resource of the resource owner; sending an authorization code request to a first entity, where the authorization code request is used to request an authorization code; and sending the authorization code received from the first entity to the API caller.

[0005] In some embodiments, the method further includes performing mutual authentication with the API caller, and if the authentication is successful, establishing a first connection between the resource owner and the API caller, wherein the first connection is a secure connection for transmitting resource authorization requests and / or API authorization requests.

[0006] In some embodiments, performing mutual authentication with the API caller includes at least one of performing mutual authentication with the API caller based on a certificate if the API caller is a user equipment (UE), and performing mutual authentication with the API caller through a generic bootstrapping architecture (GBA) based authentication mechanism, an authentication and key management for applications (AKMA) based authentication mechanism, or a certificate-based authentication mechanism if the API caller is an application function (AF).

[0007] In some embodiments, receiving a resource authorization request and / or an API authorization request sent from the API caller includes: if the API caller has obtained authorization for the service, receiving a resource authorization request sent from the API caller; and if the API caller has not obtained authorization for the service, receiving a resource authorization request and an API authorization request sent from the API caller, wherein the resource authorization request includes at least one of an identifier of the API caller, an identifier of the resource owner, and a target resource identifier, and the API authorization request includes a service identifier.

[0008] In some embodiments, the service identifier includes at least one of a service name identifier, a service operation identifier, an operation semantic identifier, and an API identifier.

[0009] In some embodiments, the method further includes performing mutual authentication with the first entity, and if the authentication is successful, establishing a second connection between the resource owner and the first entity, the second connection being a secure connection for transmitting the authorization code request and response.

[0010] In some embodiments, mutually authenticating with the first entity includes mutually authenticating based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK (transport layer security with pre-shared key), and an OAuth (open authorization) token-based authentication mechanism.

[0011] In some embodiments, sending the authorization code request to the first entity includes at least one of: agreeing the resource authorization request in real time and sending the authorization code request to the first entity; agreeing the resource authorization request asynchronously based on a local policy of the resource owner and sending the authorization code request to the first entity; and sending the local policy and / or the authorization code request to the first entity, wherein the local policy is used to assist the first entity in agreeing the resource authorization request asynchronously.

[0012] In some embodiments, the method further includes receiving an authorization code sent from the first entity if the resource authorization request obtains authorization and the API caller obtains authorization for the service.

[0013] In some embodiments, the resource owner is a user equipment (UE) and the resource is quality of service and / or location information of the UE.

[0014] An embodiment of a second aspect of the present disclosure provides a resource invocation method performed by a first entity, the method including: receiving an authorization code request sent from a resource owner, where the authorization code request is used to request an authorization code; sending the authorization code to the resource owner; receiving the authorization code sent from an API caller; and generating a token based on the authorization code and sending the token to the API caller.

[0015] In some embodiments, the method further includes performing mutual authentication with the resource owner, and if the authentication is successful, establishing a second connection between the resource owner and the first entity, the second connection being a secure connection for transmitting the authorization code request and response.

[0016] In some embodiments, mutually authenticating with the resource owner includes mutually authenticating based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0017] In some embodiments, receiving the authorization code request sent from the resource owner includes at least one of receiving the authorization code request based on the resource owner's real-time consent to the resource authorization request, receiving the authorization code request based on the resource owner's asynchronous consent to the resource authorization request, and receiving a local policy and / or the authorization code request sent from the resource owner and asynchronously consenting to the resource authorization request.

[0018] In some embodiments, receiving the authorization code request sent from the resource owner further includes generating an authorization code if the resource authorization request obtains consent and the API caller obtains authorization for the service.

[0019] In some embodiments, when the resource authorization request obtains consent and the API caller obtains authorization for the service, generating an authorization code includes: when the resource authorization request obtains consent but the API caller does not obtain authorization for the service, determining whether to consent to the service authorization request of the API caller based on a preset policy; and when the service authorization request of the API caller is consented to, generating an authorization code.

[0020] In some embodiments, the method further includes performing mutual authentication with the API caller, and if the authentication is successful, establishing a third connection between the API caller and the first entity, the third connection being a secure connection for transmitting the authorization code.

[0021] In some embodiments, mutually authenticating with the API caller includes mutually authenticating based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0022] In some embodiments, generating a token based on the authorization code and sending the token to the API caller includes at least one of sending an access token and / or a refresh token to the API caller, and receiving a refresh token sent from the API caller and sending an access token to the API caller based on the refresh token.

[0023] In some embodiments, the first entity is a CAPIF core function or an authorization function.

[0024] An embodiment of a third aspect of the present disclosure provides a resource invocation method performed by an API caller, the method including: sending a resource authorization request and / or an API authorization request to a resource owner, where the resource authorization request is used to request, set, or modify a resource of the resource owner; receiving an authorization code sent from the resource owner and sending the authorization code to a first entity; and receiving a token generated by the first entity based on the authorization code.

[0025] In some embodiments, the method further includes performing mutual authentication with the resource owner, and if the authentication is successful, establishing a first connection between the resource owner and the API caller, wherein the first connection is a secure connection for transmitting resource authorization requests and / or API authorization requests.

[0026] In some embodiments, the step of mutually authenticating with the resource owner includes at least one of: if the API caller is a user equipment (UE), performing mutual authentication with the resource owner based on a certificate; and if the API caller is an application function (AF), performing mutual authentication with the resource owner via a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism.

[0027] In some embodiments, sending a resource authorization request and / or an API authorization request to the resource owner includes: if the API caller has obtained authorization for the service, sending a resource authorization request to the resource owner; and if the API caller has not obtained authorization for the service, sending a resource authorization request and an API authorization request to the resource owner, wherein the resource authorization request includes at least one of an identifier of the API caller, an identifier of the resource owner, and a target resource identifier, and the API authorization request includes a service identifier.

[0028] In some embodiments, if the API caller obtains authorization for a service and a resource authorization request sent by the API caller to the resource owner obtains consent, a token generated by the first entity based on the authorization code includes only authorization information related to the resource.

[0029] In some embodiments, the method further includes performing mutual authentication with the first entity, and if the authentication is successful, establishing a third connection between the API caller and the first entity, the third connection being a secure connection for transmitting the authorization code.

[0030] In some embodiments, receiving a token generated by the first entity based on the authorization code includes at least one of receiving an access token and / or a refresh token sent from the first entity, and sending a refresh token to the first entity and receiving an access token sent by the first entity based on the refresh token.

[0031] In some embodiments, the API caller is a User Equipment (UE) or an Application Function (AF), and the resource is the quality of service and / or location information of the resource owner.

[0032] An embodiment of a fourth aspect of the present disclosure provides a resource invocation device, the device being configured to a resource owner, the device including a transceiver module configured to receive a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, the resource authorization request being used to request, set or modify a resource of the resource owner, send an authorization code request to a first entity, the authorization code request being used to request an authorization code, and send the authorization code received from the first entity to the API caller.

[0033] An embodiment of a fifth aspect of the present disclosure provides a resource invocation device, the device being configured to be configured to a first entity, the device including a transceiver module configured to receive an authorization code request sent from a resource owner, where the authorization code request is used to request an authorization code, send the authorization code to the resource owner, receive the authorization code sent from an API caller, generate a token based on the authorization code, and send the token to the API caller.

[0034] An embodiment of a sixth aspect of the present disclosure provides a resource invocation device, the device including: a transceiver module configured to send a resource authorization request and / or an API authorization request to a resource owner, where the resource authorization request is used to request, set, or modify a resource of the resource owner; receive an authorization code sent from the resource owner; send the authorization code to a first entity; and receive a token generated by the first entity based on the authorization code.

[0035] An embodiment of a seventh aspect of the present disclosure provides a communication system, the communication system including: a resource owner, an API caller, and a first entity; The resource owner is configured to execute the resource invocation method according to any one of the embodiments of the first aspect described above; the first entity is configured to execute the resource invocation method according to any one of the embodiments of the second aspect; The API caller is configured to perform the resource calling method of any of the embodiments of the third aspect above.

[0036] An embodiment of an eighth aspect of the present disclosure provides a communication device, including a transceiver, a memory, and a processor, the processors being respectively connected to the transceiver and the memory and configured to control transmission and reception of radio signals by the transceiver by executing computer-executable instructions in the memory, thereby realizing the resource calling method of the embodiment of the first aspect, the embodiment of the second aspect, or the embodiment of the third aspect described above.

[0037] An embodiment of a ninth aspect of the present disclosure provides a computer storage medium having computer-executable instructions stored thereon, which, when executed by a processor, realizes the resource invocation method of the embodiment of the first aspect, the embodiment of the second aspect, or the embodiment of the third aspect described above.

[0038] The embodiments of the present disclosure provide a resource invocation method and device, in which a resource owner receives a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, the resource authorization request is used to request, set, or modify a resource of the resource owner, and sends an authorization code request to a first entity, the authorization code request is used to request an authorization code, and the resource owner can send the authorization code received from the first entity to the API caller. The technical solution provided by the present disclosure enables a UE to authorize the API caller to request a resource of the UE in an API invocation scenario, and prevents data tampering by the resource owner during the authorization process.

[0039] Additional aspects and advantages of the disclosure will be set forth in part in the description that follows, and in part will be obvious from the description, or may be learned through practice of the disclosure. [Brief explanation of the drawings]

[0040] The above and / or additional aspects and advantages of the present disclosure will become more apparent and understandable from the following detailed description of the embodiments taken in conjunction with the drawings. [Figure 1] 1 is a schematic flowchart of a resource invoking method according to an embodiment of the present disclosure; [Figure 2] 1 is a schematic flowchart of a resource invoking method according to an embodiment of the present disclosure; [Figure 3] 1 is a schematic flowchart of a resource invoking method according to an embodiment of the present disclosure; [Figure 4] 1 is a schematic flowchart of a resource invoking method according to an embodiment of the present disclosure; [Figure 5] 1 is a schematic flowchart of a resource invoking method according to an embodiment of the present disclosure; [Figure 6] 1 is a schematic flowchart of a resource invoking method according to an embodiment of the present disclosure; [Figure 7]1 is a schematic diagram of interactions of a resource invocation method according to an embodiment of the present disclosure; [Figure 8] 1 is a schematic diagram of interactions of a resource invocation method according to an embodiment of the present disclosure; [Figure 9] FIG. 1 is a block diagram of a resource calling device according to an embodiment of the present disclosure. [Figure 10] FIG. 1 is a block diagram of a resource calling device according to an embodiment of the present disclosure. [Figure 11] FIG. 1 is a block diagram of a resource calling device according to an embodiment of the present disclosure. [Figure 12] FIG. 1 is a block diagram of a resource calling device according to an embodiment of the present disclosure. [Figure 13] FIG. 1 is a block diagram of a resource calling device according to an embodiment of the present disclosure. [Figure 14] FIG. 1 is a block diagram of a resource calling device according to an embodiment of the present disclosure. [Figure 15] FIG. 1 is a block diagram of a resource calling device according to an embodiment of the present disclosure. [Figure 16] FIG. 1 is a schematic configuration diagram of a communication device provided by an embodiment of the present disclosure. [Figure 17] 1 is a schematic diagram of a chip provided by an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0041] Hereinafter, the embodiments of the present disclosure will be described in detail, and examples of the embodiments are shown in the drawings, and the same or similar reference numerals always represent the same or similar elements, or elements having the same or similar functions. The embodiments described below with reference to the drawings are illustrative and are used to explain the present disclosure, and should not be understood as limiting the present disclosure.

[0042] One of the targets of SNAAPP's security research is obtaining authorization from the resource owner. TS 22.261 [1] Section 6.10.2 specifies that the UE can provide or revoke permission to share information (e.g., location information, presence information, etc.) with third parties. In this case, the UE is the resource owner, and the API caller must obtain the UE's authorization before requesting a resource (e.g., the location information of a specific UE). However, in an API call scenario, there is no mechanism that allows the UE to authorize the API caller to request that resource.

[0043] Therefore, the present disclosure provides a resource invocation method and apparatus, allowing a UE to authorize an API caller to request resources of the UE in an API invocation scenario.

[0044] The resource invoking method and apparatus provided by the present application will be described in detail below in conjunction with the drawings.

[0045] 1 shows a schematic flowchart of a resource calling method according to an embodiment of the present disclosure. The method can be performed by a resource owner, and specifically, the resource owner can be a UE. As shown in FIG. 1, the method can include the following steps S101 to S103.

[0046] In S101, a resource authorization request and / or an API authorization request sent from an API caller is received, and the resource authorization request is used to request, set or modify a resource of a resource owner.

[0047] In the embodiment of the present disclosure, the API caller may be a UE or an application function (AF). The API caller may send a resource authorization request to a resource requester to request the UE to authorize the API caller to make a call on the resource. The resource may be the location information and / or Quality of Service (QoS) of the resource owner.

[0048] In some embodiments of the present disclosure, the resource owner may also receive an API authorization request from the API caller, in which case the API caller has not obtained API authorization.

[0049] In S102, an authorization code request is sent to the first entity, and the authorization code request is used to request an authorization code.

[0050] In an embodiment of the present disclosure, the first entity may be a Common API Framework (CAPIF) Core Function (CCF) or an Authorization Function, and the resource owner may request an authorization code from the first entity by sending an authorization code request to the first entity.

[0051] Note that this authorization code can be understood as a certificate that authorizes the API caller to call the resource owner's resource in an API call scenario.

[0052] In S103, the authorization code received from the first entity is sent to the API caller.

[0053] In an embodiment of the present disclosure, the resource owner receives the requested authorization code from the first entity and sends the authorization code to the API caller, allowing the API caller to perform subsequent processes, such as exchanging a token.

[0054] Furthermore, in the process of authorizing a UE to request a resource from an API caller, the token allows access to the resource without identity authentication, and if the resource owner accesses the token, the resource owner may impersonate the API caller, modify data, and falsely claim that the modification was made by the API caller. Therefore, the present disclosure uses an authorization code to block the resource owner from accessing the token, preventing the resource owner from accessing the token for resource invocation granted to the API caller, thereby ensuring the feasibility and safety of authorizing a UE to request a resource from an API caller.

[0055] As described above, according to the resource calling method provided by the present disclosure, the resource owner receives a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, the resource authorization request is used to request, set or modify the resource owner's resource, and sends an authorization code request to a first entity, which is used to request an authorization code, and the resource owner can send the authorization code received from the first entity to the API caller. The technical solution provided by the present disclosure realizes that in an API calling scenario, the UE authorizes the API caller to request the UE's resource, to avoid data tampering by the resource owner during the authorization process.

[0056] 2 shows a schematic flowchart of a resource invoking method according to an embodiment of the present disclosure. This method can be performed by a resource owner, and based on the embodiment shown in FIG. 1, the method can include the following steps S201 to S208, as shown in FIG.

[0057] In S201, mutual authentication is performed with the API caller.

[0058] In some alternative embodiments, the step of mutually authenticating with the API caller can be performed in the following manner.

[0059] In one embodiment, when the API caller is a user equipment (UE), mutual authentication is performed with the API caller based on the certificate.

[0060] In another embodiment, when the API caller is an application function (AF), mutual authentication is performed by a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism.

[0061] Specifically, the API caller and the resource owner can perform mutual authentication. When the API caller is a UE, mutual authentication can be realized based on certificates. When the API caller is an A, mutual authentication can be realized by a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism.

[0062] In S202, if the authentication is successful, a first connection between the resource owner and the API caller is established.

[0063] In the present disclosure, the first connection is a secure connection for transmitting resource authorization requests and / or API authorization requests.

[0064] The secure connection between the API caller and the resource owner is established after mutual authentication, and may be a secure transport layer (TLS) connection, i.e., a secure connection established based on the TLS protocol.

[0065] In the present disclosure, the purpose of the resource owner performing two-way authentication with the API caller and establishing a secure connection is that the resource caller needs to verify whether the API caller's identity information in the request matches or can be mapped to the verified information. For example, if the resource owner verifies the API caller's mobile phone number, but the corresponding WeChat account in the sent request, the request can also be approved.

[0066] In S203, a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller is received.

[0067] In an embodiment of the present disclosure, a resource authorization request is used to request, set, or modify a resource of a resource owner.

[0068] In the present disclosure, different requests can be sent for different cases, whether the API caller has obtained API authorization or not.

[0069] In one example, when the API caller obtains authorization for the service, a resource authorization request sent from the API caller is received. The resource authorization request includes at least one of an API caller identifier, a resource owner identifier, and a target resource identifier. In other words, when the API caller obtains authorization for the service, the request sent by the API caller to the resource owner includes the API caller's identity identifier (e.g., GPSI, IMPI, or application layer ID), the resource owner's (e.g., referred to as target UE) identity identifier (e.g., GPSI, IMPI, or application layer ID), and the target resource identifier (e.g., the location of the target UE, the QoS of the target UE).

[0070] In another example, when the API caller has not obtained authorization for the service, a resource authorization request and an API authorization request sent from the API caller are received. The resource authorization request includes at least one of an API caller identifier, a resource owner identifier, and a target resource identifier, and the API authorization request includes a service identifier. In other words, when the API caller has not obtained authorization for the service, the request sent by the API caller to the resource owner further includes a service identifier in addition to the API caller's identity identifier, the target UE's identity identifier, and the target resource identifier.

[0071] In an embodiment of the present disclosure, the service identifier includes at least one of a service name identifier, a service operation identifier, an operation semantics identifier, and an API identifier.

[0072] It should be noted that if the API caller obtains authorization for a service, i.e., the API caller only sends a resource authorization request, and the resource authorization request sent by the API caller to the resource owner obtains consent, the token generated by the first entity based on the authorization code only includes authorization information related to the resource.

[0073] In S204, mutual authentication is performed with the first entity.

[0074] In an embodiment of the present disclosure, the resource owner can mutually authenticate with the first entity based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0075] Specifically, different authentication policies can be adopted for different cases where the first entity is a CCF and an Authorization Function. For the case where the first entity is a CCF, the resource owner can authenticate the CCF with a certificate, and then the CCF can authenticate the resource owner using a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism. The CCF can further generate a certificate and an OAuth 2.0 token for the resource owner after authentication. For the case where the first entity is an Authorization Function, the resource owner can authenticate the Authorization Function with a certificate, and then the Authorization Function can authenticate the resource owner using TLS-PSK, an OAuth token-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism, and a certificate can be assigned by the CCF.

[0076] In S205, if the authentication is successful, a second connection between the resource owner and the first entity is established.

[0077] The second connection is a secure connection for transmitting the authorization code request and response. Note that the secure connection between the resource owner and the CCF / Authorization Function is established after mutual authentication. This secure connection may be a TLS connection, i.e., a secure connection established based on the TLS protocol.

[0078] In S206, an authorization code request is sent to the first entity.

[0079] In the embodiments of the present disclosure, the resource owner may implement sending the authorization code request to the first entity in a synchronous or asynchronous manner.

[0080] For the synchronous case, in one example, the resource owner agrees to the resource authorization request in real time and sends an authorization code request to the first entity. In other words, the resource owner can grant the authorization request for the resource in a timely and synchronous manner. The resource owner sends the authorization request and authorization information to the first entity and requests an authorization code.

[0081] In contrast to the asynchronous case, in another example, the resource owner asynchronously approves the resource authorization request based on the resource owner's local policy and sends an authorization code request to the first entity. In other words, the resource owner can asynchronously grant the authorization request for the resource based on a locally pre-generated configuration file without needing to respond in real time. The resource owner sends the authorization request and authorization information to the first entity and requests an authorization code.

[0082] For another asynchronous case, in another example, the resource owner sends a local policy and / or an authorization code request to the first entity, and the local policy is used to help the first entity asynchronously approve the resource authorization request. In other words, if the resource owner previously sent a pre-generated configuration file to the first entity, the resource owner sends an authorization request to the first entity to request an authorization code. The first entity can approve the resource authorization request based on the pre-generated file. Note that there is no priority or binding relationship between the sending of the authorization code request and the sending of the local policy. The resource owner can send the local policy before, after, or at the same time as sending the authorization code request, and this disclosure is not limited thereto.

[0083] In S207, the authorization code sent from the first entity is received.

[0084] Specifically, if the resource authorization request is approved and the API caller is authorized for the service, the resource owner receives the authorization code sent by the first entity.

[0085] Whether to send an authorization code is determined by the first entity. In other words, only when both resource access and API authorization are consented to does the first entity generate and send an authorization code to the resource owner. Specifically, when an API caller obtains authorization for a service, the first entity generates an authorization code for the API caller if the API caller is authorized to request a resource. In other words, when resource access is consented to and the API caller has not requested authorization related to the API (API authorization has been obtained in advance and there is no need to request it again), the first entity directly sends the authorization code to make a resource request. When the API caller has not obtained authorization for the service, the first entity checks whether the API caller is authorized to call the service based on a preset policy. If the API caller is authorized to call the service and resource, the first entity generates an authorization code for the API; that is, if the resource access has obtained consent but the API caller requires API authorization, the first entity can determine whether the API caller can access this API based on the operator's preset policy, and if the API caller can access it, the first entity generates and sends the authorization code; if the API caller cannot access it, the first entity does not send it.

[0086] In S208, the authorization code is sent to the API caller.

[0087] In an embodiment of the present disclosure, after receiving the authorization code sent from the first entity, the resource owner sends the authorization code to the API caller for subsequent token exchange.

[0088] It should be noted that the above steps S201, S202, S204 and S205 are optional steps, in other words, the request and response messages in the present disclosure can be transmitted without identity authentication and establishment of a secure connection.

[0089] As described above, according to the resource calling method provided by the present disclosure, a resource owner can perform two-way authentication with an API caller and a first entity, the resource owner can receive a resource authorization request and / or an API authorization request sent from the application programming interface (API) caller and send an authorization code request to the first entity, the authorization code request is used to request an authorization code, and the resource owner can send the authorization code received from the first entity to the API caller. The technical solution provided by the present disclosure realizes that in an API calling scenario, a UE authorizes an API caller to request a resource of the UE, to prevent data tampering by the resource owner during the authorization process.

[0090] 3 shows a schematic flowchart of a resource invocation method according to an embodiment of the present disclosure. The method can be performed by a first entity, and specifically, as described above, the first entity can be a CCF or an Authorization Function. As shown in FIG. 3, the method can include the following steps S301 to S304.

[0091] In S301, an authorization code request sent from a resource owner is received.

[0092] In this disclosure, an authorization code request is used to request an authorization code, which can be understood as a certificate that authorizes an API caller to invoke a resource of a resource owner in an API invocation scenario.

[0093] In S302, an authorization code is sent to the resource owner.

[0094] In an embodiment of the present disclosure, the first entity can generate and send an authorization code to the resource owner if certain conditions are met, where the certain conditions refer to both resource access and API authorization being agreed upon.

[0095] In S303, the authorization code sent from the API caller is received.

[0096] In an embodiment of the present disclosure, the authorization code is sent to the resource owner, and then sent by the resource owner to the API caller, and the first entity receives the authorization code from the API caller and exchanges it for a token.

[0097] In S304, a token is generated based on the authorization code and sent to the API caller.

[0098] In an embodiment of the present disclosure, the first entity generates a token based on the authorization code and sends the token to the API caller for the API caller to perform subsequent processes.

[0099] As described above, according to the resource calling method provided by the present disclosure, the first entity can receive an authorization code request sent by the resource owner, generate an authorization code in response to the request and send it to the resource owner, receive the authorization code sent by the API caller, generate a token based on the authorization code and provide it to the API caller.The technical solution provided by the present disclosure realizes that in an API calling scenario, the UE authorizes the API caller to request the UE's resources, so as to prevent the resource owner from tampering with data during the authorization process.

[0100] FIG. 4 shows a schematic flowchart of a resource invocation method according to an embodiment of the present disclosure, which can be performed by a first entity. Based on the embodiment of FIG. 3, as shown in FIG. 4, the method can include the following steps S401 to S409:

[0101] In S401, mutual authentication is performed with the resource owner.

[0102] In an embodiment of the present disclosure, the first entity can mutually authenticate with the resource owner based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0103] Specifically, different authentication policies can be adopted for different cases where the first entity is a CCF and an Authorization Function. For the case where the first entity is a CCF, the resource owner can authenticate the CCF with a certificate, and then the CCF can authenticate the resource owner using a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism. The CCF can further generate a certificate and an OAuth 2.0 token for the resource owner after authentication. For the case where the first entity is an Authorization Function, the resource owner can authenticate the Authorization Function with a certificate, and then the Authorization Function can authenticate the resource owner using TLS-PSK, an OAuth token-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism, and a certificate can be assigned by the CCF.

[0104] In S402, if the authentication is successful, a second connection between the resource owner and the first entity is established.

[0105] The second connection is a secure connection for transmitting the authorization code request and response. Note that the secure connection between the resource owner and the CCF / Authorization Function is established after mutual authentication. The secure connection can be established by TLS. This secure connection may be a TLS connection, i.e., a secure connection established based on the TLS protocol.

[0106] In S403, an authorization code request sent from the resource owner is received.

[0107] In the embodiments of the present disclosure, the resource owner can realize sending the authorization code request to the first entity in a synchronous or asynchronous manner, in other words, the resource owner can process the resource request in different manners.

[0108] 1. The resource owner consents to the request based on local policy.

[0109] For the synchronous case, in one example, the first entity receives an authorization code request based on real-time consent to the resource authorization request from the resource owner. The resource owner consents to the resource authorization request in real-time and sends an authorization code request to the first entity. In other words, the resource owner can grant the authorization request for the resource in a timely and synchronous manner. The resource owner sends the authorization request and authorization information to the first entity to request an authorization code.

[0110] 2. The resource owner agrees to the request in real time.

[0111] In another example, in contrast to the asynchronous case, the first entity can receive an authorization code request based on asynchronous consent to the resource authorization request from the resource owner. The resource owner asynchronously consents to the resource authorization request based on the resource owner's local policy and sends an authorization code request to the first entity. In other words, the resource owner can asynchronously grant the authorization request for the resource based on a locally pre-generated configuration file without needing to respond in real time. The resource owner sends the authorization request and authorization information to the first entity and requests an authorization code.

[0112] 3. The resource owner sends the policy to the CCF / Authorization Function, which unifies the request based on the policy.

[0113] In another example, for another asynchronous case, the first entity receives a local policy and / or authorization code request sent from the resource owner and asynchronously accepts the resource authorization request. The resource owner sends a local policy and / or authorization code request to the first entity, and the local policy is used to help the first entity accept the resource authorization request asynchronously. In other words, if the resource owner previously sent a pre-generated configuration file to the first entity, the resource owner sends an authorization request to the first entity to request an authorization code. The first entity can approve the resource authorization request based on the pre-generated file. Note that there is no priority or binding relationship between the transmission of the authorization code request and the transmission of the local policy. The resource owner can send the local policy before, after, or at the same time as sending the authorization code request, and this disclosure is not limited thereto.

[0114] In S404, if the resource authorization request obtains consent and the API caller obtains authorization for the service, an authorization code is generated.

[0115] Specifically, if the resource authorization request is authorized and the API caller is authorized for the service, the first entity generates an authorization code.

[0116] Note that whether to generate an authorization code is determined by the first entity; in other words, the first entity generates and sends an authorization code to the resource owner only when both resource access and API authorization are consented to. Specifically, when an API caller obtains authorization for a service, the first entity generates an authorization code for the API caller if the API caller is authorized to request a resource; that is, when resource access is consented to and the API caller has not requested authorization related to the API (API authorization has been obtained in advance and there is no need to request it again), the first entity directly sends the authorization code to make a resource request.

[0117] Specifically, this step further includes the steps of: if the resource authorization request has been consented to but the API caller has not been authorized for the service, determining whether to consent to the service authorization request of the API caller based on a preset policy; and if the service authorization request of the API caller is consented to, generating an authorization code.

[0118] In other words, if the API caller has not obtained authorization for the service, the first entity checks whether the API caller is authorized to call the service based on a preset policy. If the API caller is authorized to call the service and resource, the first entity generates an authorization code for the API. That is, if the resource access has obtained consent but the API caller requires API authorization, the first entity can determine whether the API caller can access this API based on the operator's preset policy. If the API caller can access it, the first entity generates and sends the authorization code; if the API caller cannot access it, the first entity does not send it.

[0119] In S405, an authorization code is sent to the resource owner.

[0120] In an embodiment of the present disclosure, if a certain condition is met, the first entity can generate and send an authorization code to the resource owner. As described in the previous step, the certain condition refers to both resource access and API authorization being agreed upon.

[0121] In S406, mutual authentication is performed with the API caller.

[0122] In an embodiment of the present disclosure, the first entity can perform mutual authentication with the API caller based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0123] Specifically, different authentication policies can be adopted for different cases where the first entity is a CCF and an Authorization Function. For the case where the first entity is a CCF, the resource owner can authenticate the CCF with a certificate, and then the CCF can authenticate the resource owner using a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism. The CCF can further generate a certificate and an OAuth 2.0 token for the resource owner after authentication. For the case where the first entity is an Authorization Function, the resource owner can authenticate the Authorization Function with a certificate, and then the Authorization Function can authenticate the resource owner using TLS-PSK, an OAuth token-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism, and a certificate can be assigned by the CCF.

[0124] In S407, if the authentication is successful, a third connection between the API caller and the first entity is established.

[0125] The third connection is a secure connection for transmitting the authorization code, which is established after mutual authentication and may be a TLS connection, i.e., a secure connection established based on the TLS protocol.

[0126] In S408, the authorization code sent from the API caller is received.

[0127] In an embodiment of the present disclosure, the first entity can receive an authorization code sent from an API caller, where the first entity sends the authorization code to the resource owner, and then the resource owner sends the authorization code to the API caller, which then sends the authorization code to the first entity, which can then be used for a subsequent token exchange.

[0128] In S409, a token is generated based on the authorization code and sent to the API caller.

[0129] In an embodiment of the present disclosure, the first entity can generate a token and send it to the API caller in the following manner.

[0130] In one example, the first entity sends an access token and / or a refresh token to the API caller.

[0131] In another example, the first entity receives a refresh token sent from the API caller and sends an access token to the API caller based on the refresh token.

[0132] In other words, the first entity can send the refresh token / access token directly to the API caller, or the API caller can send the refresh token to the first entity to obtain the access token.

[0133] In an embodiment of the present disclosure, the access token includes at least one of a CCF identity identifier (e.g., NF instance ID, NF ID), an Authorization Function identity identifier (e.g., NF instance ID, NF ID), a second entity identity identifier (e.g., NF instance ID, NF ID), a service identifier, an API caller identity identifier (e.g., GPSI, IMSI, application layer ID), a resource owner identity identifier (e.g., GPSI, IMSI, application layer ID), a resource identifier (e.g., location), and an expiration time, and the second entity is an API Exposing Function (AEF).

[0134] It should be noted that the above steps S401, S402, S406 and S407 are optional steps, in other words, the request and response messages in the present disclosure can be transmitted without identity authentication and establishment of a secure connection.

[0135] As described above, according to the resource invocation method provided by the present disclosure, the first entity resource can perform two-way authentication with the resource owner and the API caller, and the first entity can receive an authorization code request sent by the resource owner, generate an authorization code in response to the request and send it to the resource owner, receive the authorization code sent by the API caller, and generate a token based on the authorization code and provide it to the API caller.The technical solution provided by the present disclosure realizes that in an API invocation scenario, the UE authorizes the API caller to request the UE's resource, to prevent data tampering by the resource owner during the authorization process.

[0136] 5 shows a schematic flowchart of a resource calling method according to an embodiment of the present disclosure. The method can be performed by an API caller, and as described above, the API caller can be a UE or an application function (AF). As shown in FIG. 5, the method can include the following steps S501 to S503.

[0137] In S501, a resource authorization request and / or an API authorization request is sent to a resource owner.

[0138] In the present disclosure, a resource authorization request is used to request, set, or modify resources of a resource owner, which may be location information and / or Quality of Service (QoS) of the resource owner.

[0139] In an embodiment of the present disclosure, when an API caller is a different entity, the requested resource may include different content. Specifically, when the API caller is a UE, the resource may include a UE parameter in a Personal Internet of Things (PIN). For example, when the UE is a PIN element with management capability, the resource may be a QoS of a PEMC. When the UE is a PIN element with gateway capability, the resource may be a QoS of a PEGC. When the UE is a PEGC, the resource may be a QoS of a PIN element under the PEGC. This is not a limitation of the present disclosure.

[0140] In some embodiments of the present disclosure, the API caller can further send an API authorization request to the resource owner if the API caller has not obtained API authorization.

[0141] In S502, receive an authorization code sent from a resource owner and send the authorization code to a first entity.

[0142] Note that this authorization code can be understood as a certificate that authorizes the API caller to call the resource owner's resource in an API call scenario.

[0143] In an embodiment of the present disclosure, if a certain condition is met, the first entity can generate and send an authorization code to the resource owner. The certain condition refers to both resource access and API authorization being agreed upon. The resource owner then sends the authorization code to the API caller. After the API caller receives the authorization code, the authorization code can be sent to the first entity to exchange for a token.

[0144] At S503, a token generated by the first entity based on the authorization code is received.

[0145] In an embodiment of the present disclosure, the first entity generates a token based on the authorization code and sends the token to the API caller for the API caller to perform subsequent processes.

[0146] As described above, according to the resource calling method provided by the present disclosure, an API caller sends a resource authorization request and / or an API authorization request to a resource owner, where the resource authorization request is used to request, set, or modify a resource of the resource owner, receives an authorization code sent from the resource owner, sends the authorization code to a first entity, and receives a token generated by the first entity based on the authorization code. The technical solution provided by the present disclosure realizes, in an API calling scenario, that a UE authorizes an API caller to request a resource of the UE, in order to prevent data tampering by the resource owner during the authorization process.

[0147] 6 shows a schematic flowchart of a resource calling method according to an embodiment of the present disclosure. Based on the embodiment of FIG. 5, the method is performed by an API caller. As shown in FIG. 6, the method may include the following steps S601 to S612.

[0148] In S601, mutual authentication is performed with the resource owner.

[0149] In the embodiment of the present disclosure, the step of mutual authentication between the API caller and the resource owner can be performed in the following manner.

[0150] In one embodiment, when the API caller is a user equipment (UE), mutual authentication is performed with the API caller based on the certificate.

[0151] In another embodiment, when the API caller is an application function (AF), mutual authentication is performed by a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism.

[0152] Specifically, the API caller and the resource owner can perform mutual authentication. When the API caller is a UE, mutual authentication can be realized based on certificates. When the API caller is an A, mutual authentication can be realized by a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism.

[0153] In S602, if the authentication is successful, a first connection between the resource owner and the API caller is established.

[0154] In the present disclosure, the first connection is a secure connection for transmitting resource authorization requests and / or API authorization requests.

[0155] The secure connection between the API caller and the resource owner is established after mutual authentication, and may be a TLS connection, i.e., a secure connection established based on the TLS protocol.

[0156] In the present disclosure, the purpose of the resource owner performing two-way authentication with the API caller and establishing a secure connection is that the resource caller needs to verify whether the API caller's identity information in the request matches or can be mapped to the verified information. For example, if the resource owner verifies the API caller's mobile phone number, but the corresponding WeChat account in the sent request, the request can also be approved.

[0157] In S603, a resource authorization request and / or an API authorization request is sent to the resource owner.

[0158] In an embodiment of the present disclosure, a resource authorization request is used to request, set, or modify a resource of a resource owner.

[0159] In the present disclosure, different requests can be sent for different cases, whether the API caller has obtained API authorization or not.

[0160] In one example, when the API caller obtains authorization for the service, a resource authorization request sent from the API caller is received. The resource authorization request includes at least one of an API caller identifier, a resource owner identifier, and a target resource identifier. In other words, when the API caller obtains authorization for the service, the request sent by the API caller to the resource owner includes the API caller's identity identifier (e.g., GPSI, IMPI, or application layer ID), the resource owner's (e.g., referred to as target UE) identity identifier (e.g., GPSI, IMPI, or application layer ID), and the target resource identifier (e.g., the location of the target UE, the QoS of the target UE).

[0161] In another example, when the API caller has not obtained authorization for the service, a resource authorization request and an API authorization request sent from the API caller are received. The resource authorization request includes at least one of an API caller identifier, a resource owner identifier, and a target resource identifier, and the API authorization request includes a service identifier. In other words, when the API caller has not obtained authorization for the service, the request sent by the API caller to the resource owner further includes a service identifier in addition to the API caller's identity identifier, the target UE's identity identifier, and the target resource identifier.

[0162] If the API caller obtains authorization for a service, i.e., if the API caller only sends a resource authorization request, and the resource authorization request sent by the API caller to the resource owner obtains consent, the token generated by the first entity based on the authorization code includes only authorization information related to the resource. In S604, the authorization code sent from the resource owner is received.

[0163] The authorization code is generated by the first entity and sent to the resource owner when certain conditions are met, where the certain conditions indicate that both resource access and API authorization are agreed upon. The resource owner sends the authorization code to the API caller for exchange for a token.

[0164] In S605, mutual authentication is performed with the first entity.

[0165] In an embodiment of the present disclosure, the first entity can perform mutual authentication with the API caller based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0166] Specifically, different authentication policies can be adopted for different cases where the first entity is a CCF and an Authorization Function. For the case where the first entity is a CCF, the resource owner can authenticate the CCF with a certificate, and then the CCF can authenticate the resource owner using a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism. The CCF can further generate a certificate and an OAuth 2.0 token for the resource owner after authentication. For the case where the first entity is an Authorization Function, the resource owner can authenticate the Authorization Function with a certificate, and then the Authorization Function can authenticate the resource owner using TLS-PSK, an OAuth token-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism, and a certificate can be assigned by the CCF.

[0167] In S606, if the authentication is successful, a third connection between the API caller and the first entity is established.

[0168] The third connection is a secure connection for transmitting the authorization code, which is established after mutual authentication and may be a TLS connection, i.e., a secure connection established based on the TLS protocol.

[0169] In S607, the authorization code is sent to the first entity.

[0170] In an embodiment of the present disclosure, the first entity can receive an authorization code sent from the API caller for exchange for a token.

[0171] At S608, a token generated by the first entity based on the authorization code is received.

[0172] In an embodiment of the present disclosure, the first entity can generate a token and send it to the API caller in the following manner.

[0173] In one example, the first entity sends an access token and / or a refresh token to the API caller.

[0174] In another example, the first entity receives a refresh token sent from the API caller and sends an access token to the API caller based on the refresh token.

[0175] In other words, the first entity can send the refresh token / access token directly to the API caller, or the API caller can send the refresh token to the first entity to obtain the access token.

[0176] In an embodiment of the present disclosure, the access token includes at least one of a CCF identity identifier (e.g., NF instance ID, NF ID), an Authorization Function identity identifier (e.g., NF instance ID, NF ID), a second entity identity identifier (e.g., NF instance ID, NF ID), a service identifier, an API caller identity identifier (e.g., GPSI, IMSI, application layer ID), a resource owner identity identifier (e.g., GPSI, IMSI, application layer ID), a resource identifier (e.g., location), and an expiration date, and the second entity is an AEF.

[0177] In a subsequent step, the API caller interacts with a second entity.

[0178] In S609, mutual authentication is performed with the second entity.

[0179] In an embodiment of the present disclosure, the API caller and the AEF can perform mutual authentication based on TLS-PSK, an OAuth token-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism.

[0180] In S610, if the authentication is successful, a fourth connection is established between the API caller and the second entity.

[0181] The fourth connection is a secure connection between the API caller and the AEF, which is established after mutual authentication, and may be a TLS connection, i.e., a secure connection established based on the TLS protocol.

[0182] In S611, a service invocation request is sent to a second entity.

[0183] In an embodiment of the present disclosure, a service invocation request sent by an API caller to an AEF includes an identity identifier of the API caller, an identity identifier of a resource owner, a service identifier that needs to be invoked, a user resource identifier that the API caller needs to access, and an access token.

[0184] At S612, an authorization response sent from the second entity is received.

[0185] In an embodiment of the present disclosure, the AEF can authorize the request based on the token and send a response to the API caller.

[0186] It should be noted that the above steps S601, S602, S605, S606, S609, and S610 are optional steps, in other words, the request and response messages in the present disclosure can be transmitted without identity authentication and establishment of a secure connection.

[0187] As described above, according to the resource calling method provided by the present disclosure, an API caller can perform two-way authentication with a resource owner, a first entity, and a second entity, and the API caller can send a resource authorization request and / or an API authorization request to the resource owner, where the resource authorization request is used to request, set, or modify a resource of the resource owner, receive an authorization code sent from the resource owner, send the authorization code to the first entity, and receive a token generated by the first entity based on the authorization code. The technical solution provided by the present disclosure realizes, in an API calling scenario, that a UE authorizes an API caller to request a resource of the UE, in order to prevent data tampering by the resource owner during the authorization process.

[0188] 7 illustrates a schematic diagram of interactions of a resource invocation method according to an embodiment of the present disclosure. The method can be performed by a communication system including at least a resource owner, a first entity, and an API caller. As shown in FIG. 7, the method can include the following steps S701 to S707.

[0189] In S701, a first entity sends a resource authorization request and / or an API authorization request to a resource owner.

[0190] At S702, the resource owner sends an authorization code request to the first entity.

[0191] In S703, the first entity sends an authorization code to the resource owner.

[0192] In S704, the resource owner sends an authorization code to the API caller.

[0193] In S705, the API caller sends the authorization code to the first entity.

[0194] At S706, the first entity generates a token based on the authorization code.

[0195] In S707, the first entity sends the token to the API caller.

[0196] The principles of the above steps are the same as those of the embodiment shown in FIGS. 1 to 6, and therefore will not be described here.

[0197] As described above, according to the resource invocation method provided by the present disclosure, through the interaction between the API caller, the resource owner, and the first entity, in an API invocation scenario, the UE authorizes the API caller to request resources of the UE, so as to avoid data tampering by the resource owner during the authorization process.

[0198] 8 illustrates a schematic diagram of interactions of a resource invocation method according to an embodiment of the present disclosure. The method can be performed by a communication system, which includes at least a resource owner, a first entity, an API caller, and a second entity based on the embodiment illustrated in FIG. 7. As shown in FIG. 8, the method can include the following steps S801 to S815.

[0199] In S801, mutual authentication is performed between the API caller and the resource owner, and if the authentication is successful, a first connection between the resource owner and the API caller is established.

[0200] In S802, the API caller sends a resource authorization request and / or an API authorization request to the resource owner.

[0201] In S803, mutual authentication is performed between the first entity and the resource owner, and if the authentication is successful, a second connection between the resource owner and the first entity is established.

[0202] At S804, the resource owner sends an authorization code request to the first entity.

[0203] In S805, the first entity generates an authorization code.

[0204] At S806, the first entity sends the authorization code to the resource owner.

[0205] In S807, the resource owner sends the authorization code to the API caller.

[0206] In S808, mutual authentication is performed between the API caller and the first entity, and if the authentication is successful, a third connection between the API caller and the first entity is established.

[0207] In S809, the API caller sends the authorization code to the first entity.

[0208] At S810, the first entity generates a token based on the authorization code.

[0209] In S811, the first entity sends the token to the API caller.

[0210] In S812, mutual authentication is performed between the API caller and the second entity, and if the authentication is successful, a fourth connection between the API caller and the second entity is established.

[0211] In S813, the API caller sends a service call request to the second entity.

[0212] At S814, the second entity authorizes the request based on the token.

[0213] In S815, the second entity sends an authorization response to the API caller.

[0214] The principles of the above steps are the same as those of the embodiment shown in FIGS. 1 to 7, and therefore will not be described here.

[0215] It should be noted that the above steps S801, S803, S808 and S812 are optional steps, in other words, the request and response messages in the present disclosure can be transmitted without identity authentication and establishment of a secure connection.

[0216] As described above, according to the resource invocation method provided by the present disclosure, through interactions between the API caller, the resource owner, the first entity, and the second entity, in an API invocation scenario, the UE authorizes the API caller to request resources of the UE, so as to avoid data tampering by the resource owner during the authorization process.

[0217] In the above embodiments provided by the present application, the methods provided by the embodiments of the present application are described from the perspectives of a resource owner, an API caller, and a first entity, respectively. To realize each function in the methods provided by the above embodiments of the present application, the resource owner, the API caller, and the first entity may include a hardware structure or a software module, and each of the above functions may be realized in the form of a hardware structure, a software module, or a combination of a hardware structure and a software module. Some of the above functions may be performed in the form of a hardware structure, a software module, or a combination of a hardware structure and a software module.

[0218] Corresponding to the resource invocation method provided by the above several embodiments, the present disclosure further provides a resource invocation device, and since the resource invocation device provided by the embodiments of the present disclosure corresponds to the resource invocation method provided by the above several embodiments, the embodiments of the resource invocation method also apply to the resource invocation device provided by this embodiment, and the description will be omitted in this embodiment.

[0219] FIG. 9 is a schematic structural diagram of a resource invoking device 900 provided by an embodiment of the present disclosure, which is set by a resource owner.

[0220] As shown in FIG. 9 , the apparatus 900 includes a transceiver module 910, which receives a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, where the resource authorization request is used to request, set, or modify a resource of a resource owner, sends an authorization code request to a first entity, where the authorization code request is used to request an authorization code, and sends the authorization code received from the first entity to the API caller.

[0221] According to the resource calling device provided by the present disclosure, a resource owner receives a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, the resource authorization request is used to request, set or modify a resource of the resource owner, and can send an authorization code request to a first entity, the authorization code request is used to request an authorization code, and the resource owner can send the authorization code received from the first entity to the API caller. The technical solution provided by the present disclosure realizes that in an API calling scenario, a UE authorizes an API caller to request a resource of the UE, to avoid data tampering by the resource owner during the authorization process.

[0222] In some embodiments, as shown in FIG. 10 , the apparatus 900 further includes an authentication module 920, which performs mutual authentication with the API caller, and if the authentication is successful, establishes a first connection between the resource owner and the API caller.

[0223] In some embodiments, the authentication module 920 further performs at least one of: performing mutual authentication with the API caller based on a certificate if the API caller is a user equipment (UE); and performing mutual authentication using a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism if the API caller is an application function (AF).

[0224] In some embodiments, the transceiver module 910 further receives a resource authorization request sent from the API caller if the API caller has obtained authorization for the service, and receives a resource authorization request and an API authorization request sent from the API caller if the API caller has not obtained authorization for the service, wherein the resource authorization request includes at least one of an API caller identifier, a resource owner identifier, and a target resource identifier, and the API authorization request includes a service identifier.

[0225] In some embodiments, the authentication module 920 further performs mutual authentication with the first entity, and if the authentication is successful, establishes a second connection between the resource owner and the first entity, the second connection being a secure connection for transmitting the authorization code request and response.

[0226] In some embodiments, the authentication module 920 further performs mutual authentication based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0227] In some embodiments, the transceiver module 910 further agrees to the resource authorization request in real time and sends an authorization code request to the first entity; agrees to the resource authorization request asynchronously based on a local policy of the resource owner and sends the authorization code request to the first entity; and sends the local policy and / or the authorization code request to the first entity, wherein the local policy is used to assist the first entity in agreeing to the resource authorization request asynchronously.

[0228] In some embodiments, the transceiver module 910 further receives an authorization code sent from the first entity if the resource authorization request is authorized and the API caller is authorized for the service.

[0229] In some embodiments, the resource owner is a user equipment (UE) and the resource is quality of service and / or location information of the UE.

[0230] As described above, the resource calling device provided by the present disclosure enables a resource owner to perform two-way authentication with an API caller and a first entity, the resource owner can receive a resource authorization request and / or an API authorization request sent from the application programming interface (API) caller and send an authorization code request to the first entity, the authorization code request is used to request an authorization code, and the resource owner can send the authorization code received from the first entity to the API caller. The technical solution provided by the present disclosure realizes, in an API calling scenario, that a UE authorizes an API caller to request a resource of the UE, to prevent data tampering by the resource owner during the authorization process.

[0231] FIG. 11 is a schematic structural diagram of a resource invoking device 1100 provided by an embodiment of the present disclosure, and the resource invoking device 1100 is configured as a first entity.

[0232] As shown in FIG. 11 , the apparatus 1100 includes a transceiver module 1110, which receives an authorization code request sent from a resource owner, where the authorization code request is used to request an authorization code, sends the authorization code to the resource owner, receives an authorization code sent from an API caller, generates a token based on the authorization code, and sends the token to the API caller.

[0233] According to the resource invocation device provided by the present disclosure, a first entity can receive an authorization code request sent from a resource owner, generate an authorization code in response to the request and send it to the resource owner, receive an authorization code sent from an API caller, generate a token based on the authorization code and provide it to the API caller.The technical solution provided by the present disclosure realizes that in an API invocation scenario, a UE authorizes an API caller to request a resource of the UE, so as to prevent data tampering by the resource owner during the authorization process.

[0234] In some embodiments, as shown in FIG. 12 , the apparatus 1100 further includes an authentication module 1120, which performs mutual authentication with the resource owner, and if the authentication is successful, establishes a second connection between the resource owner and the first entity, where the second connection is a secure connection for transmitting the authorization code request and response.

[0235] In some embodiments, the authentication module 1120 further performs mutual authentication based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0236] In some embodiments, the transceiver module 1110 further receives an authorization code request based on a resource owner's real-time consent to a resource authorization request, receives an authorization code request based on a resource owner's asynchronous consent to a resource authorization request, receives a local policy and / or an authorization code request sent from the resource owner, and asynchronously consents to a resource authorization request.

[0237] In some embodiments, the transceiver module 1110 further generates an authorization code if the resource authorization request obtains consent and the API caller obtains authorization for the service.

[0238] In some embodiments, as shown in FIG. 13 , the apparatus 1100 further includes an authorization module 1130. When the resource authorization request has been consented but the API caller has not been authorized for the service, the authorization module 1130 determines whether to consent to the service authorization request of the API caller based on a preset policy, and generates an authorization code if the service authorization request of the API caller is consented to.

[0239] In some embodiments, the authentication module 1120 further performs mutual authentication with the API caller, and if the authentication is successful, establishes a third connection between the API caller and the first entity, the third connection being a secure connection for transmitting the authorization code.

[0240] In some embodiments, the authentication module 1120 further performs mutual authentication based on at least one of a certificate-based authentication mechanism, a GBA-based authentication mechanism, an AKMA-based authentication mechanism, TLS-PSK, and an OAuth token-based authentication mechanism.

[0241] In some embodiments, the transceiver module 1110 further performs at least one of sending an access token and / or a refresh token to the API caller, and receiving a refresh token sent from the API caller and sending an access token to the API caller based on the refresh token.

[0242] In some embodiments, the first entity is a CAPIF core function or an authorization function.

[0243] According to the resource invocation device provided by the present disclosure, a first entity resource can perform two-way authentication with a resource owner and an API caller, and the first entity can receive an authorization code request sent from the resource owner, generate an authorization code in response to the request and send it to the resource owner, receive the authorization code sent from the API caller, generate a token based on the authorization code and provide it to the API caller.The technical solution provided by the present disclosure realizes that in an API invocation scenario, a UE authorizes an API caller to request a resource of the UE, to prevent data tampering by the resource owner during the authorization process.

[0244] FIG. 14 is a schematic diagram of a resource calling device 1400 provided by an embodiment of the present disclosure, and the resource calling device 1400 is set as an API call source.

[0245] As shown in FIG. 14 , the apparatus 1400 includes a transceiver module 1410, which sends a resource authorization request and / or an API authorization request to a resource owner, where the resource authorization request is used to request, set, or modify a resource of the resource owner, receives an authorization code sent from the resource owner, sends the authorization code to a first entity, and receives a token generated by the first entity based on the authorization code.

[0246] According to the resource calling device provided by the present disclosure, an API caller can send a resource authorization request and / or an API authorization request to a resource owner, where the resource authorization request is used to request, set, or modify a resource of the resource owner, receive an authorization code sent from the resource owner, send the authorization code to a first entity, and receive a token generated by the first entity based on the authorization code.The technical solution provided by the present disclosure realizes that in an API calling scenario, a UE authorizes an API caller to request a resource of the UE, to prevent data tampering by the resource owner during the authorization process.

[0247] In some embodiments, as shown in FIG. 15 , the apparatus 1400 further includes an authentication module 1420, which performs mutual authentication with the resource owner, and if the authentication is successful, establishes a first connection between the resource owner and the API caller, where the first connection is a secure connection for transmitting a resource authorization request and / or an API authorization request.

[0248] In some embodiments, the authentication module 1420 further performs at least one of: performing mutual authentication with the resource owner based on a certificate if the API caller is a user equipment (UE); and performing mutual authentication with the resource owner through a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism if the API caller is an application function (AF).

[0249] In some embodiments, the transceiver module 1410 further sends a resource authorization request to the resource owner if the API caller has obtained authorization for the service, and sends a resource authorization request and an API authorization request to the resource owner if the API caller has not obtained authorization for the service, wherein the resource authorization request includes at least one of the API caller identifier, the resource owner identifier, and the target resource identifier, and the API authorization request includes a service identifier.

[0250] In some embodiments, the authentication module 1420 further performs mutual authentication with the first entity, and if the authentication is successful, establishes a third connection between the API caller and the first entity, the third connection being a secure connection for transmitting the authorization code.

[0251] In some embodiments, the transceiver module 1410 further performs at least one of receiving an access token and / or a refresh token sent from the first entity, sending a refresh token to the first entity, and receiving an access token sent by the first entity based on the refresh token.

[0252] In some embodiments, the API caller is a User Equipment (UE) or an Application Function (AF), and the resource is the quality of service and / or location information of the resource owner.

[0253] According to the resource calling device provided by the present disclosure, an API caller can perform two-way authentication with a resource owner, a first entity, and a second entity, and the API caller can send a resource authorization request and / or an API authorization request to the resource owner, where the resource authorization request is used to request, set, or modify a resource of the resource owner, receive an authorization code sent from the resource owner, send the authorization code to the first entity, and receive a token generated by the first entity based on the authorization code.The technical solution provided by the present disclosure realizes that in an API calling scenario, a UE authorizes the API caller to request a resource of the UE, to prevent data tampering by the resource owner during the authorization process.

[0254] An embodiment of the present disclosure further provides a communication system, the system including a resource owner, an API caller, and a first entity, and the system includes a resource invocation device shown in the embodiment of Figure 9■15 above for performing the resource invocation method shown in the embodiment of Figures 1 to 8.

[0255] 16, which is a schematic configuration diagram of a communication device 1600 provided by an embodiment of the present application. The communication device 1600 may be a network device, a user equipment (UE), a chip, a chip system, a processor, etc. that supports the network device to implement the above method, or a chip, a chip system, a processor, etc. that supports the user equipment to implement the above method. This device can be used to implement the method described in the above method embodiment, and specifically, reference can be made to the description of the above method embodiment.

[0256] The communication device 1600 may include one or more processors 1601. The processor 1601 may be a general-purpose processor or a special-purpose processor. For example, it may be a baseband processor or a central processing unit. The baseband processor may be used to process communication protocols and communication data, and the central processing unit may be used to control a communication device (e.g., a base station, a baseband chip, a terminal device, a terminal device chip, a DU or CU, etc.), execute a computer program, and process data of the computer program.

[0257] Optionally, the communication device 1600 may further include one or more memories 1602 capable of storing computer programs 1604. The processor 1601 executes the computer programs 1604 so that the communication device 1600 performs the methods described in the above method embodiments. Optionally, data may also be stored in the memory 1402. The communication device 1600 and the memory 1602 may be provided separately or integrated.

[0258] Optionally, the communication device 1600 may further include a transceiver 1605 and an antenna 1606. The transceiver 1605 realizes a transmitting and receiving function and may be referred to as a transmitting and receiving unit, a transceiver, or a transmitting and receiving circuit, etc. The transceiver 1605 may include a receiver and a transmitter, where the receiver realizes a receiving function and may be referred to as a receiver or a receiving circuit, etc., and the transmitter realizes a transmitting function and may be referred to as a transmitter or a transmitting circuit, etc.

[0259] Optionally, the communication device 1600 may further include one or more interface circuits 1607. The interface circuit 1607 is used to receive and transmit code instructions to the processor 1601. The processor 1601 executes the code instructions to cause the communication device 1600 to perform the methods described in the above method embodiments.

[0260] In one embodiment, the processor 1601 may include a transceiver for implementing the receiving and transmitting functions. For example, the transceiver may be a transmitting / receiving circuit, an interface, or an interface circuit. The transmitting / receiving circuit, the interface, or the interface circuit for implementing the receiving and transmitting functions may be separate or integrated. The transmitting / receiving circuit, the interface, or the interface circuit may be used for reading and writing code / data, or the transmitting / receiving circuit, the interface, or the interface circuit may be used for transmitting or communicating signals.

[0261] In one implementation, the processor 1601 can store a computer program 1603, which, when executed by the processor 1601, can cause the communication device 1600 to perform the methods described in the above method embodiments. The computer program 1603 can be hardened within the processor 1601, in which case the processor 1601 may be realized by hardware.

[0262] In one embodiment, the communication device 1600 may include circuitry capable of implementing the transmitting or receiving or communication functions of the above method embodiments. The processors and transceivers described herein may be implemented in an integrated circuit (IC), an analog IC, a radio frequency integrated circuit (RFIC), a hybrid signal IC, an application specific integrated circuit (ASIC), a printed circuit board (PCB), an electronic device, or the like. The processors and transceivers may also be fabricated in various IC process technologies, such as complementary metal oxide semiconductor (CMOS), n-type metal oxide semiconductor (nMOS), p-type metal oxide semiconductor (pMOS), bipolar junction transistor (BJT), bipolar CMOS (BiCMOS), silicon germanium (SiGe), or gallium arsenide (GaAs).

[0263] The communication device described in the above embodiment may be a network device or user equipment, but the scope of the communication device described in this application is not limited thereto, and the structure of the communication device may not be limited to that shown in FIG. 16. The communication device may be an independent device or a part of a larger device. For example, the communication device may be as follows: (1) An independent integrated circuit IC, or chip, or chip system or subsystem; (2) A set having one or more ICs, optionally including a memory component for storing data, computer programs; (3) ASICs such as modems, (4) Modules that can be incorporated into other devices; (5) Receivers, terminal devices, smart terminal devices, mobile phones, wireless devices, handhelds, mobile units, in-vehicle devices, network devices, cloud devices, artificial intelligence devices, etc. (6) Others.

[0264] When the communication device may be a chip or a chip system, reference may be made to the schematic configuration diagram of the chip shown in Fig. 17. The chip shown in Fig. 17 includes a processor 1701 and an interface 1702. The number of processors 1701 may be one or more, and the number of interfaces 1702 may be more than one.

[0265] Optionally, the chip further includes a memory 1703 for storing necessary computer programs and data.

[0266] Those skilled in the art can also understand that the various illustrative logical blocks and steps listed in the embodiments of the present disclosure can be realized by electronic hardware, computer software, or a combination of both. Whether such functions are realized by hardware or software is determined by the specific application and the overall system design requirements. Those skilled in the art can realize the described functions using various methods for each specific application, but this realization should not be understood as exceeding the scope of protection of the embodiments of the present application.

[0267] The present application further provides a computer-readable storage medium having stored thereon instructions that, when executed by a computer, implement the functionality of any of the method embodiments described above.

[0268] The present application further provides a computer program product which, when executed by a computer, implements the functionality of any of the method embodiments described above.

[0269] The above embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, they may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs. The processes or functions according to the embodiments of the present application are generated in whole or in part when the computer program is loaded and executed on a computer. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. A computer program can be stored on a computer-readable storage medium or transmitted from one computer-readable storage medium to another; for example, a computer program can be transmitted from one website, computer, server, or data center to another via wire (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, radio, microwave, etc.). A computer-readable storage medium may be any available medium accessible by a computer, or may include a data storage device such as a server, data center, or the like integrated with one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)).

[0270] Those skilled in the art will understand that the various numerals such as first, second, etc. in this application are merely for the convenience of explanation and do not limit the scope of the embodiments of this application, but also indicate priority.

[0271] At least one of the features in the present application can be described as one or more, and more can be two, three, four or more, and is not limited in the present application. In the embodiments of the present application, for one technical feature, the technical features in the category of technical features are distinguished by "first", "second", "third", "A", "B", "C", and "D", etc., and there is no order of precedence or hindrance between the technical features described in the "first", "second", "third", "A", "B", "C", and "D".

[0272] As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., magnetic disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions that are a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0273] The systems and techniques described herein may be implemented on a computing system including back-end components (e.g., a data server), or a computing system including middleware components (e.g., an application server), or a computing system including front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with embodiments of the systems and techniques described herein), or on a computing system including any combination of such back-end, middleware, and front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0274] A computer system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server is created by computer programs running on corresponding computers and having a client-server relationship to each other.

[0275] It should be understood that steps can be rearranged, added, or deleted using the various types of flows shown above. For example, the steps described in the present disclosure may be performed in parallel, sequentially, or in a different order, but this specification is not limited thereto as long as the technical solution disclosed in the present disclosure can achieve the desired results.

[0276] It should also be understood that the various embodiments of the present application may be practiced alone or in combination with other embodiments where permitted by the technical proposal.

[0277] Those skilled in the art will recognize that the units and algorithm steps of each example described in the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether a function is implemented in hardware or software is determined by the specific application and design constraints of the technical solution. Those skilled in the art may implement the described functions using different methods for each specific application, but such implementation should not be considered beyond the scope of this application.

[0278] As will be apparent to those skilled in the art, for convenience and brevity of description, the specific operating processes of the above-described systems, devices and units may refer to the corresponding processes in the above-described method embodiments, and the description thereof will be omitted here.

[0279] The above are only specific embodiments of the present application, but the scope of protection of the present application is not limited thereto, and those skilled in the art can easily think of modifications or substitutions within the technical scope disclosed in the present application, which should also be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A resource invocation method executed by a resource owner, comprising: receiving a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, wherein the resource authorization request is used to request, set or modify a resource of the resource owner; sending an authorization code request to a first entity, said authorization code request being used to request an authorization code; sending the authorization code received from the first entity to the API caller; A source calling method comprising:

2. The method comprises: performing mutual authentication with the API caller; If authentication is successful, establishing a first connection between the resource owner and the API caller; the first connection is a secure connection for transmitting the resource authorization request and / or the API authorization request; 2. The source calling method according to claim 1.

3. The step of performing mutual authentication with the API caller includes: If the API caller is a user equipment (UE), performing mutual authentication with the API caller based on a certificate; and if the API caller is an application function (AF), performing mutual authentication by a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism.

3. The source calling method according to claim 2.

4. The step of receiving a resource authorization request and / or an API authorization request transmitted from the API caller includes: receiving a resource authorization request sent from the API caller if the API caller has obtained authorization for the service; receiving a resource authorization request and an API authorization request sent from the API caller if the API caller has not obtained authorization for the service; the resource authorization request includes at least one of an identifier of the API caller, an identifier of the resource owner, and a target resource identifier, and the API authorization request includes a service identifier; 4. The source calling method according to claim 1, wherein:

5. The service identifier is A service name identifier; a service operation identifier; an operation semantic identifier; an API identifier; and 5. The source calling method according to claim 4.

6. The method comprises: performing mutual authentication with the first entity; if authentication is successful, establishing a second connection between the resource owner and the first entity; the second connection is a secure connection for transmitting the authorization code request and response; 6. The source calling method according to claim 1, wherein:

7. The step of performing mutual authentication with the first entity includes: Certificate-based authentication mechanisms, GBA-based authentication mechanism; AKMA-based authentication mechanism; TLS-PSK, and an OAuth token-based authentication mechanism; 7. The source calling method according to claim 1, wherein:

8. The step of sending an authorization code request to the first entity includes: agreeing in real time to the resource authorization request and sending an authorization code request to the first entity; asynchronously agreeing to the resource authorization request based on a local policy of the resource owner and sending an authorization code request to the first entity; sending a local policy and / or the authorization code request to the first entity, wherein the local policy is used to assist the first entity in asynchronously agreeing to the resource authorization request; 8. The source calling method according to claim 1, wherein:

9. The method comprises: If the resource authorization request is authorized and the API caller is authorized for a service, receiving an authorization code sent from the first entity.

9. The source calling method according to claim 1, wherein:

10. The resource owner is a user equipment (UE), and the resource is the UE's quality of service and / or location information; 10. The source calling method according to claim 1.

11. 1. A resource invocation method performed by a first entity, comprising: receiving an authorization code request sent from a resource owner, the authorization code request being used to request an authorization code; sending an authorization code to the resource owner; receiving an authorization code sent from an API caller; generating a token based on the authorization code and sending the token to the API caller; A resource calling method comprising:

12. The method comprises: mutually authenticating with the resource owner; if authentication is successful, establishing a second connection between the resource owner and the first entity; the second connection is a secure connection for transmitting the authorization code request and response; The resource calling method according to claim 11 .

13. The step of performing mutual authentication with the resource owner includes: Certificate-based authentication mechanisms, GBA-based authentication mechanism; AKMA-based authentication mechanism; TLS-PSK, and an OAuth token-based authentication mechanism; 13. The resource calling method according to claim 12.

14. The step of receiving an authorization code request sent from the resource owner includes: receiving the authorization code request based on the resource owner's real-time consent to a resource authorization request; receiving the authorization code request based on the resource owner's asynchronous consent to the resource authorization request; receiving a local policy and / or the authorization code request sent from the resource owner and asynchronously agreeing to the resource authorization request; 14. The resource calling method according to claim 11, wherein:

15. The step of receiving an authorization code request sent from the resource owner includes: If the resource authorization request obtains consent and the API caller obtains authorization for a service, generating the authorization code.

15. The resource calling method according to claim 10, wherein:

16. If the resource authorization request obtains consent and the API caller obtains authorization for a service, generating an authorization code includes: if the resource authorization request has been approved but the API caller has not been approved for the service, determining whether to approve the service authorization request of the API caller based on a preset policy; generating the authorization code if the service authorization request of the API caller is approved; 16. The resource calling method according to claim 15.

17. The method comprises: performing mutual authentication with the API caller; if authentication is successful, establishing a third connection between the API caller and the first entity; the third connection being a secure connection for transmitting an authorization code; 17. The resource calling method according to claim 11, wherein:

18. The step of performing mutual authentication with the API caller includes: Certificate-based authentication mechanisms, GBA-based authentication mechanism; AKMA-based authentication mechanism; TLS-PSK, and an OAuth token-based authentication mechanism; 18. The resource calling method according to claim 17.

19. generating a token based on the authorization code and sending the token to the API caller, sending an access token and / or a refresh token to the API caller; receiving a refresh token sent from the API caller, and sending an access token to the API caller based on the refresh token; The resource calling method according to any one of claims 11 to 18.

20. the first entity is a CAPIF Core Function or an Authorization Function; 20. The resource calling method according to claim 11, wherein:

21. A resource invocation method executed by an API caller, comprising: sending a resource authorization request and / or an API authorization request to a resource owner, wherein the resource authorization request is used to request, set or modify a resource of the resource owner; receiving an authorization code sent from the resource owner and sending the authorization code to a first entity; receiving a token generated by the first entity based on the authorization code; A resource calling method comprising:

22. The method comprises: mutually authenticating with the resource owner; If authentication is successful, establishing a first connection between the resource owner and the API caller; the first connection is a secure connection for transmitting the resource authorization request and / or the API authorization request; 22. The resource invocation method of claim 21.

23. The step of performing mutual authentication with the resource owner includes: If the API caller is a user equipment (UE), performing mutual authentication with the resource owner based on a certificate; If the API caller is an application function (AF), mutual authentication with the resource owner is performed by a GBA-based authentication mechanism, an AKMA-based authentication mechanism, or a certificate-based authentication mechanism.

23. The resource invocation method of claim 22.

24. The step of sending a resource authorization request and / or an API authorization request to the resource owner includes: If the API caller obtains authorization for a service, sending a resource authorization request to the resource owner; If the API caller has not obtained authorization for the service, sending a resource authorization request and an API authorization request to the resource owner; the resource authorization request includes at least one of an identifier of the API caller, an identifier of the resource owner, and a target resource identifier, and the API authorization request includes a service identifier; 24. The resource calling method according to claim 22 or 23.

25. If the API caller obtains authorization for a service and a resource authorization request sent by the API caller to the resource owner obtains consent, a token generated by the first entity based on the authorization code includes only authorization information related to the resource.

25. The resource invocation method of claim 24.

26. The method comprises: performing mutual authentication with the first entity; if authentication is successful, establishing a third connection between the API caller and the first entity; the third connection being a secure connection for transmitting an authorization code; The resource calling method according to any one of claims 21 to 25.

27. receiving a token generated by the first entity based on the authorization code, receiving an access token and / or a refresh token sent from the first entity; sending a refresh token to the first entity; and receiving an access token sent by the first entity based on the refresh token. The resource calling method according to any one of claims 21 to 26.

28. The API caller is a user equipment (UE) or an application function (AF), and the resource is the quality of service and / or location information of the resource owner; The resource calling method according to any one of claims 21 to 27.

29. A resource calling device, the device being configured as a resource owner, the device including a transceiving module, the transceiving module comprising: receiving a resource authorization request and / or an API authorization request sent from an application programming interface (API) caller, the resource authorization request being used to request, set, or modify a resource of the resource owner; sending an authorization code request to a first entity, the authorization code request being used to request an authorization code; configured to send the authorization code received from the first entity to the API caller; A resource calling device comprising:

30. A resource invoking device, the device being configured to a first entity, the device including a transceiver module, the transceiver module comprising: receiving an authorization code request sent from a resource owner, the authorization code request being used to request an authorization code; sending an authorization code to the resource owner; Receive the authorization code sent from the API caller, configured to generate a token based on the authorization code and send the token to the API caller; A resource calling device comprising:

31. A resource calling device, the device being set as an API caller, the device including a transmitting and receiving module, the transmitting and receiving module including: sending a resource authorization request and / or an API authorization request to a resource owner, the resource authorization request being used to request, set or modify a resource of the resource owner; receiving an authorization code sent from the resource owner and sending the authorization code to a first entity; configured to receive a token generated by the first entity based on the authorization code; A resource calling device comprising:

32. A communications device comprising a transceiver, a memory, and a processor; the processors are connected to the transceiver and the memory, respectively, and are configured to execute computer-executable instructions in the memory to control the transceiver to transmit and receive radio signals, thereby implementing the method according to any one of claims 1 to 28. A communication device characterized by:

33. A computer storage medium having computer-executable instructions stored thereon, The computer-executable instructions, when executed by a processor, implement the method according to any one of claims 1 to 28. A computer storage medium comprising:

34. 1. A communication system, comprising: a resource owner, an API caller, and a first entity; The resource owner is configured to perform the method according to any one of claims 1 to 9, The first entity is configured to perform the method according to any one of claims 10 to 19, The API caller is configured to execute the method according to any one of claims 20 to 28. A communication system comprising:

Images