WO2024065564A1 - 一种api的调用方法、装置、设备及存储介质 - Google Patents

一种api的调用方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2024065564A1
WO2024065564A1 PCT/CN2022/122958 CN2022122958W WO2024065564A1 WO 2024065564 A1 WO2024065564 A1 WO 2024065564A1 CN 2022122958 W CN2022122958 W CN 2022122958W WO 2024065564 A1 WO2024065564 A1 WO 2024065564A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
user resource
access token
api call
resource access
Prior art date
Application number
PCT/CN2022/122958
Other languages
English (en)
French (fr)
Inventor
梁浩然
陆伟
Original Assignee
北京小米移动软件有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京小米移动软件有限公司 filed Critical 北京小米移动软件有限公司
Priority to PCT/CN2022/122958 priority Critical patent/WO2024065564A1/zh
Priority to CN202280003760.0A priority patent/CN118120176A/zh
Publication of WO2024065564A1 publication Critical patent/WO2024065564A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords

Definitions

  • the present disclosure relates to the field of communication technology, and in particular to an API calling method/device/equipment and a storage medium.
  • a common application programming interface framework (Common Application Programming Interface Framework, CAPIF) is introduced to achieve load balancing and access control.
  • the CAPIF can include API (Application Programming Interface) calling entity, common API framework core function (Common API Framework Core Function, CCF), API exposing function (API Exposing Function, AEF), etc., among which AEF can provide one or more APIs.
  • API Application Programming Interface
  • CCF Common API Framework Core Function
  • API Exposing Function API Exposing Function
  • AEF API Exposing Function
  • API calling entity in CAPIF can directly access the AEF that provides the API through API information and call the API through AEF.
  • AEF does not obtain authorization from the resource owner, that is, it directly accesses user resources without the authorization of the resource owner. Based on this, there may be illegal calls to API to access resources, thereby reducing the security of API calls.
  • API calling method/device/equipment and storage medium proposed in the present disclosure are used to solve the technical problem of low security of API calling methods in related technologies.
  • an embodiment of the present disclosure provides an API calling method, characterized in that it is executed by an API open function entity and includes:
  • API call request sent by an API call entity, wherein the API call request includes API call information and a user resource access token;
  • the API call verification is performed according to the API call information and the user resource access token.
  • the API open functional entity receives the API calling request sent by the API calling entity, wherein the API calling request includes the API calling information and the user resource access token, and then performs the API calling verification according to the API calling information and the user resource access token. It can be seen from this that in the method provided by the present disclosure, the API open functional entity can perform the API calling verification through the user resource access token, that is, the API open functional entity can use the user resource access information in the user resource access token to perform the API calling verification, thus avoiding the situation of "directly accessing user resources without the authorization of the resource owner", thereby improving the security of the API calling.
  • an API calling method which is executed by an API calling entity and includes:
  • An API call request is sent to the API open function entity, wherein the API call request includes API call information and a user resource access token.
  • an embodiment of the present disclosure provides a communication device, which is configured in an API open function entity, including:
  • a receiving module configured to receive an API call request sent by an API call entity, wherein the API call request includes API call information and a user resource access token;
  • a call verification module is used to perform API call verification based on the API call information and the user resource access token.
  • an embodiment of the present disclosure provides an API calling method, wherein the device is configured in an API calling entity, and includes:
  • the sending module is used to send an API call request to the API open function entity, wherein the API call request includes API call information and a user resource access token.
  • an embodiment of the present disclosure provides a communication device, which includes a processor.
  • the processor calls a computer program in a memory, the method described in the first aspect is executed.
  • an embodiment of the present disclosure provides a communication device, which includes a processor.
  • the processor calls a computer program in a memory, the method described in the second aspect is executed.
  • an embodiment of the present disclosure provides a communication device, which includes a processor and a memory, in which a computer program is stored; the processor executes the computer program stored in the memory so that the communication device executes the method described in the first aspect above.
  • an embodiment of the present disclosure provides a communication device, which includes a processor and a memory, in which a computer program is stored; the processor executes the computer program stored in the memory so that the communication device executes the method described in the second aspect above.
  • an embodiment of the present disclosure provides a communication device, which includes a processor and an interface circuit, wherein the interface circuit is used to receive code instructions and transmit them to the processor, and the processor is used to run the code instructions to enable the device to execute the method described in the first aspect above.
  • an embodiment of the present disclosure provides a communication device, which includes a processor and an interface circuit, wherein the interface circuit is used to receive code instructions and transmit them to the processor, and the processor is used to run the code instructions to enable the device to execute the method described in the second aspect above.
  • an embodiment of the present disclosure provides a communication system, which includes the communication device described in the third aspect to the communication device described in the fourth aspect, or the system includes the communication device described in the fifth aspect to the communication device described in the sixth aspect, or the system includes the communication device described in the seventh aspect to the communication device described in the eighth aspect, or the system includes the communication device described in the ninth aspect to the communication device described in the tenth aspect.
  • an embodiment of the present invention provides a computer-readable storage medium for storing instructions used for the above-mentioned network device.
  • the terminal device executes the method described in any one of the above-mentioned first to second aspects.
  • the present disclosure further provides a computer program product comprising a computer program, which, when executed on a computer, enables the computer to execute the method described in any one of the first to second aspects above.
  • the present disclosure provides a chip system, which includes at least one processor and an interface, and is used to support a network device to implement the functions involved in the method described in any one of the first aspect to the second aspect, for example, determining or processing at least one of the data and information involved in the above method.
  • the chip system also includes a memory, and the memory is used to store computer programs and data necessary for the source auxiliary node.
  • the chip system can be composed of a chip, or it can include a chip and other discrete devices.
  • the present disclosure provides a computer program, which, when executed on a computer, enables the computer to execute the method described in any one of the first to second aspects above.
  • FIG1 is a schematic diagram of the architecture of a communication system provided by an embodiment of the present disclosure.
  • FIG2 is a schematic diagram of a flow chart of an API calling method provided by another embodiment of the present disclosure.
  • FIG3 is a flow chart of an API calling method provided in yet another embodiment of the present disclosure.
  • FIG4 is a flow chart of an API calling method provided by yet another embodiment of the present disclosure.
  • FIG5 is a flow chart of an API calling method provided by another embodiment of the present disclosure.
  • FIG6 is a flow chart of an API calling method provided in yet another embodiment of the present disclosure.
  • FIG7 is a flow chart of an API calling method provided by yet another embodiment of the present disclosure.
  • FIG8 is a flow chart of an API calling method provided by an embodiment of the present disclosure.
  • FIG9 is a flow chart of an API calling method provided by another embodiment of the present disclosure.
  • FIG10 is a flow chart of an API calling method provided in yet another embodiment of the present disclosure.
  • FIG11 is a flow chart of an API calling method provided by yet another embodiment of the present disclosure.
  • FIG12 is a flow chart of an API calling method provided by another embodiment of the present disclosure.
  • FIG13 is an interactive flow chart of an API calling method provided by yet another embodiment of the present disclosure.
  • FIG14 is a schematic diagram of the structure of a communication device provided by an embodiment of the present disclosure.
  • FIG15 is a schematic diagram of the structure of a communication device provided by another embodiment of the present disclosure.
  • FIG16 is a block diagram of a user equipment provided by an embodiment of the present disclosure.
  • FIG17 is a block diagram of a network-side device provided by an embodiment of the present disclosure.
  • first, second, third, etc. may be used to describe various information in the disclosed embodiments, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information.
  • the words "if” and “if” as used herein may be interpreted as “at” or "when” or "in response to determination".
  • CAPIF includes API calling entity, Common API Framework Core Function (CCF), API Exposing Function (AEF), etc., among which AEF can provide one or more APIs.
  • CCF Common API Framework Core Function
  • AEF API Exposing Function
  • the API calling entity usually obtains the information of the AEF that provides the API from the CCF and directly accesses the AEF that provides the API.
  • FIG. 1 is a schematic diagram of the architecture of a communication system provided by an embodiment of the present disclosure.
  • the communication system may include, but is not limited to, a network device and a terminal device.
  • the number and form of devices shown in FIG. 1 are only used as examples and do not constitute a limitation on the embodiment of the present disclosure. In actual applications, two or more network devices and two or more terminal devices may be included.
  • the communication system shown in FIG. 1 includes, for example, a terminal device 11 and a core network device 12.
  • LTE long term evolution
  • 5G fifth generation
  • NR 5G new radio
  • the core network device 12 in the embodiment of the present disclosure is a device deployed in the core network.
  • the function of the core network device 12 is mainly to provide user connection, user management and service bearing, and to provide an interface to the external network as a bearer network.
  • the core network device in the 5G NR system may include an Access and Mobility Management Function (AMF) network element, a User Plane Function (UPF) network element, and a Session Management Function (SMF) network element.
  • AMF Access and Mobility Management Function
  • UPF User Plane Function
  • SMF Session Management Function
  • the core network device 12 in the embodiment of the present application may include a location management function network element.
  • the location management function network element includes a location server (location server), and the location server can be implemented as any of the following: LMF (Location Management Function, location management network element), E SMLC (Enhanced Serving Mobile Location Centre, enhanced serving mobile location center), SUPL (Secure User Plane Location, secure user plane positioning), SUPL SLP (SUPL Location Platform, secure user plane positioning platform).
  • LMF Location Management Function
  • E SMLC Enhanced Serving Mobile Location Centre, enhanced serving mobile location center
  • SUPL Secure User Plane Location
  • SUPL SLP SUPL Location Platform, secure user plane positioning platform
  • the terminal device 11 in the disclosed embodiment is an entity on the user side for receiving or transmitting signals, such as a mobile phone.
  • the terminal device may also be referred to as a terminal device (terminal), a user equipment (UE), a mobile station (MS), a mobile terminal device (MT), etc.
  • the terminal device may be a car with communication function, a smart car, a mobile phone (mobile phone), a wearable device, a tablet computer (Pad), a computer with wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal device in industrial control (industrial control), a wireless terminal device in self-driving, a wireless terminal device in remote medical surgery, a wireless terminal device in smart grid (smart grid), a wireless terminal device in transportation safety (transportation safety), a wireless terminal device in a smart city (smart city), a wireless terminal device in a smart home (smart home), etc.
  • the embodiments of the present disclosure do not limit the specific technology and specific device form adopted by the terminal device.
  • the communication system described in the embodiment of the present disclosure is for the purpose of more clearly illustrating the technical solution of the embodiment of the present disclosure, and does not constitute a limitation on the technical solution provided by the embodiment of the present disclosure.
  • a person skilled in the art can know that with the evolution of the system architecture and the emergence of new business scenarios, the technical solution provided by the embodiment of the present disclosure is also applicable to similar technical problems.
  • one of the goals of SNAAPP security research is to obtain authorization from the resource owner.
  • TS22.261 stipulates that "UE (User Equipment) is allowed to provide/revoke consent for information (e.g., location, presence) shared with third parties”.
  • the API calling entity needs to call a specific service API to obtain/modify/set specific user resources (e.g., location, QoS).
  • the user resource authorization information and the API authorization information should be used simultaneously.
  • the present disclosure proposes an API calling method.
  • FIG2 is a flow chart of an API calling method provided by an embodiment of the present disclosure, wherein the method is executed by an API open function entity. As shown in FIG2 , the API calling method may include the following steps:
  • Step 201 Receive an API call request sent by an API call entity, where the API call request includes API call information and a user resource access token.
  • the API calling entity may be a UE or an AF (Application Function).
  • the API open function entity may be an AEF.
  • the above API call information may include at least one of the following:
  • the first resource owner's identity such as GPSI (Generic Public Subscription Identifier) or IMSI (International Mobile Subscriber Identity), or application layer ID (Identity, serial number));
  • the service API identifier to be called
  • the identifier of the service to be called is the identifier of the service to be called
  • the identifier of the user resource that needs access (such as a location).
  • the user resource access token may include one or more of the following:
  • CAPIF Common Application Programming Interface Framework
  • core function identity such as NF (Network Function) instance ID or NF ID
  • Authorized function identity (such as NF instance ID or NF ID);
  • the first identity of the API open function entity (such as NF instance ID or NF ID);
  • the second resource owner's identity such as GPSI (Generic Public Subscription Identifier) or IMSI (International Mobile Subscriber Identity), or application layer ID;
  • User resource identifier e.g., location
  • the service identifier may include at least one of the following:
  • Service Name Service Name
  • Service Operation Service Operation
  • the API open function entity before the API open function entity receives the API call request sent by the API calling entity, it needs to perform mutual identity authentication with the API calling entity, and establish a secure connection after mutual identity authentication to ensure the security of the interaction process. And, in one embodiment of the present disclosure, after the API calling entity and the API open function entity perform mutual identity authentication, the API calling entity will have an authenticated identity identifier so that the API open function entity can subsequently authenticate the API calling entity. Among them, the process of establishing a network connection will be described in detail in subsequent embodiments.
  • the user resource access information may include a second resource owner identity and/or a user resource identifier.
  • the first identity of the API calling entity in the above API call information, the first resource owner identity, and the second identity of the API calling entity in the user resource access token, and the second resource owner identity will be described in detail in subsequent embodiments.
  • Step 202 Perform API call verification based on the API call information and the user resource access token.
  • user resource access verification and API call verification can be performed on the API call request based on the API call information and the user resource access token, and when both the user resource access verification and the API call verification pass, it is judged that the API call request has passed the verification.
  • the method for performing API call verification based on the API call information and the user resource access token is also different. This part of the content will be described in detail in subsequent embodiments.
  • the API open functional entity will receive the API calling request sent by the API calling entity, wherein the API calling request includes the API calling information and the user resource access token, and then the API calling verification is performed according to the API calling information and the user resource access token. It can be seen from this that in the method provided by the present disclosure, the API open functional entity can perform API calling verification through the user resource access token, that is, the API open functional entity can use the user resource access information in the user resource access token to perform API calling verification, thus avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calling.
  • FIG3 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API open function entity. As shown in FIG3 , the API calling method may include the following steps:
  • Step 301 Receive an API call request sent by an API call entity, wherein the API call request includes API call information and a user resource access token.
  • Step 302 Perform user resource access verification on the API call request according to the user resource access token.
  • the method for the API open function entity to perform user resource access verification on the API call request based on the user resource access token may include: performing validity verification on the user resource access token, and after determining that the user resource access token is valid, performing user resource access verification on the API call request based on the user resource access token.
  • the method for an API open functional entity to verify the validity of a user resource access token may include: verifying the validity of the user resource access token (i.e., whether the token has been tampered with); if the user resource token is invalid, it means that the user resource access token has been tampered with, and the API open functional entity terminates subsequent verification and determines that the user resource access verification has not passed; if the user resource access token is valid, it means that the user resource access token has not been tampered with, and then the validity verification of the user resource access token is completed to determine that the user resource access token is valid.
  • verifying the validity of the user resource access token i.e., whether the token has been tampered with
  • the API open functional entity terminates subsequent verification and determines that the user resource access verification has not passed
  • the user resource access token is valid, it means that the user resource access token has not been tampered with, and then the validity verification of the user resource access token is completed to determine that the user resource access token is valid.
  • the method for the above-mentioned API open function entity to verify the validity of the user resource access token may include: if the user resource access token is a JSON Web token, the API open function entity uses the public key of the CAPIF core function/authorization function to verify whether the token is valid (that is, whether the token has been tampered with); if the user resource access token is not a JSON Web token, the API open function entity will send the user resource access token to the CAPFI core function/authorization function, and receive an indication from the CAPIF core function/authorization function. If the CAPIF core function/authorization function indicates that the user resource access token is valid, it is determined that the user resource access token is valid; otherwise, it is determined that the user resource access token is invalid.
  • the validity of the user resource access token is verified, thereby ensuring that the information in the received user resource access token is available through the above-mentioned verification method.
  • the above-mentioned API open function entity after determining that the user resource access token is valid, the above-mentioned API open function entity also needs to perform user resource access verification on the API call request according to the user resource access token.
  • the second resource owner identity and/or user resource identifier in the user resource access token is the user resource access information that can be accessed by the API calling entity. Based on this, it is necessary to compare the information that can be accessed by the API calling entity in the resource access token with the information that the API calling entity wants to access in the API calling information, so as to determine whether the API call request passes the user resource access verification.
  • a method for performing user resource access verification on an API call request based on a user resource access token may include: determining whether the user resource access token is the same as the value corresponding to the same identifier in the API call information; if the values corresponding to the same identifier are the same, determining that the API call request passes the user resource access verification; otherwise, determining that the API call request fails the user resource access verification, and the API open function entity terminates subsequent verification.
  • the API open function entity terminates subsequent verification and determines that the API call request has not passed the user resource access verification; otherwise, if the first resource owner identity identifier in the API calling information is not the same as the second resource owner identity identifier in the user resource access token, the API open function entity terminates subsequent verification and determines that the API call request has not passed the user resource access verification; otherwise, if the user resource identifier to be accessed in the API calling information is not the same as the user resource identifier in the user resource access token, the API open function entity terminates subsequent verification and determines that the API call request has not passed the user resource access verification; otherwise, if the first identity identifier of the API open function entity in
  • the API open functional entity after determining that the user resource access token is valid, the API open functional entity will first authenticate the API calling entity, and when the first identity identifier of the API calling entity in the API call information and the second identity identifier of the API calling entity in the user resource access token are consistent with the authenticated identity identifier of the API calling entity, or can be mapped to the authenticated identity identifier, will it continue with subsequent verification; otherwise, the API open functional entity terminates subsequent verification and determines that the API call request has not passed the user resource access verification, thereby determining the identity of the API calling entity, avoiding API calls by unauthenticated API calling entities, and ensuring the security of API calls.
  • the first identity identifier and the first resource owner identity identifier of the API calling entity in the API call information are for comparison with the second identity identifier and the second resource owner identity identifier of the API calling entity in the user resource access token, so as to further determine that the information in the user resource access token is available.
  • the API call request passes the user resource access verification, it means that the API call entity is authorized to access the user resources; if it is confirmed that the API call request does not pass the user resource access verification, it means that the API call entity is not authorized to access the user resources.
  • Step 303 Perform API call verification on the API call request by calling the CAPIF core function or the authorization function.
  • the above-mentioned user resource access token only includes user resource access information (such as the second resource owner identity and/or the user resource identifier), and does not include API usage information (such as the service API identifier and/or the service identifier).
  • the API open function entity cannot determine the API usage information that the API calling entity can call based on the user resource access token, and thus cannot perform API call verification on the API call request based on the user resource access token.
  • a method for performing API call verification on an API call request by calling a CAPIF core function or an authorization function may include: an API open function entity sends the first identity identifier of the API call entity and the service API identifier/service identifier to be called in the API call information to CCF/AF (Authorization function) for API authorization, thereby determining whether the API call request passes the API call verification based on the response received from CCF/AF. If an authorization response is received from CCF/AF, it is determined that the API call request passes the API call verification; otherwise, it is determined that the API call request does not pass the API call verification.
  • CCF/AF Authorization function
  • the API call request passes the API call verification, it means that the API call entity is authorized to call the service API and/or service; if it is confirmed that the API call request does not pass the API call verification, it means that the API call entity is not authorized to call the service API and/or service.
  • Step 304 When both the user resource access verification and the API call verification are passed, it is determined that the API call request has passed the verification.
  • the API call request when both the user resource access verification and the API call verification are passed, it is judged that the API call request has passed the verification, and it is determined that the API calling entity is authorized to access user resources and call service APIs and/or services; otherwise, it is judged that the API call request has not passed the verification, and it is determined that the API calling entity is not authorized to access user resources and/or call service APIs and/or services.
  • the API open functional entity will receive the API calling request sent by the API calling entity, wherein the API calling request includes the API calling information and the user resource access token, and then the API calling verification is performed according to the API calling information and the user resource access token.
  • the API open functional entity can perform API calling verification through the user resource access token, that is, the API open functional entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calling.
  • FIG4 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API open function entity. As shown in FIG4 , the API calling method may include the following steps:
  • Step 401 Receive an API call request sent by an API call entity.
  • the API call request includes API call information and a user resource access token.
  • the user resource access token includes a service API identifier and a service identifier.
  • Step 402 Perform user resource access verification and API call verification on the API call request according to the user resource access token.
  • the method for the API open function entity to perform user resource access verification and API call verification on the API call request according to the user resource access token may include: performing validity verification on the user resource access token, and after determining that the user resource access token is valid, performing user resource access verification and API call verification on the API call request according to the user resource access token.
  • the difference between this embodiment and the above-mentioned embodiment is that, in this embodiment, the user resource access token includes, in addition to the above-mentioned information, also includes: a service API identifier and/or a service identifier, wherein the service API identifier and/or service identifier in the user resource access token is the API usage information that can be accessed by the API calling entity.
  • the user resource access token contains user resource access information and API usage information. Based on this, after the API open function entity determines that the user resource access token is valid, it can perform user resource access verification and API call verification on the API call request according to the user resource access token.
  • a method for performing user resource access verification and API call verification on an API call request based on a user resource access token may include: determining whether the value corresponding to the same identifier in the user resource access token is the same as that in the API call information; if the values corresponding to the same identifier are the same, determining that the API call request passes the user resource access verification and the API call verification; otherwise, determining that the API call request does not pass the user resource access verification or the API call verification, then the API open function entity terminates subsequent verification.
  • the API open function entity terminates subsequent verification and determines that the API call request has not passed the user resource access verification; otherwise, if the first resource owner identity identifier in the API calling information is not the same as the second resource owner identity identifier in the user resource access token, the API open function entity terminates subsequent verification and determines that the API call request has not passed the user resource access verification; otherwise, if the user resource identifier to be accessed in the API calling information is not the same as the user resource identifier in the user resource access token, the API open function entity terminates subsequent verification and determines that the API call request has not passed the user resource access verification; otherwise, if the first identity identifier of the API open function entity in
  • the API open functional entity terminates subsequent verification and determines that the API call request has not passed the API call verification; otherwise, if the service identifier to be called in the API call information is different from the service API operator in the user resource access token, the API open functional entity terminates subsequent verification and determines that the API call request has not passed the API call verification; otherwise, it is determined that the API call request has passed the API call verification.
  • Step 403 When both the user resource access verification and the API call verification are passed, it is determined that the API call request has passed the verification.
  • step 403 For a detailed description of step 403, reference may be made to the relevant description in the above embodiment, which will not be elaborated in detail in the embodiment of the present disclosure.
  • the API open functional entity will receive the API calling request sent by the API calling entity, wherein the API calling request includes the API calling information and the user resource access token, and then the API calling verification is performed according to the API calling information and the user resource access token.
  • the API open functional entity can perform API call verification through the user resource access token, that is, the API open functional entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG5 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API open function entity. As shown in FIG5 , the API calling method may include the following steps:
  • Step 501 Receive an API call request sent by an API call entity, where the API call request includes API call information, a user resource access token, and an API access token.
  • the API access token may include one or more of the following:
  • the service identifier The service identifier.
  • the user resource access token and the API access token may belong to different tokens or the same token.
  • Step 502 Perform user resource access verification on the API call request according to the user resource access token.
  • step 502 For a detailed description of step 502, reference may be made to the relevant description in the above embodiment, and the present embodiment will not be elaborated here.
  • Step 503 Perform API call verification on the API call request according to the API access token.
  • the method for the API open function entity to verify the API call request according to the API access token may include: verifying the validity of the API access token, and after determining that the API access token is valid, verifying the API call request according to the API access token.
  • the method for the API open functional entity to verify the validity of the API access token may include: verifying the validity of the API access token (i.e., whether the token has been tampered with); if the API access token is invalid, it means that the API access token has been tampered with, and the API open functional entity terminates subsequent verification and determines that the API call verification has not passed; if the API access token is valid, it means that the API access token has not been tampered with, and then the validity verification of the API access token is completed to determine that the API access token is valid.
  • the method for the above-mentioned API open function entity to verify the validity of the API access token may include: if the API access token is a JSON Web token, the API open function entity uses the public key of the CAPIF core function/authorization function to verify whether the API access token is valid; if the API access token is not a JSON Web token, the API open function entity will send the API access token to the CAPFI core function/authorization function, and receive an indication from the CAPIF core function/authorization function. If the indication from the CAPIF core function/authorization function is that the API access token is valid, it is determined that the API access token is valid; otherwise, it is determined that the API access token is invalid.
  • the API open functional entity needs to authenticate both the user resource access token and the API access token.
  • the API open function entity when the user resource access token and the API access token belong to the same token, after the API calling entity sends the user resource access token and the API access token to the API open function entity, the API open function entity only needs to perform validity verification on the tokens to which the user resource access token and the API access token belong.
  • validity verification method reference can be made to the relevant description in the above embodiment.
  • the above-mentioned API open function entity after determining that the API access token is valid, the above-mentioned API open function entity also needs to perform an API call verification on the API call request according to the API access token.
  • the service API identifier and/or service identifier in the API access token is the API usage information that can be called by the API calling entity
  • the user resource identifier is the user resource access information that can be accessed by the API calling entity. Based on this, it is necessary to compare the API usage information and user resource access information that can be called by the API calling entity in the API access token with the API usage information and user resource access information to be called by the API calling entity in the API call information, so as to determine whether the API call request passes the API call verification.
  • a method for performing user resource access verification on a call request based on an API access token may include: determining whether the API access token is the same as the value corresponding to the same identifier in the API call information; if the values corresponding to the same identifier are the same, determining that the API call request passes the API call verification; otherwise, determining that the API call request fails the API call verification, and the API open function entity terminates subsequent verification.
  • the API open functional entity terminates subsequent verification and determines that the API call request has not passed the API call verification; otherwise, if the service API identifier to be called in the API call information is different from the service API identifier in the API access token, the API open functional entity terminates subsequent verification and determines that the API call request has not passed the API call verification; otherwise, if the service identifier to be called in the API call information is different from the service API identifier in the API access token, If the service identifier in the API access token is different from the service identifier in the API access token, the API open functional entity terminates subsequent verification and determines that the API call request has not passed the API call verification; otherwise, if the second identity identifier
  • Step 504 When both the user resource access verification and the API call verification are passed, it is determined that the API call request has passed the verification.
  • step 504 For a detailed description of step 504, reference may be made to the relevant description in the above embodiment, which will not be elaborated in detail in the embodiment of the present disclosure.
  • the API open functional entity will receive the API calling request sent by the API calling entity, wherein the API calling request includes the API calling information and the user resource access token, and then the API calling verification is performed according to the API calling information and the user resource access token.
  • the API open functional entity can perform API call verification through the user resource access token, that is, the API open functional entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG6 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API open function entity. As shown in FIG6 , the API calling method may include the following steps:
  • Step 601 Send an API call response to the API calling entity.
  • the API open function entity may send an API call response to the API calling entity according to the result of the API call verification obtained in the above embodiment.
  • the API open functional entity when it is determined that the API call request has passed the verification, it means that the API calling entity is authorized to access user resources and call service APIs and/or services, and the API open functional entity sends an authorization API call response to the API calling entity; when it is determined that the API call request has not passed the verification, it means that the API calling entity is not authorized to access user resources and/or call service APIs and/or services, and the API open functional entity sends a rejection/termination API call response to the API calling entity.
  • the API calling entity may perform operations according to the received API call response.
  • the API open functional entity will receive the API calling request sent by the API calling entity, wherein the API calling request includes the API calling information and the user resource access token, and then the API calling verification is performed according to the API calling information and the user resource access token.
  • the API open functional entity can perform API call verification through the user resource access token, that is, the API open functional entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG. 7 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API open function entity. As shown in FIG. 7 , the API calling method may include the following steps:
  • Step 701 Perform mutual identity authentication with the API calling entity.
  • mutual identity authentication is performed with the API calling entity through any of the following authentication mechanisms:
  • TLS-PSK Transport Layer Security-Pre-Shared Key
  • Authentication mechanism based on AKMA Application layer Authentication and Key Management
  • Step 702 In response to successful identity authentication, a secure connection is established with the API calling entity.
  • a secure connection in response to successful identity authentication, can be established with the API calling entity through TLS (Transport Layer Security).
  • TLS Transport Layer Security
  • the API open functional entity can interact with the API calling entity through the secure connection, such as receiving an API call request sent by the API calling entity, or sending an API call response to the API calling entity.
  • the API open functional entity will receive the API calling request sent by the API calling entity, wherein the API calling request includes the API calling information and the user resource access token, and then the API calling verification is performed according to the API calling information and the user resource access token.
  • the API open functional entity can perform API call verification through the user resource access token, that is, the API open functional entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG8 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API calling entity. As shown in FIG8 , the API calling method may include the following steps:
  • Step 801 Send an API call request to an API open function entity, where the API call request includes API call information and a user resource access token.
  • the API calling entity may be a UE or an AF.
  • the above API call information may include one or more of the following:
  • the first resource owner's identity (such as GPSI or IMSI, or application layer ID);
  • the service API identifier to be called
  • the identifier of the service to be called is the identifier of the service to be called
  • the identifier of the user resource that needs access (such as a location).
  • the user resource access token may include one or more of the following:
  • CAPIF core functional identity such as NF instance ID or NF ID
  • Authorized function identity (such as NF instance ID or NF ID);
  • the identity of the API open function entity (such as NF instance ID, NF ID);
  • the second resource owner's identity (such as GPSI or IMSI, or application layer ID);
  • User resource identifier e.g., location
  • the API open functional entity may perform API calling verification according to the API calling information and the user resource access token.
  • the API calling entity sends an API calling request to the API open function entity, and the API calling request includes API calling information and a user resource access token.
  • the API open function entity can verify the API call through the user resource access token, that is, the API open function entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG9 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API calling entity. As shown in FIG9 , the API calling method may include the following steps:
  • Step 901 Send an API call request to an API open function entity.
  • the API call request includes API call information and a user resource access token.
  • the user resource access token includes a service API identifier and a service identifier.
  • the difference between this embodiment and the embodiment of FIG. 8 is that, in addition to the above information, the user resource access token in this embodiment also includes: a service API identifier and/or a service identifier.
  • the content included in the user resource access token in this embodiment is different from the content included in the user resource access token in the embodiment of FIG8 .
  • the subsequent API open function entity performs a different method for API call verification based on the API call information and the user resource access token.
  • the API calling entity will send an API calling request to the API open function entity, and the API calling request includes API calling information and a user resource access token.
  • the API open function entity can verify the API call through the user resource access token, that is, the API open function entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG10 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API calling entity. As shown in FIG10 , the API calling method may include the following steps:
  • Step 1001 Send an API call request to an API open function entity, where the API call request includes API call information, a user resource access token, and an API access token.
  • the API access token may include one or more of the following:
  • the service identifier The service identifier.
  • the user resource access token and the API access token may belong to different tokens or the same token.
  • the API open function entity needs to authenticate both the user resource access token and the API access token.
  • the API open function entity when the above-mentioned user resource access token and API access token belong to the same token, after the API calling entity sends the user resource access token and API access token to the API open function entity, the API open function entity only needs to authenticate the token to which the user resource access token and API access token belong.
  • the API open function entity only needs to authenticate the token to which the user resource access token and API access token belong.
  • the API calling entity will send an API calling request to the API open function entity, and the API calling request includes API calling information and a user resource access token.
  • the API open function entity can verify the API call through the user resource access token, that is, the API open function entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG11 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API calling entity. As shown in FIG11 , the API calling method may include the following steps:
  • Step 1101 Receive an API call response sent by an API open function entity.
  • the API open functional entity can perform an API call verification on the API calling request based on the received API calling information and user resource access token, and determine the API calling response based on the verification result.
  • the API call entity when the API call request fails to pass the API call verification, the API call entity receives a rejection/termination API call response sent by the API open function entity. And, in another embodiment of the present disclosure, when the API call request passes the API call verification, the API call entity receives an authorization API call response sent by the API open function entity.
  • the API calling entity when the API call response sent by the receiving API open function entity is a rejection/termination API call response, the API calling entity cannot call the corresponding service API and/or service.
  • the API calling entity when the API call response sent by the receiving API open function entity is an authorized API call response, the API calling entity can call the corresponding service API and/or service.
  • the API calling entity will send an API calling request to the API open function entity, and the API calling request includes API calling information and a user resource access token.
  • the API open function entity can verify the API call through the user resource access token, that is, the API open function entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG12 is a flow chart of an API calling method provided by an embodiment of the present disclosure. The method is executed by an API calling entity. As shown in FIG12 , the API calling method may include the following steps:
  • Step 1201 Perform mutual identity authentication with the API open function entity.
  • mutual identity authentication is performed with the API open function entity through any of the following authentication mechanisms:
  • Step 1202 In response to successful identity authentication, a secure connection is established with the API open function entity.
  • a secure connection with the API open function entity may be established via TLS.
  • the API calling entity can interact with the API open functional entity through the secure connection, such as sending an API call request to the API open functional entity, or receiving an API call response sent by the API open functional entity.
  • the API calling entity will send an API calling request to the API open function entity, and the API calling request includes API calling information and a user resource access token.
  • the API open function entity can verify the API call through the user resource access token, that is, the API open function entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • FIG13 is an interactive flow chart of an API calling method provided by an embodiment of the present disclosure. As shown in FIG13 , the following steps may be specifically included:
  • Step 1301 The API caller (ie, the API calling entity) and the AEF (ie, the API open function entity) perform mutual authentication (ie, the identity authentication).
  • Step 1302 The API calling entity sends a service API calling request (ie, the above-mentioned API calling request) to the AEF.
  • a service API calling request ie, the above-mentioned API calling request
  • Step 1303 AEF performs API call request authorization verification.
  • Step 1304 AEF performs API call request authorization and authorization verification through the CAPIF core function/authorization function.
  • Step 1305 The AEF sends a service API call response (ie, the above-mentioned API call response) to the API calling entity.
  • a service API call response ie, the above-mentioned API call response
  • FIG. 14 is a schematic diagram of the structure of a communication device provided in an embodiment of the present disclosure. As shown in FIG. 15 , the device may include:
  • the receiving module 1401 is used to receive an API call request sent by an API call entity, wherein the API call request includes API call information and a user resource access token;
  • the verification module 1402 is used to perform API call verification according to the API call information and the user resource access token.
  • the API open function entity will receive the API call request sent by the API calling entity, wherein the API call request includes the API call information and the user resource access token, and then the API call verification is performed according to the API call information and the user resource access token.
  • the API open function entity can perform API call verification through the user resource access token, that is, the API open function entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • the API call request also includes an API access token.
  • the user resource access token and the API access token belong to the same token.
  • the API call information includes one or more of the following:
  • the first resource owner's identity The first resource owner's identity
  • the service API identifier to be called
  • the identifier of the service to be called is the identifier of the service to be called
  • the identifier of the user resource that needs access is the identifier of the user resource that needs access.
  • the user resource access token includes one or more of the following:
  • the user resource access token further includes:
  • the service identifier The service identifier.
  • the verification module 1402 is further used to:
  • the verification module 1402 is further used to:
  • the verification module 1402 is further used to:
  • the above device is further used for:
  • the above device is further used for:
  • the above device is further used to perform mutual identity authentication with the API calling entity through any of the following authentication mechanisms:
  • the above device is further used for:
  • FIG. 15 is a schematic diagram of the structure of a communication device provided by an embodiment of the present disclosure. As shown in FIG. 15 , the device may include:
  • the sending module 1501 is used to send an API call request to the API open function entity, wherein the API call request includes API call information and a user resource access token.
  • the API calling entity will send an API calling request to the API open function entity, and the API calling request includes API calling information and a user resource access token.
  • the API open function entity can verify the API call through the user resource access token, that is, the API open function entity can use the user resource access token to determine whether to authorize the API calling entity to access user resources and call the service API, thereby avoiding the situation of "directly accessing user resources without authorization from the resource owner", thereby improving the security of API calls.
  • the API call request also includes an API access token.
  • the user resource access token and the API access token belong to the same token.
  • the API call information includes one or more of the following:
  • the first resource owner's identity The first resource owner's identity
  • the service API identifier to be called
  • the identifier of the service to be called is the identifier of the service to be called
  • the identifier of the user resource that needs access is the identifier of the user resource that needs access.
  • the user resource access token includes one or more of the following:
  • the user resource access token further includes:
  • the service identifier The service identifier.
  • the above device is further used for:
  • the above device is further used for:
  • the above device is further used to perform mutual identity authentication with the API open function entity through any of the following authentication mechanisms:
  • the above device is further used for:
  • FIG 16 is a schematic diagram of the structure of a communication device 1600 provided in an embodiment of the present application.
  • the communication device 1600 can be a network device, or a terminal device, or a chip, a chip system, or a processor that supports the network device to implement the above method, or a chip, a chip system, or a processor that supports the terminal device to implement the above method.
  • the device can be used to implement the method described in the above method embodiment, and the details can be referred to the description in the above method embodiment.
  • the communication device 1600 may include one or more processors 1601.
  • the processor 1601 may be a general-purpose processor or a dedicated processor, etc.
  • it may be a baseband processor or a central processing unit.
  • the baseband processor may be used to process the communication protocol and communication data
  • the central processing unit may be used to control the communication device (such as a base station, a baseband chip, a terminal device, a terminal device chip, a DU or a CU, etc.), execute a computer program, and process the data of the computer program.
  • the communication device 1600 may further include one or more memories 1602, on which a computer program 1604 may be stored, and the processor 1601 executes the computer program 1604 so that the communication device 1600 performs the method described in the above method embodiment.
  • data may also be stored in the memory 1602.
  • the communication device 1600 and the memory 1602 may be provided separately or integrated together.
  • the communication device 1600 may further include a transceiver 1605 and an antenna 1606.
  • the transceiver 1605 may be referred to as a transceiver unit, a transceiver, or a transceiver circuit, etc., for implementing a transceiver function.
  • the transceiver 1605 may include a receiver and a transmitter, the receiver may be referred to as a receiver or a receiving circuit, etc., for implementing a receiving function; the transmitter may be referred to as a transmitter or a transmitting circuit, etc., for implementing a transmitting function.
  • the communication device 1600 may further include one or more interface circuits 1607.
  • the interface circuit 1607 is used to receive code instructions and transmit them to the processor 1601.
  • the processor 1601 runs the code instructions to enable the communication device 1600 to perform the method described in the above method embodiment.
  • the communication device 1600 is a terminal device: the transceiver 1605 is used to execute steps 301-302 in FIG. 3; steps 401 to 402 in FIG. 4; steps 501 to 503 in FIG. 5; steps 601a to 603a in FIG. 6a; and steps 601b to 602b in FIG. 6b.
  • the processor 1601 is used to execute step 201 in FIG. 2; steps 303-304 in FIG. 3; step 403 in FIG. 4; steps 504 and 505 in FIG. 5; step 604a in FIG. 6a; step 603b in FIG. 6b; and steps 701-702 in FIG. 7.
  • the communication device 1600 is a network device: the transceiver 1605 is used to execute step 1102a in Figure 11a.
  • the processor 1601 is used to execute step 801 in Figure 8; steps 901 to 904 in Figure 9; steps 1001 to 1005 in Figure 10; step 1101a in Figure 11a; and steps 1101b and 1102b in Figure 11b.
  • the processor 1601 may include a transceiver for implementing the receiving and sending functions.
  • the transceiver may be a transceiver circuit, an interface, or an interface circuit.
  • the transceiver circuit, interface, or interface circuit for implementing the receiving and sending functions may be separate or integrated.
  • the above-mentioned transceiver circuit, interface, or interface circuit may be used for reading and writing code/data, or the above-mentioned transceiver circuit, interface, or interface circuit may be used for transmitting or delivering signals.
  • the processor 1601 may store a computer program 1603, which runs on the processor 1601 and enables the communication device 1600 to perform the method described in the above method embodiment.
  • the computer program 1603 may be fixed in the processor 1601, in which case the processor 1601 may be implemented by hardware.
  • the communication device 1600 may include a circuit that can implement the functions of sending or receiving or communicating in the aforementioned method embodiments.
  • the processor and transceiver described in the present application can be implemented in an integrated circuit (IC), an analog IC, a radio frequency integrated circuit RFIC, a mixed signal IC, an application specific integrated circuit (ASIC), a printed circuit board (PCB), an electronic device, etc.
  • the processor and transceiver can also be manufactured using various IC process technologies, such as complementary metal oxide semiconductor (CMOS), N-type metal oxide semiconductor (nMetal-oxide-semiconductor, NMOS), P-type metal oxide semiconductor (positive channel metal oxide semiconductor, PMOS), bipolar junction transistor (bipolar junction transistor, BJT), bipolar CMOS (BiCMOS), silicon germanium (SiGe), gallium arsenide (GaAs), etc.
  • CMOS complementary metal oxide semiconductor
  • N-type metal oxide semiconductor nMetal-oxide-semiconductor
  • PMOS bipolar junction transistor
  • BJT bipolar junction transistor
  • BiCMOS bipolar CMOS
  • SiGe silicon germanium
  • GaAs gallium arsenide
  • the communication device described in the above embodiments may be a network device or a terminal device, but the scope of the communication device described in the present application is not limited thereto, and the structure of the communication device may not be limited by FIG. 16.
  • the communication device may be an independent device or may be part of a larger device.
  • the communication device may be:
  • the IC set may also include a storage component for storing data and computer programs;
  • ASIC such as modem
  • the communication device can be a chip or a chip system
  • the communication device can be a chip or a chip system
  • the schematic diagram of the chip structure shown in Figure 17 includes a processor 1701 and an interface 1702.
  • the number of processors 1701 can be one or more, and the number of interfaces 1702 can be multiple.
  • the chip further includes a memory 1703, and the memory 1703 is used to store necessary computer programs and data.
  • the present application also provides a readable storage medium having instructions stored thereon, which implement the functions of any of the above method embodiments when executed by a computer.
  • the present application also provides a computer program product, which implements the functions of any of the above method embodiments when executed by a computer.
  • the computer program product includes one or more computer programs.
  • the computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.
  • the computer program can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.
  • the computer program can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center.
  • the computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated.
  • the available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a high-density digital video disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.
  • a magnetic medium e.g., a floppy disk, a hard disk, a magnetic tape
  • an optical medium e.g., a high-density digital video disc (DVD)
  • DVD high-density digital video disc
  • SSD solid state disk
  • At least one in the present application can also be described as one or more, and a plurality can be two, three, four or more, which is not limited in the present application.
  • the technical features in the technical feature are distinguished by “first”, “second”, “third”, “A”, “B”, “C” and “D”, etc., and there is no order of precedence or size between the technical features described by the "first”, “second”, “third”, “A”, “B”, “C” and “D”.
  • the corresponding relationships shown in each table in the present application can be configured or predefined.
  • the values of the information in each table are only examples and can be configured as other values, which are not limited by the present application.
  • the corresponding relationships shown in some rows may not be configured.
  • appropriate deformation adjustments can be made based on the above table, such as splitting, merging, etc.
  • the names of the parameters shown in the titles in the above tables can also use other names that can be understood by the communication device, and the values or representations of the parameters can also be other values or representations that can be understood by the communication device.
  • other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables or hash tables.
  • the predefined in the present application may be understood as defined, predefined, stored, pre-stored, pre-negotiated, pre-configured, solidified, or pre-burned.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本公开提出一种API的调用方法、装置、设备及存储介质，属于通信技术领域。API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，根据API调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现"未经资源所有者授权直接访问用户资源"这一情形，从而提高了API调用的安全性。

Description

一种API的调用方法、装置、设备及存储介质 技术领域
本公开涉及通信技术领域，尤其涉及一种API的调用方法/装置/设备及存储介质。
背景技术
在通信***中，引入了一个通用应用编程接口框架(Common Application Programming Interface Framework，CAPIF)，以实现负载平衡和访问控制。其中，该CAPIF可以包括API(Application Programming Interface，应用编程接口)调用实体、通用API框架核心功能(Common API FrameworkCore Function，CCF)、API开放功能(API Exposing Function，AEF)等，其中，AEF可以提供一个或者多个API。
但是，CAPIF中的API调用实体可以直接通过API信息访问提供该API的AEF，并通过AEF调用该API。在这过程中，AEF没有经过资源所有者的授权，即未经资源所有者授权直接访问用户资源，基于此可能会存在非法调用API访问资源，从而降低了API调用的安全性。
发明内容
本公开提出的API的调用方法/装置/设备及存储介质，用于解决相关技术API调用的方法安全性低的技术问题。
第一方面，本公开实施例提供一种API的调用方法，其特征在于，由API开放功能实体执行，包括：
接收API调用实体发送的API调用请求，其中，所述API调用请求中包括API调用信息和用户资源访问令牌；
根据所述API调用信息和所述用户资源访问令牌进行API调用验证。
本公开提供的API的调用方法中，API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，之后，根据API调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌中的用户资源访问信息进行API调用验证，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
第二方面，本公开实施例提供一种API的调用方法，由API调用实体执行，包括：
向API开放功能实体发送API调用请求，其中，所述API调用请求中包括API调用信息和用户资源访问令牌。
第三方面，本公开实施例提供一种通信装置，该装置被配置在API开放功能实体中，包括：
接收模块，用于接收API调用实体发送的API调用请求，其中，所述API调用请求中包括API调用信息和用户资源访问令牌；
调用验证模块，用于根据所述API调用信息和所述用户资源访问令牌进行API调用验证。
第四方面，本公开实施例提供一种API的调用方法，该装置被配置在API调用实体中，包括：
发送模块，用于向API开放功能实体发送API调用请求，其中，所述API调用请求中包括API调用信息和用户资源访问令牌。
第五方面，本公开实施例提供一种通信装置，该通信装置包括处理器，当该处理器调用存储器中的计算机程序时，执行上述第一方面所述的方法。
第六方面，本公开实施例提供一种通信装置，该通信装置包括处理器，当该处理器调用存储器中的计算机程序时，执行上述第二方面所述的方法。
第七方面，本公开实施例提供一种通信装置，该通信装置包括处理器和存储器，该存储器中存储有计算机程序；所述处理器执行该存储器所存储的计算机程序，以使该通信装置执行上述第一方面所述的方法。
第八方面，本公开实施例提供一种通信装置，该通信装置包括处理器和存储器，该存储器中存储有计算机程序；所述处理器执行该存储器所存储的计算机程序，以使该通信装置执行上述第二方面所述的方法。
第九方面，本公开实施例提供一种通信装置，该装置包括处理器和接口电路，该接口电路用于接收代码指令并传输至该处理器，该处理器用于运行所述代码指令以使该装置执行上述第一方面所述的方法。
第十方面，本公开实施例提供一种通信装置，该装置包括处理器和接口电路，该接口电路用于接收代码指令并传输至该处理器，该处理器用于运行所述代码指令以使该装置执行上述第二方面所述的方法。
第十一方面，本公开实施例提供一种通信***，该***包括第三方面所述的通信装置至第四方面所述的通信装置，或者，该***包括第五方面所述的通信装置至第六方面所述的通信装置，或者，该***包括第七方面所述的通信装置至第八方面所述的通信装置，或者，该***包括第九方面所述的通信装置至第十方面所述的通信装置。
第十二方面，本发明实施例提供一种计算机可读存储介质，用于储存为上述网络设备所用的指令，当所述指令被执行时，使所述终端设备执行上述第一方面至第二方面的任一方面所述的方法。
第十三方面，本公开还提供一种包括计算机程序的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面至第二方面的任一方面所述的方法。
第十四方面，本公开提供一种芯片***，该芯片***包括至少一个处理器和接口，用于支持网络设备实现第一方面至第二方面的任一方面所述的方法所涉及的功能，例如，确定或处理上述方法中所涉及的数据和信息中的至少一种。在一种可能的设计中，所述芯片***还包括存储器，所述存储器，用于保存源辅节点必要的计算机程序和数据。该芯片***，可以由芯片构成，也可以包括芯片和其他分立器件。
第十五方面，本公开提供一种计算机程序，当其在计算机上运行时，使得计算机执行上述第一方面至第二方面的任一方面所述的方法。
附图说明
本公开上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为本公开实施例提供的一种通信***的架构示意图；
图2为本公开另一个实施例所提供的API的调用方法的流程示意图；
图3为本公开再一个实施例所提供的API的调用方法的流程示意图；
图4为本公开又一个实施例所提供的API的调用方法的流程示意图；
图5为本公开另一个实施例所提供的API的调用方法的流程示意图；
图6为本公开再一个实施例所提供的API的调用方法的流程示意图；
图7为本公开又一个实施例所提供的API的调用方法的流程示意图；
图8为本公开一个实施例所提供的API的调用方法的流程示意图；
图9为本公开另一个实施例所提供的API的调用方法的流程示意图；
图10为本公开再一个实施例所提供的API的调用方法的流程示意图；
图11为本公开又一个实施例所提供的API的调用方法的流程示意图；
图12为本公开另一个实施例所提供的API的调用方法的流程示意图；
图13为本公开再一个实施例所提供的API的调用方法的交互流程图；
图14为本公开一个实施例所提供的通信装置的结构示意图；
图15为本公开另一个实施例所提供的通信装置的结构示意图；
图16是本公开一个实施例所提供的一种用户设备的框图；
图17为本公开一个实施例所提供的一种网络侧设备的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有 表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开实施例的一些方面相一致的装置和方法的例子。
在本公开实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开实施例。在本公开实施例和所附权利要求书中所使用的单数形式的“一种”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”及“若”可以被解释成为“在……时”或“当……时”或“响应于确定”。
下面详细描述本公开的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的要素。下面通过参考附图描述的实施例是示例性的，旨在用于解释本公开，而不能理解为对本公开的限制。
为了便于理解，首先介绍本申请涉及的术语。
1、通用应用编程接口框架(Common Application Programming Interface Framework，CAPIF)
CAPIF包括API调用实体、通用API框架核心功能(Common API FrameworkCore Function，CCF)、API开放功能(API Exposing Function，AEF)等，其中，AEF可以提供一个或者多个API。
API调用实体通常会从CCF中获取到提供API的AEF的信息，直接访问提供API的AEF。
为了更好的理解本公开实施例公开的一种API的调用方法，下面首先对本公开实施例适用的通信***进行描述。
请参见图1，图1为本公开实施例提供的一种通信***的架构示意图。该通信***可包括但不限于一个网络设备和一个终端设备，图1所示的设备数量和形态仅用于举例并不构成对本公开实施例的限定，实际应用中可以包括两个或两个以上的网络设备，两个或两个以上的终端设备。图1所示的通信***以包括一个终端设备11、一个核心网设备12为例。
需要说明的是，本公开实施例的技术方案可以应用于各种通信***。例如：长期演进(long term evolution，LTE)***、第五代(5th generation，5G)移动通信***、5G新空口(new radio，NR)***，或者其他未来的新型移动通信***等。
本公开实施例中的核心网设备12是部署在核心网中的设备，核心网设备12的功能主要是提供用户连接、对用户的管理以及对业务完成承载，作为承载网络提供到外部网络的接口。例如，5G NR***中的核心网设备可以包括接入和移动性管理功能(Access and Mobility Management Function，AMF)网元、用户平面功能(User Plane Function，UPF)网元和会话管理功能(Session Management Function，SMF)网元等。
示例性的，本申请实施例中的核心网设备12可以包括位置管理功能网元。可选地，位置管理功能网元包括位置服务器(location server)，位置服务器可以实现为以下任意一项：LMF(Location Management Function，位置管理网元)、E SMLC(Enhanced Serving Mobile Location Centre，增强服务的流动定位中心)、SUPL(Secure User Plane Location，安全用户平面定位)、SUPL SLP(SUPL Location Platform，安全用户平面定位定位平台)。
本公开实施例中的终端设备11是用户侧的一种用于接收或发射信号的实体，如手机。终端设备也可以称为终端设备(terminal)、用户设备(user equipment，UE)、移动台(mobile station，MS)、移动终端设备(mobile terminal，MT)等。终端设备可以是具备通信功能的汽车、智能汽车、手机(mobile phone)、穿戴式设备、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality，AR)终端设备、工业控制(industrial control)中的无线终端设备、无人驾驶(self-driving)中的无线终端设备、远程手术(remote medical surgery)中的无线终端设备、智能电网(smart grid)中的无线终端设备、运输安全(transportation safety)中的无线终端设备、智慧城市(smart city)中的无线终端设备、智慧家庭(smart home)中的无线终端设备等等。本公开的实施 例对终端设备所采用的具体技术和具体设备形态不做限定。
可以理解的是，本公开实施例描述的通信***是为了更加清楚的说明本公开实施例的技术方案，并不构成对于本公开实施例提供的技术方案的限定，本领域普通技术人员可知，随着***架构的演变和新业务场景的出现，本公开实施例提供的技术方案对于类似的技术问题，同样适用。
其中，在本公开的一个实施例中，SNAAPP安全性研究的目标之一是获得资源所有者的授权，在TS22.261规定，“允许UE(User Equipment，用户设备)提供/撤销对与第三方共享的信息(例如，位置、存在)的同意”。基于此，API调用实体要调用特定的服务API来获取/修改/设置特定的用户资源(例如位置、QoS)，在API调用过程中应同时使用用户资源授权信息和API授权信息。为满足上述“在API调用过程中应同时使用用户资源授权信息和API授权信息”这个条件，本公开提出了一种API的调用方法。
下面参考附图对本公开实施例所提供的API的调用方法/装置/设备及存储介质进行详细描述。
图2为本公开实施例所提供的一种API的调用方法的流程示意图，其中，该方法由API开放功能实体执行，如图2所示，该API的调用方法可以包括以下步骤：
步骤201、接收API调用实体发送的API调用请求，API调用请求中包括API调用信息和用户资源访问令牌。
其中，在本公开的一个实施例中，上述API调用实体可以是UE或AF(Application Function，应用功能)。并且，在本公开的另一个实施例中，上述API开放功能实体可以是AEF。
以及，在本公开的一个实施例中，上述API调用信息可以包括以下中的至少一项：
API调用实体的第一身份标识；
第一资源所有者身份标识(如GPSI(Generic Public Subscription Identifier，通用公共订阅标识符)或者IMSI(International Mobile Subscriber Identity，国际移动用户识别码)，或者应用层ID(Identity，序号))；
需要调用的服务API标识符；
需要调用的服务标识符；
需要访问的用户资源标识符(如位置)。
进一步地，在本公开的一个实施例中，上述用户资源访问令牌可以包括以下一项或多项：
CAPIF(Common Application Programming Interface Framework，通用应用编程接口框架)核心功能身份(如NF(Network Function，网络功能)instance(实例)ID或者NF ID)；
授权功能身份(如NF instance ID或者NF ID)；
API开放功能实体的第一身份标识(如NF instance ID或者NF ID)；
API调用实体的第二身份标识；
第二资源所有者身份标识(如GPSI(Generic Public Subscription Identifier，通用公共订阅标识符)或者IMSI(International Mobile Subscriber Identity，国际移动用户识别码)，或者应用层ID)；
用户资源标识符(如位置)；
过期时间。
其中，在本公开的一个实施例中，上述服务标识符可以包括以下至少一种：
服务名称标识符(Service Name)；
服务操作标识符(Service Operation)；
操作语义标识(Operation Semantics)。
以及，在本公开的一个实施例中，API开放功能实体接收API调用实体发送的API调用请求之前，需要与API调用实体进行相互身份认证，并在进行相互身份认证后建立安全连接，以保证交互过程的安全。以及，在本公开的一个实施例中，API调用实体与API开放功能实体进行相互身份认证后，API调用实体会有认证后的身份标识，以便后续API开放功能实体对API调用实体进行身份认证。其中，关于建立网络连接的过程会在后续实施例中进行详细介绍。
在本公开的一个实施例中，用户资源访问信息可以包括第二资源所有者身份标识，和/或用户资源 标识符。关于上述API调用信息中的API调用实体的第一身份标识、第一资源所有者身份标识与用户资源访问令牌中的API调用实体的第二身份标识、第二资源所有者身份标识会在后续实施例中进行详细介绍。
步骤202、根据API调用信息和用户资源访问令牌进行API调用验证。
其中，在本公开的一个实施例中，根据API调用信息和用户资源访问令牌进行API调用验证时，可以根据API调用信息和用户资源访问令牌对API调用请求进行用户资源访问验证和API调用验证，并且当用户资源访问验证和API调用验证均通过时，判断API调用请求通过验证。
以及，在本公开的一个实施例中，当API调用请求中内容不同时，上述根据API调用信息和用户资源访问令牌进行API调用验证的方法也有所不同。关于这部分内容会在后续实施例中进行详细介绍。
综上所述，在本公开实施例提供的API的调用方法中，API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，之后，根据API调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌中的用户资源访问信息进行API调用验证，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图3为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API开放功能实体执行，如图3所示，该API的调用方法可以包括以下步骤：
步骤301、接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌。
步骤302、根据用户资源访问令牌对API调用请求进行用户资源访问验证。
其中，在本公开的一个实施例中，API开放功能实体根据用户资源访问令牌对API调用请求进行用户资源访问验证的方法可以包括：对用户资源访问令牌进行有效性校验，确定用户资源访问令牌有效后，根据用户资源访问令牌对API调用请求进行用户资源访问验证。
具体的，在本公开的一个实施例中，API开放功能实体对用户资源访问令牌进行有效性校验的方法可以包括：验证用户资源访问令牌的有效性(即令牌是否被篡改)，若用户资源令牌无效，说明用户资源访问令牌已被篡改，则API开放功能实体终止后续验证，确定未通过用户资源访问验证；若用户资源访问令牌有效，说明用户资源访问令牌未被篡改，则完成对用户资源访问令牌的有效性校验，确定用户资源访问令牌有效。
其中，在本公开的一个实施例中，上述API开放功能实体验证用户资源访问令牌的有效性的方法可以包括：若用户资源访问令牌是JSONWeb令牌，则API开放功能实体使用CAPIF核心功能/授权功能的公钥来验证令牌是否有效(即令牌是否被篡改)；若用户资源访问令牌不是JSON Web令牌，则API开放功能实体会将用户资源访问令牌发送到CAPFI核心功能/授权功能，并接收CAPIF核心功能/授权功能的指示，若接收CAPIF核心功能/授权功能指示用户资源访问令牌有效，则确定用户资源访问令牌有效；否则，确定用户资源访问令牌无效。
需要说明的是，在本公开的一个实施例中，上述对用户资源访问令牌的有效性进行校验的过程中，验证了用户资源访问令牌的有效性，从而通过上述校验方法确保接收到的用户资源访问令牌中的信息是可用的。
进一步地，在本公开的一个实施例中，确定用户资源访问令牌有效后，上述API开放功能实体还需要根据用户资源访问令牌对API调用请求进行用户资源访问验证。
其中，在本公开的一个实施例中，用户资源访问令牌中的第二资源所有者身份标识和/或用户资源标识符为API调用实体可以访问的用户资源访问信息，基于此，需要利用资源访问令牌中API调用实体可以访问的信息与API调用信息中API调用实体要访问的信息进行比较，从而确定API调用请求是否通过用户资源访问验证。
以及，在本公开的一个实施例中，根据用户资源访问令牌对API调用请求进行用户资源访问验证的方法可以包括：确定用户资源访问令牌与API调用信息中对应相同标识的值是否相同，若对应相同 标识的值均相同，则确定API调用请求通过用户资源访问验证；否则，确定API调用请求未通过用户资源访问验证，以及API开放功能实体终止后续验证，。
具体的，在本公开的一个实施例中，若API调用信息中的API调用实体的第一身份标识和用户资源访问令牌中的API调用实体的第二身份标识，与该API调用实体身份认证后的标识不相同，和/或，无法映射到API调用实体身份认证后的标识，则API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证；否则，若API调用信息中的第一资源所有者身份标识与用户资源访问令牌中的第二资源所有者身份标识不相同，则API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证；否则，若API调用信息中的需要访问的用户资源标识符与用户资源访问令牌中的用户资源标识符不相同，则API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证；否则，若用户资源访问令牌中的API开放功能实体的第一身份标识与API开放功能实体的身份标识不相同，和/或，无法映射到API开放功能实体的身份标识，则API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证；否则，确认API调用请求通过用户资源访问验证。
其中，在本公开的一个实施例中，通过上述内容可知，确定用户资源访问令牌有效后，API开放功能实体会首先对API调用实体进行身份验证，并当API调用信息中API调用实体的第一身份标识以及用户资源访问令牌中的API调用实体的第二身份标识，与API调用实体认证后的身份标识一致，或者可以映射到认证后的身份标识，才会继续后续验证；否则，API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证，从而确定了API调用实体的身份，避免了未经身份认证的API调用实体进行API调用，保证了API调用的安全性。
以及，在本公开的一个实施例中，通过上述内容可知，API调用信息中的API调用实体的第一身份标识、第一资源所有者身份标识是为了与用户资源访问令牌中的API调用实体的第二身份标识、第二资源所有者身份标识进行比对，从而进一步确定用户资源访问令牌中的信息可用。
以及，在本公开的一个实施例中，若确认API调用请求通过用户资源访问验证，则说明授权API调用实体访问用户资源；若确认API调用请求未通过用户资源访问验证，则说明未授权API调用实体访问用户资源。
步骤303、通过调用CAPIF核心功能或授权功能对API调用请求进行API调用验证。
其中，在本公开的一个实施例中，上述用户资源访问令牌中仅包括用户资源访问信息(如第二资源所有者身份标识和/或用户资源标识符)，并不包括API使用信息(如服务API标识符和/或服务标识符)。基于此，API开放功能实体无法根据用户资源访问令牌确定API调用实体可以调用的API使用信息，从而无法根据用户资源访问令牌对API调用请求进行API调用验证，此时需要通过调用CAPIF核心功能或授权功能对API调用请求进行API调用验证。
具体的，在本公开的一个实施例中，通过调用CAPIF核心功能或授权功能对API调用请求进行API调用验证的方法可以包括：API开放功能实体将API调用信息中的API调用实体的第一身份标识和需要调用的服务API标识符/需要调用的服务标识符发送至CCF/AF(Authorization function，授权功能)进行API授权，从而根据接收到的CCF/AF发送的响应确定API调用请求是否通过API调用验证。其中，若接收到的CCF/AF发送的授权响应，则确定API调用请求通过API调用验证；否则，确定API调用请求未通过API调用验证。
以及，在本公开的一个实施例中，若确认API调用请求通过API调用验证，则说明授权API调用实体调用服务API和/或服务；若确认API调用请求未通过API调用验证，则说明未授权API调用实体调用服务API和/或服务。
步骤304、当用户资源访问验证和API调用验证均通过时，判断API调用请求通过验证。
其中，在本公开的一个实施例中，当用户资源访问验证和API调用验证均通过时，判断API调用请求通过验证，此时确定授权API调用实体访问用户资源和调用服务API和/或服务；否则，判断API调用请求未通过验证，此时确定未授权API调用实体访问用户资源和/或调用服务API和/或服务。
综上所述，在本公开实施例提供的API的调用方法中，API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，之后，根据API 调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图4为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API开放功能实体执行，如图4所示，该API的调用方法可以包括以下步骤：
步骤401、接收API调用实体发送的API调用请求，API调用请求中包括API调用信息和用户资源访问令牌，用户资源访问令牌中包括服务API标识符和服务标识符。
步骤402、根据用户资源访问令牌对API调用请求进行用户资源访问验证和API调用验证。
其中，在本公开的一个实施例中，API开放功能实体根据用户资源访问令牌对API调用请求进行用户资源访问验证和API调用验证的方法可以包括：对用户资源访问令牌进行有效性校验，确定用户资源访问令牌有效后，根据用户资源访问令牌对API调用请求进行用户资源访问验证和API调用验证。
关于API开放功能实体对用户资源访问令牌进行有效性校验的方法可以参考上述实施例中相关介绍，本公开实施例在此不做赘述。
以及，在本公开的一个实施例中，本实施例与上述实施例的区别在于，本实施例中用户资源访问令牌除了包括上述信息外，还包括：服务API标识符和/或服务标识符，其中用户资源访问令牌中的服务API标识符和/或服务标识符为API调用实体可以访问的API使用信息。
由此，本实施例中，用户资源访问令牌中用户资源访问信息和API使用信息。基于此，API开放功能实体确定用户资源访问令牌有效后，可以根据用户资源访问令牌对API调用请求进行用户资源访问验证和API调用验证。
具体的，在本公开的一个实施例中，根据用户资源访问令牌对API调用请求进行用户资源访问验证和API调用验证的方法可以包括：确定用户资源访问令牌与API调用信息中对应相同标识的值是否相同，若对应相同标识的值均相同，则确定API调用请求通过用户资源访问验证和API调用验证；否则，确定API调用请求未通过用户资源访问验证或API调用验证，则API开放功能实体终止后续验证。
具体的，在本公开的一个实施例中，若API调用信息中的API调用实体的第一身份标识和用户资源访问令牌中的API调用实体的第二身份标识，与该API调用实体身份认证后的标识不相同，和/或，无法映射到API调用实体身份认证后的标识，则API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证；否则，若API调用信息中的第一资源所有者身份标识与用户资源访问令牌中的第二资源所有者身份标识不相同，则API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证；否则，若API调用信息中的需要访问的用户资源标识符与用户资源访问令牌中的用户资源标识符不相同，则API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证；否则，若用户资源访问令牌中的API开放功能实体的第一身份标识与API开放功能实体的身份标识不相同，和/或，无法映射到API开放功能实体的身份标识，则API开放功能实体终止后续验证，确定API调用请求未通过用户资源访问验证；否则，确认API调用请求通过用户资源访问验证。
以及，在本公开的一个实施例中，若API调用信息中的需要调用的服务API标识符与用户资源访问令牌中的服务API标识符不相同，则API开放功能实体终止后续验证，确定API调用请求未通过API调用验证；否则，若API调用信息中的需要调用的服务标识符与用户资源访问令牌中的服务API操作符不相同，则API开放功能实体终止后续验证，确定API调用请求未通过API调用验证；否则，确定API调用请求通过API调用验证。
步骤403、当用户资源访问验证和所述API调用验证均通过时，判断API调用请求通过验证。
关于步骤403的详细介绍可以参考上述实施例中的相关介绍，本公开实施例在此不做赘述。
综上所述，在本公开实施例提供的API的调用方法中，API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，之后，根据API调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌 确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图5为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API开放功能实体执行，如图5所示，该API的调用方法可以包括以下步骤：
步骤501、接收API调用实体发送的API调用请求，API调用请求中包括API调用信息、用户资源访问令牌和API访问令牌。
其中，在本公开的一个实施例中，上述API访问令牌可以包括以下一项或多项：
API调用实体的第三身份标识；
API开放功能实体的第二身份标识；
用户资源标识符；
服务API标识符；
服务标识符。
其中，在本公开的一个实施例中，上述用户资源访问令牌和API访问令牌可以属于不同令牌或者同属于一个令牌。
步骤502、根据用户资源访问令牌对API调用请求进行用户资源访问验证。
关于步骤502的详细介绍可以参考上述实施例中的相关介绍，本公开实施例在此不做赘述。
步骤503、根据API访问令牌对API调用请求进行API调用验证。
其中，在本公开的一个实施例中，API开放功能实体根据API访问令牌对API调用请求进行API调用验证的方法可以包括：对API访问令牌进行有效性校验，确定API访问令牌有效后，根据API访问令牌对API调用请求进行API调用验证。
具体的，在本公开的一个实施例中，API开放功能实体对API访问令牌进行有效性校验的方法可以包括：验证API访问令牌的有效性(即令牌是否被篡改)，若API访问令牌无效，说明API访问令牌已被篡改，则API开放功能实体终止后续验证，确定未通过API调用验证；若API访问令牌有效，说明API访问令牌未被篡改，则完成对API访问令牌的有效性校验，确定API访问令牌有效。
其中，在本公开的一个实施例中，上述API开放功能实体验证API访问令牌的有效性的方法可以包括：若API访问令牌是JSON Web令牌，则API开放功能实体使用CAPIF核心功能/授权功能的公钥来验证API访问令牌是否有效；若API访问令牌不是JSON Web令牌，则API开放功能实体会将API访问令牌发送到CAPFI核心功能/授权功能，并接收CAPIF核心功能/授权功能的指示，若接收CAPIF核心功能/授权功能指示API访问令牌有效，则确定API访问令牌有效；否则，确定API访问令牌无效。
以及，在本公开的一个实施例中，当上述用户资源访问令牌和API访问令牌属于不同令牌时，API调用实体向API开放功能实体发送用户资源访问令牌和API访问令牌后，API开放功能实体需要对用户资源访问令牌和API访问令牌均进行认证。
在本公开的另一个实施例中，当上述用户资源访问令牌和API访问令牌同属于一个令牌时，API调用实体向API开放功能实体发送用户资源访问令牌和API访问令牌后，API开放功能实体需要仅需对用户资源访问令牌和API访问令牌同属的令牌进行有效性校验。关于有效性校验的方法可以参考上述实施例中的相关描述。
进一步地，在本公开的一个实施例中，确定API访问令牌有效后，上述API开放功能实体还需要根据API访问令牌对API调用请求进行API调用验证。
其中，在本公开的一个实施例中，API访问令牌中的服务API标识符和/或服务标识符为API调用实体可以调用的API使用信息，以及用户资源标识符为API调用实体可以访问的用户资源访问信息，基于此，需要利用API访问令牌中API调用实体可以调用的API使用信息和用户资源访问信息与API调用信息中API调用实体要调用的API使用信息和用户资源访问信息进行比较，从而确定API调用请求是否通过API调用验证。
以及，在本公开的一个实施例中，根据API访问令牌对调用请求进行用户资源访问验证的方法可以包括：确定API访问令牌与API调用信息中对应相同标识的值是否相同，若对应相同标识的值均相 同，则确定API调用请求通过API调用验证；否则，确定API调用请求未通过API调用验证，以及API开放功能实体终止后续验证。
具体的，在本公开的一个实施例中，若API调用信息中的API调用实体的第一身份标识和API访问令牌中的API调用实体的第三身份标识，与该API调用实体身份认证后的标识不相同，或者，无法映射到API调用实体身份认证后的标识，则API开放功能实体终止后续验证，确定API调用请求未通过API调用验证；否则，若API调用信息中的需要调用的服务API标识符与API访问令牌中的服务API标识符不相同，则API开放功能实体终止后续验证，确定API调用请求未通过API调用验证；否则，若API调用信息中的需要调用的服务标识符与API访问令牌中的服务标识符不相同，则API开放功能实体终止后续验证，确定API调用请求未通过API调用验证；否则，若API访问令牌中的API开放功能实体的第二身份标识与API开放功能实体的身份标识不相同，和/或，无法映射到API开放功能实体的身份标识，则API开放功能实体终止后续验证，确定API调用请求未通过API调用验证；否则，若API调用信息中的需要访问的用户资源标识符与API访问令牌中的用户资源标识符不相同，则API开放功能实体终止后续验证，确定API调用请求未通过API调用验证；否则，确定API调用请求通过API调用验证。
步骤504、当用户资源访问验证和API调用验证均通过时，判断API调用请求通过验证。
关于步骤504的详细介绍可以参考上述实施例中的相关介绍，本公开实施例在此不做赘述。
综上所述，在本公开实施例提供的API的调用方法中，API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，之后，根据API调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图6为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API开放功能实体执行，如图6所示，该API的调用方法可以包括以下步骤：
步骤601、向API调用实体发送API调用响应。
其中，在本公开的一个实施例中，API开放功能实体可以根据上述实施例中得到的API调用验证的结果，向API调用实体发送API调用响应。
具体的，在本公开的一个实施例中，当确定API调用请求通过验证时，说明API调用实体被授权访问用户资源和调用服务API和/或服务，则API开放功能实体向API调用实体发送授权API调用响应；当确定API调用请求未通过验证时，说明API调用实体未被授权访问用户资源和/或调用服务API和/或服务，则API开放功能实体向API调用实体发送拒绝/终止API调用响应。
以及，在本公开的一个实施例中，API开放功能实体向API调用实体发送API调用响应后，API调用实体可根据接收到的API调用响应进行进行操作。
综上所述，在本公开实施例提供的API的调用方法中，API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，之后，根据API调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图7为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API开放功能实体执行，如图7所示，该API的调用方法可以包括以下步骤：
步骤701、与API调用实体进行相互身份认证。
其中，在本公开的一个实施例中，通过以下任一认证机制与API调用实体进行相互身份认证：
TLS-PSK(Transport Layer Security-Pre-Shared Key，安全传输层协议-预共享密钥)；
PKI(Public Key Infrastructure，公钥基础设施)；
Oauth(Open Authorization，开放授权)协议证书；
基于GBA(General Bootstrapping Architecture，通用认证机制)的认证机制；
基于AKMA(Application layer Authentication and Key Management，应用层鉴权和密钥管理)的认证机制；
基于证书的认证机制。
步骤702、响应于身份认证成功，建立与API调用实体之间的安全连接。
其中，在本公开的一个实施例中，响应于身份认证成功，可以通过TLS(Transport Layer Security，传输层安全)建立与API调用实体之间的安全连接。
以及，在本公开的一个实施例中，在与API调用实体建立安全连接之后，API开放功能实体可以通过安全连接与API调用实体进行交互，如接收API调用实体发送的API调用请求，或者，向API调用实体发送API调用响应。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的API的调用方法中，API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，之后，根据API调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图8为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API调用实体执行，如图8所示，该API的调用方法可以包括以下步骤：
步骤801、向API开放功能实体发送API调用请求，API调用请求中包括API调用信息和用户资源访问令牌。
其中，在本公开的一个实施例中，上述API调用实体可以是UE或AF。
以及，在本公开的一个实施例中，上述API调用信息可以包括以下一项或多项：
API调用实体的第一身份标识；
第一资源所有者身份标识(如GPSI或者IMSI，或者应用层ID)；
需要调用的服务API标识符；
需要调用的服务标识符；
需要访问的用户资源标识符(如位置)。
进一步地，在本公开的一个实施例中，上述用户资源访问令牌可以包括以下一项或多项：
CAPIF核心功能身份(如NF instance ID或者NF ID)；
授权功能身份(如NF instance ID或者NF ID)；
API开放功能实体的身份标识(如NF instance ID、NF ID)；
API调用实体的第二身份标识；
第二资源所有者身份标识(如GPSI或者IMSI，或者应用层ID)；
用户资源标识符(如位置)；
过期时间。
进一步地，在本公开的一个实施例中，API调用实体向API开放功能实体发送API调用请求之后，API开放功能实体可以根据API调用信息和用户资源访问令牌进行API调用验证。
关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的API的调用方法中，API调用实体向API开放功能实体发送API调用请求，API调用请求中包括API调用信息和用户资源访问令牌。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图9为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API调用实体执行，如图9所示，该API的调用方法可以包括以下步骤：
步骤901、向API开放功能实体发送API调用请求，API调用请求中包括API调用信息和用户资源访问令牌，用户资源访问令牌中包括服务API标识符和服务标识符。
在本公开的一个实施例中，本实施例与上述图8的实施例的区别在于，本实施例中用户资源访问令牌除了包括上述信息外，还包括：服务API标识符和/或服务标识符。
由此，本实施例中用户资源访问令牌包括的内容与图8实施例中用户资源访问令牌包括的内容不同，基于此，后续API开放功能实体根据API调用信息和用户资源访问令牌进行API调用验证的方法也有所不同。关于这部分内容的详细介绍可以参考上述实施例中的相关介绍，本公开实施例在此不做赘述。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的API的调用方法中，API调用实体会向API开放功能实体发送API调用请求，API调用请求中包括API调用信息和用户资源访问令牌。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图10为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API调用实体执行，如图10所示，该API的调用方法可以包括以下步骤：
步骤1001、向API开放功能实体发送API调用请求，API调用请求中包括API调用信息、用户资源访问令牌和API访问令牌。
其中，在本公开的一个实施例中，上述API访问令牌可以包括以下一项或多项：
API调用实体的第三身份标识；
服务API标识符；
服务标识符。
以及，在本公开的一个实施例中，上述用户资源访问令牌和API访问令牌可以属于不同令牌或者同属于一个令牌。
其中，在本公开的一个实施例中，当上述用户资源访问令牌和API访问令牌属于不同令牌时，API调用实体向API开放功能实体发送用户资源访问令牌和API访问令牌后，API开放功能实体需要对用户资源访问令牌和API访问令牌均进行认证。
以及，在本公开的一个实施例中，当上述用户资源访问令牌和API访问令牌同属于一个令牌时，API调用实体向API开放功能实体发送用户资源访问令牌和API访问令牌后，API开放功能实体需要仅需对用户资源访问令牌和API访问令牌同属的令牌进行认证。以及，关于这部分内容的详细介绍可以参考上述实施例中的相关介绍，本公开实施例在此不做赘述。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的API的调用方法中，API调用实体会向API开放功能实体发送API调用请求，API调用请求中包括API调用信息和用户资源访问令牌。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图11为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API调用实体执行，如图11所示，该API的调用方法可以包括以下步骤：
步骤1101、接收API开放功能实体发送的API调用响应。
其中，在本公开的一个实施例中，API调用实体向API开放功能实体发送API调用请求之后，API开放功能实体可以根据接收到API调用信息和用户资源访问令牌对API调用请求进行API调用验证，并根据验证结果确定API调用响应。
具体的，在本公开的一个实施例中，当API调用请求未通过API调用验证，则API调用实体接收 API开放功能实体发送的拒绝/终止API调用响应。以及，在本公开的另一个实施例中，当API调用请求通过API调用验证，则API调用实体接收API开放功能实体发送的授权API调用响应。
其中，在本公开的一个实施例中，当接收API开放功能实体发送的API调用响应为拒绝/终止API调用响应，则API调用实体不能调用对应的服务API和/或服务。
以及，在本公开的一个实施例中，当将收API开放功能实体发送的API调用响应为授权API调用响应，则API调用实体可以调用对应的服务API和/或服务。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的API的调用方法中，API调用实体会向API开放功能实体发送API调用请求，API调用请求中包括API调用信息和用户资源访问令牌。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
图12为本公开实施例所提供的一种API的调用方法的流程示意图，该方法由API调用实体执行，如图12所示，该API的调用方法可以包括以下步骤：
步骤1201、与API开放功能实体进行相互身份认证。
其中，在本公开的一个实施例中，通过以下任一认证机制与API开放功能实体进行相互身份认证：
TLS-PSK；
PKI；
OAuth协议证书；
基于GBA的认证机制；
基于AKMA的认证机制；
基于证书的认证机制。
步骤1202、响应于身份认证成功，建立与API开放功能实体之间的安全连接。
其中，在本公开的一个实施例中，响应于身份认证成功，可以通过TLS建立与API开放功能实体之间的安全连接。
以及，在本公开的一个实施例中，在API调用实体与API开放功能实体建立安全连接之后，API调用实体可以通过安全连接与API开放功能实体进行交互，如向API开放功能实体发送API调用请求，或者，接收API开放功能实体发送的API调用响应。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的API的调用方法中，API调用实体会向API开放功能实体发送API调用请求，API调用请求中包括API调用信息和用户资源访问令牌。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
基于上述描述，图13为本公开一个实施例提供的一种API的调用方法的交互流程图，如图13所示，具体可以包括以下步骤：
步骤1301、API调用者(即上述API调用实体)与AEF(即上述API开放功能实体)进行相互认证(即上述身份认证)。
步骤1302、API调用实体向AEF发送服务API调用请求(即上述API调用请求)。
步骤1303、AEF进行API调用请求授权验证。
步骤1304、AEF通过CAPIF核心功能/授权功能进行API调用请求授权和授权验证。
步骤1305、AEF向API调用实体发送服务API调用响应(即上述API调用响应)。
图14为本公开实施例所提供的一种通信装置的结构示意图，如图15所示，装置可以包括：
接收模块1401，用于接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌；
验证模块1402，用于根据API调用信息和用户资源访问令牌进行API调用验证。
综上所述，在本公开实施例提供的通信装置中，API开放功能实体会接收API调用实体发送的API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌，之后，根据API调用信息和用户资源访问令牌进行API调用验证。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
可选的，在本公开的一个实施例中，API调用请求中还包括API访问令牌。
可选的，在本公开的一个实施例中，用户资源访问令牌和所述API访问令牌同属于一个令牌。
可选的，在本公开的一个实施例中，API调用信息包括以下一项或多项：
API调用实体的第一身份标识；
第一资源所有者身份标识；
需要调用的服务API标识符；
需要调用的服务标识符；
需要访问的用户资源标识符。
可选的，在本公开的一个实施例中，用户资源访问令牌包括以下一项或多项：
CAPIF核心功能身份；
授权功能身份；
所述API开放功能实体的身份标识；
所述API调用实体的第二身份标识；
第二资源所有者身份标识；
用户资源标识符；
过期时间。
可选的，在本公开的一个实施例中，用户资源访问令牌还包括：
服务API标识符；
服务标识符。
可选的，在本公开的一个实施例中，上述验证模块1402，还用于：
根据用户资源访问令牌对API调用请求进行用户资源访问验证；
通过调用CAPIF核心功能或授权功能对API调用请求进行API调用验证；
当用户资源访问验证和API调用验证均通过时，判断API调用请求通过验证。
可选的，在本公开的一个实施例中，上述验证模块1402，还用于：
根据用户资源访问令牌对API调用请求进行用户资源访问验证和API调用验证；
当用户资源访问验证和API调用验证均通过时，判断API调用请求通过验证。
可选的，在本公开的一个实施例中，上述验证模块1402，还用于：
根据用户资源访问令牌对API调用请求进行用户资源访问验证；
根据API访问令牌对API调用请求进行API调用验证；
当用户资源访问验证和API调用验证均通过时，判断API调用请求通过验证。
可选的，在本公开的一个实施例中，上述装置，还用于：
向API调用实体发送API调用响应。
可选的，在本公开的一个实施例中，上述装置，还用于：
与所述API调用实体进行相互身份认证；
可选的，在本公开的一个实施例中，上述装置，还用于通过以下任一认证机制与API调用实体进行相互身份认证：
TLS-PSK；
PKI；
OAuth协议证书；
基于GBA的认证机制；
基于AKMA的认证机制；
基于证书的认证机制。
可选的，在本公开的一个实施例中，上述装置，还用于：
响应于身份认证成功，建立与API开放功能实体之间的安全连接。
图15为本公开实施例所提供的一种通信装置的结构示意图，如图15所示，装置可以包括：
发送模块1501，用于向API开放功能实体发送API调用请求，其中，API调用请求中包括API调用信息和用户资源访问令牌。
综上所述，在本公开实施例提供的通信装置中，API调用实体会向API开放功能实体发送API调用请求，API调用请求中包括API调用信息和用户资源访问令牌。由此可知，本公开提供的方法中，API开放功能实体可以通过用户资源访问令牌进行API调用验证，也即是API开放功能实体可以利用用户资源访问令牌确定是否授权API调用实体访问用户资源和调用服务API，则避免出现“未经资源所有者授权直接访问用户资源”这一情形，从而提高了API调用的安全性。
可选的，在本公开的一个实施例中，API调用请求中还包括API访问令牌。
可选的，在本公开的一个实施例中，用户资源访问令牌和所述API访问令牌同属于一个令牌。
可选的，在本公开的一个实施例中，API调用信息包括以下一项或多项：
API调用实体的第一身份标识；
第一资源所有者身份标识；
需要调用的服务API标识符；
需要调用的服务标识符；
需要访问的用户资源标识符。
可选的，在本公开的一个实施例中，用户资源访问令牌包括以下一项或多项：
CAPIF核心功能身份；
授权功能身份；
API开放功能实体的身份标识；
API调用实体的第二身份标识；
第二资源所有者身份标识；
用户资源标识符；
过期时间。
可选的，在本公开的一个实施例中，用户资源访问令牌还包括：
服务API标识符；
服务标识符。
可选的，在本公开的一个实施例中，上述装置，还用于：
接收API开放功能实体发送的API调用响应。
可选的，在本公开的一个实施例中，上述装置，还用于：
与API开放功能实体进行相互身份认证；
可选的，在本公开的一个实施例中，上述装置，还用于通过以下任一认证机制与API开放功能实体进行相互身份认证：
TLS-PSK；
PKI；
OAuth协议证书；
基于GBA的认证机制；
基于AKMA的认证机制；
基于证书的认证机制。
可选的，在本公开的一个实施例中，上述装置，还用于：
响应于身份认证成功，建立与API开放功能实体之间的安全连接。
请参见图16，图16是本申请实施例提供的一种通信装置1600的结构示意图。通信装置1600可以是网络设备，也可以是终端设备，也可以是支持网络设备实现上述方法的芯片、芯片***、或处理器等，还可以是支持终端设备实现上述方法的芯片、芯片***、或处理器等。该装置可用于实现上述方法实施例中描述的方法，具体可以参见上述方法实施例中的说明。
通信装置1600可以包括一个或多个处理器1601。处理器1601可以是通用处理器或者专用处理器等。例如可以是基带处理器或中央处理器。基带处理器可以用于对通信协议以及通信数据进行处理，中央处理器可以用于对通信装置(如，基站、基带芯片，终端设备、终端设备芯片，DU或CU等)进行控制，执行计算机程序，处理计算机程序的数据。
可选的，通信装置1600中还可以包括一个或多个存储器1602，其上可以存有计算机程序1604，处理器1601执行所述计算机程序1604，以使得通信装置1600执行上述方法实施例中描述的方法。可选的，所述存储器1602中还可以存储有数据。通信装置1600和存储器1602可以单独设置，也可以集成在一起。
可选的，通信装置1600还可以包括收发器1605、天线1606。收发器1605可以称为收发单元、收发机、或收发电路等，用于实现收发功能。收发器1605可以包括接收器和发送器，接收器可以称为接收机或接收电路等，用于实现接收功能；发送器可以称为发送机或发送电路等，用于实现发送功能。
可选的，通信装置1600中还可以包括一个或多个接口电路1607。接口电路1607用于接收代码指令并传输至处理器1601。处理器1601运行所述代码指令以使通信装置1600执行上述方法实施例中描述的方法。
通信装置1600为终端设备：收发器1605用于执行图3中的步骤301-步骤302；图4中的步骤401至步骤402；图5中的步骤501至步骤503；图6a中的步骤601a至步骤603a；图6b中的步骤601b至步骤602b。处理器1601用于执行图2中的步骤201；图3中的步骤303-步骤304；图4中的步骤403；图5中的步骤504和步骤505；图6a中的步骤604a；图6b中的步骤603b；图7中的步骤701-步骤702。
通信装置1600为网络设备：收发器1605用于执行图11a中的步骤1102a。处理器1601用于执行图8中的步骤801；图9中的步骤901至步骤904；图10中的步骤1001至步骤1005；图11a中的步骤1101a；图11b中的步骤1101b和步骤1102b。
在一种实现方式中，处理器1601中可以包括用于实现接收和发送功能的收发器。例如该收发器可以是收发电路，或者是接口，或者是接口电路。用于实现接收和发送功能的收发电路、接口或接口电路可以是分开的，也可以集成在一起。上述收发电路、接口或接口电路可以用于代码/数据的读写，或者，上述收发电路、接口或接口电路可以用于信号的传输或传递。
在一种实现方式中，处理器1601可以存有计算机程序1603，计算机程序1603在处理器1601上运行，可使得通信装置1600执行上述方法实施例中描述的方法。计算机程序1603可能固化在处理器1601中，该种情况下，处理器1601可能由硬件实现。
在一种实现方式中，通信装置1600可以包括电路，所述电路可以实现前述方法实施例中发送或接收或者通信的功能。本申请中描述的处理器和收发器可实现在集成电路(integrated circuit，IC)、模拟IC、射频集成电路RFIC、混合信号IC、专用集成电路(application specific integrated circuit，ASIC)、印刷电路板(printed circuit board，PCB)、电子设备等上。该处理器和收发器也可以用各种IC工艺技术来制造，例如互补金属氧化物半导体(complementary metal oxide semiconductor，CMOS)、N型金属氧化物半导体(nMetal-oxide-semiconductor，NMOS)、P型金属氧化物半导体(positive channel metal oxide semiconductor，PMOS)、双极结型晶体管(bipolar junction transistor，BJT)、双极CMOS(BiCMOS)、硅锗(SiGe)、砷化镓(GaAs)等。
以上实施例描述中的通信装置可以是网络设备或者终端设备，但本申请中描述的通信装置的范围并不限于此，而且通信装置的结构可以不受图16的限制。通信装置可以是独立的设备或者可以是较大设备的一部分。例如所述通信装置可以是：
(1)独立的集成电路IC，或芯片，或，芯片***或子***；
(2)具有一个或多个IC的集合，可选的，该IC集合也可以包括用于存储数据，计算机程序的存储部件；
(3)ASIC，例如调制解调器(Modem)；
(4)可嵌入在其他设备内的模块；
(5)接收机、终端设备、智能终端设备、蜂窝电话、无线设备、手持机、移动单元、车载设备、网络设备、云设备、人工智能设备等等；
(6)其他设备。
对于通信装置可以是芯片或芯片***的情况，可参见图17所示的芯片的结构示意图。图17所示的芯片包括处理器1701和接口1702。其中，处理器1701的数量可以是一个或多个，接口1702的数量可以是多个。
可选的，芯片还包括存储器1703，存储器1703用于存储必要的计算机程序和数据。
本领域技术人员还可以了解到本申请实施例列出的各种说明性逻辑块(illustrative logical block)和步骤(step)可以通过电子硬件、电脑软件，或两者的结合进行实现。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个***的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本申请实施例保护的范围。
本申请还提供一种可读存储介质，其上存储有指令，该指令被计算机执行时实现上述任一方法实施例的功能。
本申请还提供一种计算机程序产品，该计算机程序产品被计算机执行时实现上述任一方法实施例的功能。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机程序。在计算机上加载和执行所述计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机程序可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机程序可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
本领域普通技术人员可以理解：本申请中涉及的第一、第二等各种数字编号仅为描述方便进行的区分，并不用来限制本申请实施例的范围，也表示先后顺序。
本申请中的至少一个还可以描述为一个或多个，多个可以是两个、三个、四个或者更多个，本申请不做限制。在本申请实施例中，对于一种技术特征，通过“第一”、“第二”、“第三”、“A”、“B”、“C”和“D”等区分该种技术特征中的技术特征，该“第一”、“第二”、“第三”、“A”、“B”、“C”和“D”描述的技术特征间无先后顺序或者大小顺序。
本申请中各表所示的对应关系可以被配置，也可以是预定义的。各表中的信息的取值仅仅是举例，可以配置为其他值，本申请并不限定。在配置信息与各参数的对应关系时，并不一定要求必须配置各表中示意出的所有对应关系。例如，本申请中的表格中，某些行示出的对应关系也可以不配置。又例如，可以基于上述表格做适当的变形调整，例如，拆分，合并等等。上述各表中标题示出参数的名称也可以采用通信装置可理解的其他名称，其参数的取值或表示方式也可以通信装置可理解的其他取值或表示方式。上述各表在实现时，也可以采用其他的数据结构，例如可以采用数组、队列、容器、栈、线性表、指针、链表、树、图、结构体、类、堆、散列表或哈希表等。
本申请中的预定义可以理解为定义、预先定义、存储、预存储、预协商、预配置、固化、或预烧制。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (28)

  1. 一种应用程序接口API的调用方法，其特征在于，由API开放功能实体执行，所述方法包括：
    接收所述API调用实体发送的API调用请求，其中，所述API调用请求中包括API调用信息和用户资源访问令牌；
    根据所述API调用信息和所述用户资源访问令牌进行API调用验证。
  2. 如权利要求1所述的方法，其特征在于，所述API调用请求中还包括API访问令牌。
  3. 如权利要求2所述的方法，其特征在于，所述用户资源访问令牌和所述API访问令牌同属于一个令牌。
  4. 如权利要求1所述的方法，其特征在于，所述API调用信息包括以下一项或多项：
    所述API调用实体的第一身份标识；
    第一资源所有者身份标识；
    需要调用的服务API标识符；
    需要调用的服务标识符；
    需要访问的用户资源标识符。
  5. 如权利要求1所述的方法，其特征在于，所述用户资源访问令牌包括以下一项或多项：
    通用应用编程接口框架CAPIF核心功能身份；
    授权功能身份；
    所述API开放功能实体的身份标识；
    所述API调用实体的第二身份标识；
    第二资源所有者身份标识；
    用户资源标识符；
    过期时间。
  6. 如权利要求5所述的方法，其特征在于，所述用户资源访问令牌还包括：
    服务API标识符；
    服务标识符。
  7. 如权利要求1所述的方法，其特征在于，所述根据所述API调用信息和所述用户资源访问令牌进行API调用验证，包括：
    根据所述用户资源访问令牌对所述API调用请求进行用户资源访问验证；
    通过调用CAPIF核心功能或授权功能对所述API调用请求进行API调用验证；
    当所述用户资源访问验证和所述API调用验证均通过时，判断所述API调用请求通过验证。
  8. 如权利要求6所述的方法，其特征在于，所述根据所述API调用信息和所述用户资源访问令牌进行API调用验证，包括：
    根据所述用户资源访问令牌对所述API调用请求进行用户资源访问验证和API调用验证；
    当所述用户资源访问验证和所述API调用验证均通过时，判断所述API调用请求通过验证。
  9. 如权利要求2所述的方法，其特征在于，所述根据所述API调用信息和所述用户资源访问令牌进行API调用验证，包括：
    根据所述用户资源访问令牌对所述API调用请求进行用户资源访问验证；
    根据所述API访问令牌对所述API调用请求进行API调用验证；
    当所述用户资源访问验证和所述API调用验证均通过时，判断所述API调用请求通过验证。
  10. 如权利要求1所述的方法，其特征在于，所述方法还包括：
    向所述API调用实体发送API调用响应。
  11. 如权利要求1所述的方法，其特征在于，所述方法还包括：
    与所述API调用实体进行相互身份认证。
  12. 如权利要求11所述的方法，其特征在于，通过以下任一认证机制与所述API调用实体进行相互身份认证：
    安全传输层协议-预共享密钥TLS-PSK；
    公钥基础设施PKI；
    OAuth协议证书；
    基于通用认证机制GBA的认证机制；
    基于应用层鉴权和密钥管理AKMA的认证机制；
    基于证书的认证机制。
  13. 如权利要求11所述的方法，其特征在于，所述方法还包括：
    响应于身份认证成功，建立与API开放功能实体之间的安全连接。
  14. 一种API的调用方法，其特征在于，由API调用实体执行，所述方法包括：
    向所述API开放功能实体发送API调用请求，其中，所述API调用请求中包括API调用信息和用户资源访问令牌。
  15. 如权利要求14所述的方法，其特征在于，所述API调用请求中还包括API访问令牌。
  16. 如权利要求15所述的方法，其特征在于，所述用户资源访问令牌和所述API访问令牌同属于一个令牌。
  17. 如权利要求14所述的方法，其特征在于，所述API调用信息包括以下一项或多项：
    所述API调用实体的第一身份标识；
    第一资源所有者身份标识；
    需要调用的服务API标识符；
    需要调用的服务标识符；
    需要访问的用户资源标识符。
  18. 如权利要求14所述的方法，其特征在于，所述用户资源访问令牌包括以下一项或多项：
    CAPIF核心功能身份；
    授权功能身份；
    所述API开放功能实体的身份标识；
    所述API调用实体的第二身份标识；
    第二资源所有者身份标识；
    用户资源标识符；
    过期时间。
  19. 如权利要求18所述的方法，其特征在于，所述用户资源访问令牌还包括：
    服务API标识符；
    服务标识符。
  20. 如权利要求14所述的方法，其特征在于，所述方法还包括：
    接收所述API开放功能实体发送的API调用响应。
  21. 如权利要求14所述的方法，其特征在于，所述方法还包括：
    与所述API开放功能实体进行相互身份认证。
  22. 如权利要求21所述的方法，其特征在于，通过以下任一认证机制与所述API开放功能实体进行相互身份认证：
    TLS-PSK；
    PKI；
    OAuth协议证书；
    基于GBA的认证机制；
    基于AKMA的认证机制；
    基于证书的认证机制。
  23. 如权利要求21所述的方法，其特征在于，所述方法还包括：
    响应于身份认证成功，建立与API开放功能实体之间的安全连接。
  24. 一种通信装置，被配置在API开放功能实体中，包括：
    接收模块，用于接收API调用实体发送的API调用请求，其中，所述API调用请求中包括API调用信息和用户资源访问令牌；
    调用验证模块，用于根据所述API调用信息和所述用户资源访问令牌进行API调用验证。
  25. 一种通信装置，被配置在API调用实体中，包括：
    发送模块，用于向API开放功能实体发送API调用请求，其中，所述API调用请求中包括API调用信息和用户资源访问令牌。
  26. 一种通信装置，其特征在于，所述装置包括处理器和存储器，其中，所述存储器中存储有计算机程序，所述处理器执行所述存储器中存储的计算机程序，以使所述装置执行如权利要求1至13中任一项所述的方法，或所述处理器执行所述存储器中存储的计算机程序，以使所述装置执行如权利要求14至23中任一项所述的方法。
  27. 一种通信装置，其特征在于，包括：处理器和接口电路，其中：
    所述接口电路，用于接收代码指令并传输至所述处理器；
    所述处理器，用于运行所述代码指令以执行如权利要求1至13中任一项所述的方法，或用于运行所述代码指令以执行如权利要求14至23中任一项所述的方法。
  28. 一种计算机可读存储介质，用于存储有指令，当所述指令被执行时，使如权利要求1至13中任一项所述的方法被实现，或当所述指令被执行时，使如权利要求14至23中任一项所述的方法被实现。
PCT/CN2022/122958 2022-09-29 2022-09-29 一种api的调用方法、装置、设备及存储介质 WO2024065564A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2022/122958 WO2024065564A1 (zh) 2022-09-29 2022-09-29 一种api的调用方法、装置、设备及存储介质
CN202280003760.0A CN118120176A (zh) 2022-09-29 2022-09-29 一种api的调用方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/122958 WO2024065564A1 (zh) 2022-09-29 2022-09-29 一种api的调用方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
WO2024065564A1 true WO2024065564A1 (zh) 2024-04-04

Family

ID=90475424

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/122958 WO2024065564A1 (zh) 2022-09-29 2022-09-29 一种api的调用方法、装置、设备及存储介质

Country Status (2)

Country Link
CN (1) CN118120176A (zh)
WO (1) WO2024065564A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102611709A (zh) * 2012-03-31 2012-07-25 奇智软件（北京）有限公司 一种对第三方资源的访问控制方法及***
CN111373712A (zh) * 2017-11-16 2020-07-03 三星电子株式会社 用于认证应用程序接口(api)调用者的方法和***
CN112352409A (zh) * 2018-04-06 2021-02-09 日本电气株式会社 下一代网络中的通用api框架所用的安全过程
CN113312653A (zh) * 2021-06-25 2021-08-27 中国农业银行股份有限公司 开放平台认证授权方法、装置及存储介质
WO2022156887A1 (en) * 2021-01-20 2022-07-28 Lenovo (Singapore) Pte. Ltd. Application programming interface translation

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102611709A (zh) * 2012-03-31 2012-07-25 奇智软件（北京）有限公司 一种对第三方资源的访问控制方法及***
CN111373712A (zh) * 2017-11-16 2020-07-03 三星电子株式会社 用于认证应用程序接口(api)调用者的方法和***
CN112352409A (zh) * 2018-04-06 2021-02-09 日本电气株式会社 下一代网络中的通用api框架所用的安全过程
WO2022156887A1 (en) * 2021-01-20 2022-07-28 Lenovo (Singapore) Pte. Ltd. Application programming interface translation
CN113312653A (zh) * 2021-06-25 2021-08-27 中国农业银行股份有限公司 开放平台认证授权方法、装置及存储介质

Also Published As

Publication number Publication date
CN118120176A (zh) 2024-05-31

Similar Documents

Publication Publication Date Title
WO2024077455A1 (zh) 一种非陆地网络的接入方法及装置
WO2024065564A1 (zh) 一种api的调用方法、装置、设备及存储介质
WO2024026890A1 (zh) 一种定位方法/装置/设备及存储介质
WO2022068541A1 (zh) 一种鉴权方法及其装置
WO2024065339A1 (zh) 一种网络卫星覆盖数据的授权方法、设备及存储介质
WO2024065706A1 (zh) 一种构建连接的方法及装置
WO2024145949A1 (zh) 一种个人物联网pin管理方法/装置/设备及存储介质
WO2024145902A1 (zh) 密钥获取方法、装置、设备及芯片***
WO2024082143A1 (zh) 一种设备业务角色的验证方法/装置/设备及存储介质
WO2024092826A1 (zh) 身份验证方法及装置
WO2024098323A1 (zh) 一种通过托管网络提供本地化服务的方法及其装置
WO2024138581A1 (zh) 一种网络切片的授权方法、装置、设备及存储介质
WO2024098219A1 (zh) 一种密钥分发方法、装置、设备及存储介质
WO2023115487A1 (zh) 一种人工智能会话的创建方法及其装置
WO2024138338A1 (zh) 一种服务调用方法/装置/设备及存储介质
WO2024065335A1 (zh) 一种侧行链路定位方法及装置
WO2024050778A1 (zh) 一种人工智能服务策略的更新方法及装置
WO2024065336A1 (zh) 一种侧行链路定位方法及装置
WO2024130561A1 (zh) 一种用户位置信息的可信确定方法及其装置
WO2024065705A1 (zh) 应用功能授权方法及装置
WO2024065334A1 (zh) 一种用户设备ue的授权令牌的生成方法/装置/设备及存储介质
WO2023184191A1 (zh) 一种扩展现实多媒体xrm业务的处理方法及其装置
WO2024065140A1 (zh) 一种用户设备ue的角色授权方法/装置/设备及存储介质
WO2024065131A1 (zh) 一种多路径传输方法/装置/设备及存储介质
WO2024020751A1 (zh) 一种第三方服务管理方法/装置/设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22960196

Country of ref document: EP

Kind code of ref document: A1