WO2024032226A1 - 通信方法和通信装置 - Google Patents

通信方法和通信装置 Download PDF

Info

Publication number
WO2024032226A1
WO2024032226A1 PCT/CN2023/104165 CN2023104165W WO2024032226A1 WO 2024032226 A1 WO2024032226 A1 WO 2024032226A1 CN 2023104165 W CN2023104165 W CN 2023104165W WO 2024032226 A1 WO2024032226 A1 WO 2024032226A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
authorization
request message
token
caller
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2023/104165
Other languages
English (en)
French (fr)
Inventor
胡力
吴�荣
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to EP23851453.3A priority Critical patent/EP4561136A4/en
Publication of WO2024032226A1 publication Critical patent/WO2024032226A1/zh
Priority to US19/051,003 priority patent/US20250184731A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration

Definitions

  • the present application relates to the field of communication, and more specifically, to a communication method and a communication device.
  • the application function (AF) network element can request the 3GPP network to process some information, which can be data belonging to the network or data belonging to the user.
  • the AF can request 3GPP to send the user's location information externally.
  • users' private information may be illegally exposed.
  • This application provides a communication method and communication device that can avoid user privacy exposure and reduce potential security risks faced by network functions in mobile communication networks.
  • a communication method is provided, which method can be executed by an application programming interface (application programming interface, API) caller, or can also be executed by a chip or circuit for an API caller.
  • API application programming interface
  • This application is Not limited.
  • the following description takes execution by the API caller as an example.
  • the method includes: an application software programming interface API caller (API Invoker) sends an authorization request message to an authorization function network element (for example, (authorization function, AuF)), and the authorization request message includes the identification of a target user; the API caller receives an authorization request from Authorization response message of the functional network element.
  • the authorization response message includes a first token with integrity protection.
  • the first token is used to indicate that the API caller has the authority to access the target user's data.
  • the first token includes the identity of the target user.
  • the API caller sends a first API call request message to the API exposing function (AEF).
  • the first API call request message is used to request to call the target API to operate the target user's data.
  • the first API call request message Include the target user's identity and first token.
  • the API Invoker can actively obtain a more fine-grained user authorization token from AuF and use the token to access AEF, so that the AEF can authorize the API Invoker to access an API and process a certain user's data.
  • the method disclosed in this application introduces the consideration of whether the user is authorized when processing user data, which can prevent the user's private information from being exposed and reduce the potential security risks faced by network functions in the mobile communication network.
  • the API caller before the API caller sends an authorization request message to the authorization function network element, the API caller sends a second API call request message to the AEF, and the second API call request message Used to request to call the target API to operate the target user's data.
  • the second API call request message includes the identification of the target user; the API caller receives the authorization instruction from the AEF; wherein the API caller sends an authorization request message to the authorization function network element, Including: the API caller sends an authorization request message to the authorization function network element according to the authorization instruction.
  • AEF provides authorization instructions to the API Invoker, so that the API caller determines that requesting to call the target API to operate the target user's data requires the user's authorization, and then initiates an authorization request to the authorization function network element based on the received authorization instructions.
  • Introducing target user authorization into the API call process can avoid the exposure of user privacy information and reduce potential security risks in the communication network.
  • the authorization instruction includes the address of the authorization function network element; wherein the API caller receives the authorization instruction from the AEF, including: the API caller receives the second API from the AEF A response message is called, and the second API call response message includes an authorization indication.
  • the API caller can send an authorization request message to the authorized function network element through the address of the authorized function network element carried in the authorization instruction.
  • the API caller sends an authorization request message to the authorization function network element Previously, the API caller sent a second request message to the common API framework core function (CCF). The second request message was used to request to register the API caller to the CCF or to make an API call.
  • the API caller discovers the target API; the API caller receives the authorization instruction from the CCF; among them, the API caller sends an authorization request message to the authorized function network element, including: the API caller sends an authorization request message to the authorized function network element according to the authorization instruction.
  • CCF provides authorization instructions to the API Invoker, so that the API caller determines that the request to call the target API to operate the target user's data requires the user's authorization, and then initiates an authorization request to the authorization function network element based on the received authorization instructions.
  • Introducing target user authorization into the API call process can avoid the exposure of user privacy information and reduce potential security risks in the communication network.
  • the authorization instruction includes the address of the authorization function network element; wherein the API caller receives the authorization instruction from the CCF, including: the API caller receives the second API from the CCF A response message is called, and the second API call response message includes an authorization indication.
  • the second API call response message from CCF is a message in response to the second request message.
  • the API caller can send an authorization request message to the authorized function network element through the address of the authorized function network element carried in the authorization instruction.
  • the second API call response message is a redirect request message.
  • the API caller determines the address of the authorized function network element according to the authorization instruction carried in the redirection request message, and then sends the authorization request message to the authorized function network element.
  • the API caller may not know the specific meaning of the authorization indication information.
  • the authorization indication further includes a reason value, and the reason value is used to indicate that the request to operate the target user's data requires the authorization of the target user.
  • the API caller can determine the need to obtain the authorization of the target user from the authorization function network element through the reason value carried in the authorization instruction and the address of the authorization function network element, and then send an authorization request message to the authorization function network element.
  • the API caller knows the specific meaning of the authorization indication information, allowing the API caller to request the user's authorization in a more targeted manner.
  • the authorization indication includes a reason value, and the reason value is used to indicate that the request to operate the target user's data requires the authorization of the target user; wherein, the API caller, according to the authorization indication, requests authorization from the target user.
  • the functional network element sends an authorization request message, including: the API caller determines the address of the authorized functional network element based on the cause value; the API caller sends an authorization request message to the authorized functional network element based on the address of the authorized functional network element.
  • the API caller can determine that the request to operate the target user's data requires authorization from the target user through the reason value carried in the authorization instruction, and then find the address of the authorized function network element based on the reason value, and send an authorization request to the authorized function network element. information.
  • the API caller determines the address of the authorized function network element based on the cause value, including: the API caller obtains the authorization function from a preconfigured address list based on the cause value. The address of the network element.
  • the API caller can determine that the request to operate the target user's data requires authorization from the target user through the reason value carried in the authorization instruction, and then find the address of the corresponding authorized function network element from the preconfigured address list and submit the request to the authorized function.
  • the functional network element sends an authorization request message.
  • the authorization instruction also includes an authorization type
  • the authorization request message also includes a response type
  • the API caller sends an authorization request message to the authorization function network element according to the authorization instruction.
  • API callers determined the response type based on the authorization type.
  • the API caller determines the response type carried in the authorization request message sent to the authorization function network element through the authorization type carried in the authorization instruction, which can make the user authorization more targeted in the API calling process. To this extent, it can ensure the consistency of information interaction between network elements and reduce potential network risks and interference.
  • the first API call request message also includes a second token.
  • the second token is used to indicate that the API caller has the authority to call the target API.
  • the second token Including the identification of the API caller and the identification of the target API; wherein, before the API caller sends the first API call request message to the AEF, the API caller sends the first request message to the common API framework core function network element CCF.
  • the first request The message is used to request permission to call the target API.
  • the first request message includes the identity of the API caller and the identity of the target API; the API caller receives the second token from CCF.
  • the API caller can carry the first token and the second token when requesting to call the target API to operate the target user's data, that is, the API caller can be authorized to have the permission to call (or access) the target API. , and can be authorized to call the target API to operate the target user's data, ensuring the integrity and security of the API call process.
  • Protecting users' privacy and security provides a double layer of protection to reduce potential communication risks.
  • the first token further includes one or more of the following: a timeout; an identifier of the API caller; an identifier of the target API; and a signer.
  • the authorization request message further includes: an identification of the target API; and/or an identification of the target user.
  • the calling request of the API caller is more targeted, and it is convenient for the first token generated by the subsequent authorization function network element to have More statement content information will help provide more secure protection measures for target users during the API calling process and avoid risks such as user personal data being leaked.
  • a communication method which can be executed by the API open function network element AEF, or can also be executed by a chip or circuit used for the API open function network element.
  • This application does not limit this.
  • the following description takes the execution of the API open function network element as an example.
  • the method includes: AEF receives a first API call request message from an API caller, the first API call request message is used to request to call a target API to operate the target user's data, and the first API call request message includes a first API call request message with integrity protection.
  • the first token is used to indicate that the API caller has the authority to access the target user's data.
  • the first token includes the identification of the target user;
  • AEF determines whether the API caller is based on the first token. Has the permission to operate the target user's data; based on the determination result, AEF determines whether to provide the API caller with permission to access the target user's data.
  • AEF can determine whether the API caller has the authority to operate the target user's data by verifying the more fine-grained first token used for user authorization; and further, AEF can determine whether to provide the API caller with access to the target user's data based on the determination results. Multi-layer verification of API call requests based on AEF can prevent users' private information from being exposed and reduce potential security risks faced by network functions in mobile communication networks.
  • AEF determines whether the API caller has the authority to operate the target user's data based on the first token, including: AEF determines whether the API caller has the authority to operate the target user's data based on the credentials of the authorized functional network element. The integrity protection of the first token is verified, and the authorization function network element is the network element that generated the first token; when the integrity protection verification of the first token passes, the AEF determines the target user carried in the first token Is the identification the same as the identification of the target user carried in the first API call request message?
  • AEF can first verify the integrity protection of the first token through the credentials of the authorized functional network element. Further, the AEF determines whether the identity of the target user carried in the first token is the same as the identity of the target user carried in the first API call request message. Double verification is used to ensure the authenticity and accuracy of the first token, thereby providing security protection for the target user's data in subsequent operations requested by the API caller, avoiding leaks to the user's privacy and increasing potential risks.
  • the first token also includes a signer; before the AEF performs integrity verification on the first token based on the credentials of the authorized functional network element, the method also Including: AEF obtains the certificate of the authorized functional network element based on the signer.
  • the authenticity and reliability of the user's authorization can be determined, which facilitates subsequent AEF verification of the first token to determine whether the information that the user agrees to authorize to operate the target user's personal data is true and valid. , to avoid being maliciously tampered with by other network elements in the process, causing damage to target users and causing potential risks.
  • the first token also includes the identity of the API caller
  • the first API call request message also includes the identity of the API caller
  • AEF determines based on the first token. Whether the API caller has the authority to operate the target user's data also includes: AEF determines whether the API caller's identity carried in the first token is the same as the API caller's identity carried in the first API call request message.
  • the first token and the first API call request message respectively carry the identity of the API caller.
  • AEF can confirm whether the first token is valid and prevent The first token is maliciously tampered with midway, reducing the risk of the target user's personal information being leaked.
  • the first token also includes the identifier of the target API
  • the first API call request message also includes the identifier of the target API
  • AEF determines the API call based on the first token.
  • Whether the user has the authority to operate the target user's data also includes: AEF determines whether the identity of the target API carried in the first token is the same as the identity of the target API carried in the first API call request message.
  • the first token and the first API call request message respectively carry the identification of the target API.
  • AEF can confirm whether the first token is valid and prevent the first The token is maliciously tampered with in the process, reducing the risk of the target user's personal information being leaked.
  • verifying the identity of the target API it can be further determined whether the authorized API caller has the permission to call the target API.
  • the first API call request message also includes a second token; wherein, before determining whether the API caller has the authority to operate the target user's data, AEF determines whether the API caller has the authority to operate the target user's data. The second token confirms that the API caller has the permission to call the target API.
  • the second token also includes the identification of the target API
  • the first API call request message also includes the identification of the target API
  • AEF determines based on the second token
  • the API caller has the authority to call the target API, including: AEF determines that the identity of the target API carried in the second token is the same as the identity of the target API carried in the first API call request message.
  • AEF can confirm whether the API caller can be authorized to call the target API by determining whether the identifiers of the two A target APIs carried in the second token and the first API call request message are the same. Adding verification of the second token based on this implementation method can reduce the risk of the target user's personal information being leaked, provide double insurance for the API calling process, and provide higher security.
  • AEF before AEF receives the first API call request message from the API caller, AEF receives the second API call request message from the API caller, and the second API call
  • the request message is used to request to call the target API to operate the target user's data.
  • the second API call request message includes the identification of the target user; AEF sends an authorization instruction to the API caller.
  • the authorization instruction is used to indicate that the request to operate the target user's data requires the target user. authorization.
  • AEF provides authorization instructions to the API Invoker, so that the API caller determines that requesting to call the target API to operate the target user's data requires the user's authorization, and then initiates an authorization request to the authorization function network element based on the received authorization instructions.
  • Introducing target user authorization into the API call process can avoid the exposure of user privacy information and reduce potential security risks in the communication network.
  • the authorization instruction includes the address of the authorization function network element; wherein, AEF sends the authorization instruction to the API caller, including: AEF sends a second API call response to the API caller. message, the second API call response message includes an authorization indication.
  • the API caller can send an authorization request message to the authorized function network element through the address of the authorized function network element carried in the authorization instruction.
  • the second API call response message is a redirect request message.
  • the API caller determines the address of the authorized function network element according to the authorization instruction carried in the redirection request message, and then sends the authorization request message to the authorized function network element.
  • the API caller may not know the specific meaning of the authorization indication information.
  • the authorization indication includes a reason value, and the reason value is used to indicate that the request to operate the target user's data requires the authorization of the target user.
  • the API caller can determine the need to obtain the authorization of the target user from the authorization function network element through the reason value carried in the authorization instruction and the address of the authorization function network element, and then send an authorization request message to the authorization function network element.
  • the API caller knows the specific meaning of the authorization indication information, allowing the API caller to request the user's authorization in a more targeted manner.
  • AEF determines that the request to operate the target user's data requires authorization from the target user.
  • AEF determines that the request to operate the target user's data requires the authorization of the target user, it sends an authorization instruction to the API caller to indicate that the request to operate the target user's data requires the authorization of the target user.
  • AEF determines that the request to operate the target user's data requires the authorization of the target user, including: AEF sends an acquisition request message to the unified data management function network element UDM, and the acquisition request message uses Based on the request to obtain the user consent information of the target user; AEF receives the response message from UDM; based on the response message, AEF determines that the request to operate the target user's data requires the authorization of the target user.
  • AEF's UDM-based response message can determine that the request to operate the target user's data requires authorization from the target user, and then sends an authorization instruction to the API caller to authorize the user to the authorization function network element.
  • AEF determines that AEF does not save the user consent information of the target user, and the user consent information indicates that the target user agrees to operate the target user's data.
  • AEF ensures that the user consent information of the target user is not stored locally before requesting the UDM to obtain the user consent information of the target user. This can avoid unnecessary signaling overhead and reduce the number of interactions.
  • the AEF sends a third request message to the common API framework core function network element CCF.
  • the third request message is used to request to obtain the access policy for the API caller to call the target API.
  • the third request message includes the identity of the API caller and the identity of the target API; wherein, based on the determination result, AEF determines whether to provide the API caller with permission to access the target user's data, including: when the API caller has the ability to operate the target user's data permission, and the access policy indicates that the API caller is allowed to call the target API, AEF provides the API caller with permission to access the target user's data.
  • the above-mentioned AEF sends a third request message to CCF, requesting to obtain the access policy for the API caller to call the target API, and the above-mentioned API caller sends a first request message to CCF, requesting to obtain the second token for accessing the target API.
  • these two implementation methods are parallel solutions.
  • this application does not rule out that the API caller requests the CCF to obtain the second token and then sends the first API call request message to the AEF.
  • AEF determines whether the API has the authority to access the target API, it requests the CCF to obtain the API again.
  • the caller calls the access policy of the target API. Through double verification of the access policy and the second token, the API calling process can be ensured to be more secure.
  • AEF can request from CCF to obtain the access policy for accessing the target API, and then determine whether the API caller is allowed to call the target API. At the same time, based on the fact that the API caller has the permission to operate the target user's data, AEF can determine whether to provide the API caller with permission to access the target user's data.
  • AEF when the API caller has the authority to operate the target user's data, AEF sends a contract information update message to the unified data management function UDM, and the contract information update message is For updating the user consent information of the target user, the user consent information is used to indicate that the target user agrees to operate the target user's data.
  • AEF can update the contract information on UDM to reduce the number of times AuF requests RO authorization, while ensuring the security of the target user's personal data. to reduce signaling overhead.
  • a communication method which can be executed by an authorization function network element (authorization function, AuF), or can also be executed by a chip or circuit used for AuF, which is not limited in this application.
  • authorization function authentication function
  • AuF authorization function network element
  • the following takes execution by AuF as an example.
  • the method includes: an authorization function network element receives an authorization request message from an application software programming interface API caller, and the authorization request message includes an identification of a target user; when it is determined that the target user agrees to the API caller's operation of the target user's data, the authorization function The network element generates a first token with integrity protection.
  • the first token is used to indicate that the API caller has the authority to access the target user's data.
  • the first token includes the identification of the target user; the authorization function network element provides the API caller with An authorization response message is sent, and the authorization response message includes the first token.
  • the authorization function network element provides a more fine-grained user authorization token to the API Invoker after confirming that the target user agrees to the API caller's operation of the target user's data, so as to facilitate subsequent use of the token to access the AEF.
  • This allows AEF to authorize the API Invoker to access an API and process a user's data.
  • the method disclosed in this application introduces the consideration of whether the user is authorized when processing user data, which can prevent the user's private information from being exposed and reduce the potential security risks faced by network functions in the mobile communication network.
  • the authorization request message also includes the identification of the target API and the identification of the target user
  • the authorization function network element generates a first token with integrity protection, including: authorization function The network element generates a statement based on the API caller's identity, the target API's identity, and the target user's identity; the authorization function network element generates a signature based on the statement; the authorization function network element generates a first token with integrity protection based on the statement and signature.
  • the authorization function network element Based on the above solution, the authorization function network element generates the first token based on the identity of the API caller, the identity of the target API and the identity of the target user carried in the authorization request message, and when the user agrees to authorize the operation of the target user's data. , ensuring the first token The integrity, authenticity and pertinence of the data can reduce the risk of exposure of the user's private information caused by subsequent operations on the user's personal data.
  • the first token further includes one or more of the following: a timeout; an identifier of the API caller; an identifier of the target API; and a signer.
  • the authorization request message also includes: the identification of the target API; and/or the identification of the target user.
  • the calling request of the API caller is more targeted, and it is convenient for the first token generated by the subsequent authorization function network element to have More statement content information will help provide more secure protection measures for target users during the API calling process and avoid risks such as user personal data being leaked.
  • the fourth aspect provides a communication method, which can be executed by the Common API Framework Core Function (CCF), or can also be executed by the chip or circuit used for the CAPIF core function network element. , this application does not limit this. For the convenience of description, the following description takes the execution of the CAPIF core function network element as an example.
  • CCF Common API Framework Core Function
  • the method includes: a common application software programming interface API framework core function network element CCF receives a second request message from an API caller, and the second request message is used to request to register the API caller to the CCF, or for the API caller to The target API is discovered; CCF sends authorization instructions to the API caller.
  • CCF receives a second request message from an API caller, and the second request message is used to request to register the API caller to the CCF, or for the API caller to The target API is discovered; CCF sends authorization instructions to the API caller.
  • CCF provides authorization instructions to the API Invoker, so that the API caller determines that the request to call the target API to operate the target user's data requires the user's authorization, and then initiates an authorization request to the authorization function network element based on the received authorization instructions. . Introducing target user authorization into the API call process can avoid the exposure of user privacy information and reduce potential security risks in the communication network.
  • the authorization instruction includes the address of the authorization function network element; wherein, the CCF sends the authorization instruction to the API caller, including: CCF sends a second response message to the API caller, The second response message includes authorization indication.
  • the API caller can send an authorization request message to the authorized function network element through the address of the authorized function network element carried in the authorization instruction.
  • the second response message is a redirection request message.
  • the API caller determines the address of the authorized function network element according to the authorization instruction carried in the redirection request message, and then sends the authorization request message to the authorized function network element.
  • the API caller may not know the specific meaning of the authorization indication information.
  • the authorization indication further includes a reason value, and the reason value is used to indicate that the request to operate the target user's data requires the authorization of the target user.
  • the API caller can determine the need to obtain the authorization of the target user from the authorization function network element through the reason value carried in the authorization instruction and the address of the authorization function network element, and then send an authorization request message to the authorization function network element.
  • the API caller knows the specific meaning of the authorization indication information, allowing the API caller to request the user's authorization in a more targeted manner.
  • the CCF receives an authorization request message from the API caller.
  • the authorization request message includes the API caller's identity, the target API's identity, and the target user's identity; the CCF authorizes the The functional network element sends an authorization request message; the CCF receives an authorization response message from the authorized functional network element.
  • the authorization response message includes a first token with integrity protection. The first token is used to indicate that the API caller has access to the target user's data. The first token includes the identity of the target user; CCF sends an authorization response message to the API caller.
  • CCF serves as an intermediate node to forward messages between AuF and API Invoker, which can achieve more fine-grained authorization on the basis of reducing the interactive signaling between API Invoker and AuF, that is, authorizing API Invoker to access an API and process certain user data.
  • the CCF before the CCF sends the authorization request message to the authorized function network element, the CCF determines the address of the authorized function network element according to the preconfigured address list; the CCF determines the address of the authorized function network element according to the authorized function network element. The address of the network element is used to send an authorization request message to the authorization function network element.
  • CCF determines that the request to operate the target user's data requires authorization from the target user, it can find the address of the authorized function network element corresponding to the target API and send an authorization request message to the authorized function network element.
  • the CCF receives the first request message from the API caller, and the first The request message is used to request permission to call the target API.
  • the first request message includes the identity of the API caller and the identity of the target API;
  • CCF sends a second token to the API caller, and the second token is used to indicate that the API caller has Permission to call the target API.
  • the second token includes the identity of the API caller and the identity of the target API.
  • CCF issues a second token to the API caller to indicate that the API caller has the authority to call the target API. Further, it is convenient for subsequent API callers to carry the first token and the second token when requesting to call the target API to operate the target user's data, that is, the API caller can be authorized to have the authority to call (or access) the target API. , and can be authorized to call the target API to operate the target user's data, which provides a two-layer guarantee for protecting the user's privacy and security and reducing potential communication risks.
  • the CCF receives a third request message from the AEF.
  • the third request message is used to request to obtain the access policy for the API caller to call the target API.
  • the access policy is used to indicate whether The API caller is allowed to call the target API.
  • the third request message includes the identity of the API caller and the identity of the target API; CCF sends the access policy to AEF.
  • CCF can send the access policy for accessing the target API to AEF, indicating whether the API caller is allowed to call the target API.
  • a communication method is provided.
  • the method can be executed by the authorized function network element, or can also be executed by the chip or circuit used for the authorized function network element. This application does not limit this. For the convenience of description, the following description takes the execution by the authorized function network element as an example.
  • the method includes: the authorization function network element receives an authorization request message from the application software programming interface API open function network element AEF, and the authorization request message includes the API caller's identity and the target user's identity; after determining that the target user authorizes the API caller to operate the target user In the case of data, the authorization function network element sends an authorization response message to the AEF.
  • the authorization response message includes the authorization result.
  • the authorization result is used to indicate whether the target user authorizes the API caller to operate the target user's data.
  • the authorization function network element sends the authorization result to the AEF, which is used by the AEF to determine whether the API caller has the authority to operate the target user's data, avoiding the exposure of the user's private information and reducing potential security risks faced by network functions in the mobile communication network.
  • a communication method is provided, which method can be executed by an API exposing function (API exposing function, AEF), or can also be executed by a chip or circuit for an API exposing function network element.
  • API exposing function API exposing function
  • AEF API exposing function
  • This application applies This is not a limitation.
  • the following description takes the execution of the API open function network element as an example.
  • the method includes: the application software programming interface API open function network element AEF sends an authorization request message to the authorized function network element, where the authorization request message includes the identity of the API caller and the identity of the target user; the AEF receives the authorization response message from the authorized function network element. , the authorization response message includes the authorization result, and the authorization result is used to indicate whether the target user authorizes the API caller to operate the target user's data.
  • AEF can determine whether the API caller has the authority to operate the target user's data, avoid the exposure of the user's private information, and reduce potential security risks faced by network functions in mobile communication networks.
  • AEF determines that the request to operate the target user's data requires authorization from the target user.
  • AEF may determine that calling the target API requires authorization from the target user based on the locally configured API list.
  • the API list may be pre-configured by AEF, or may be configured by other network elements for AEF, which is not specifically limited in this application.
  • the API list can also correspond to the address of the authorized function network element, that is, the AEF obtains the address of the authorized function network element based on the target API.
  • AEF determines that the request to operate the target user's data requires the authorization of the target user, it sends an authorization instruction to the API caller to indicate that the request to operate the target user's data requires the authorization of the target user.
  • AEF determines that the request to operate the target user's data requires the authorization of the target user, including: AEF sends an acquisition request message to the unified data management function network element UDM, and the acquisition request message uses Based on the request to obtain the user consent information of the target user; AEF receives the response message from UDM; based on the response message, AEF determines that the request to operate the target user's data requires the authorization of the target user.
  • the response message may be used to indicate that the UDM does not store the user consent information of the target user, or may be used to indicate that the request to operate the target user's data requires the authorization of the target user, etc.
  • AEF's UDM-based response message can determine that the request to operate the target user's data requires authorization from the target user, and then sends an authorization instruction to the API caller to authorize the user to the authorization function network element.
  • AEF determines that AEF does not save the user consent information of the target user, and the user consent information indicates that the target user agrees to operate the target user's data.
  • AEF does not save the user consent information of the target user. It can be understood that AEF does not store the target user's UE context locally, or it can also be understood that the target user's user consent information is not saved in the locally stored UE context of the target user. .
  • AEF ensures that the user consent information of the target user is not stored locally before requesting the UDM to obtain the user consent information of the target user. This can avoid unnecessary signaling overhead and reduce the number of interactions.
  • the AEF sends an authorization request message to the authorized function network element, including: the AEF determines the address of the authorized function network element according to the preconfigured address list; the AEF determines the address of the authorized function network element according to the authorized function network element. The address of the network element is used to send an authorization request message to the authorization function network element.
  • AEF can find the address of the authorized function network element corresponding to the target API according to the address list, and sends an authorization request message to the authorized function network element.
  • AEF when the API caller has the authority to operate the target user's data, AEF sends a contract information update message to the unified data management function UDM, and the contract information update message is For updating the user consent information of the target user, the user consent information is used to indicate that the target user agrees to operate the target user's data.
  • the subscription information update message includes one or more of the following: the identification of the target user; the purpose of data processing, which is obtained according to the API; the identification of the API caller; the timeout; and the user consent result.
  • AEF can update the contract information on UDM to reduce the number of times AuF requests RO authorization. After authorizing the API Invoker to access an API and process a user In the case of data, signaling overhead can be reduced while ensuring the security of user data.
  • the seventh aspect provides an API caller.
  • the network element includes: a processing network element, used to generate an authorization request message; a transceiver unit, used to send an authorization request message to the authorization function network element, where the authorization request message includes the identity of the API caller; a transceiver unit, also used to receive authorization from Authorization response message of the functional network element.
  • the authorization response message includes a first token with integrity protection.
  • the first token is used to indicate that the API caller has the authority to access the target user's data.
  • the first token includes the identity of the target user.
  • the transceiver unit is also used to send a first API call request message to the API open function network element AEF.
  • the first API call request message is used to request to call the target API to operate the target user's data.
  • the first API call request message includes the target user.
  • the transceiver unit can perform the processing of receiving and sending in the aforementioned first aspect, and the processing unit can perform other processing in addition to receiving and transmitting in the aforementioned first aspect.
  • an API open function network element AEF includes: a transceiver unit, used to receive a first API call request message from an API caller, the first API call request message is used to request to call the target API to operate the target user's data, the first API call request message includes The first token of integrity protection and the identification of the target user, the first token is used to indicate that the API caller has the authority to access the target user's data, the first token includes the identification of the target user; the processing unit is used to perform the processing according to the first token A token to determine whether the API caller has the authority to operate the target user's data; the processing unit is also used to determine whether the AEF provides the API caller with the authority to access the target user's data based on the determination result.
  • the transceiver unit may perform the processing of receiving and transmitting in the foregoing second or sixth aspect, and the processing unit may perform other processing except receiving and transmitting in the foregoing second or sixth aspect.
  • an authorization function network element includes: a transceiver unit, used to receive an authorization request message from an application software programming interface API caller.
  • the authorization request message includes the API caller's identity; a processing unit, used to determine that the target user agrees to the API caller's operation of the target user.
  • the authorization function network element generates a first token with integrity protection.
  • the first token is used to indicate that the API caller has the authority to access the target user's data.
  • the first token includes the identification of the target user;
  • the transceiver unit is also used to send an authorization response message to the API caller, where the authorization response message includes the first token.
  • the transceiver unit may perform the processing of receiving and transmitting in the foregoing third or fifth aspect, and the processing unit may perform other processing except receiving and transmitting in the foregoing third or fifth aspect.
  • a CAPIF core functional network element includes: a transceiver unit, used to receive messages from API callers The second request message is used to request to register the API caller to the CCF, or for the API caller to discover the target API; the transceiver unit is also used to send an authorization instruction to the API caller.
  • the transceiver unit may perform the processing of receiving and transmitting in the foregoing fourth aspect, and the processing unit may perform other processing in addition to receiving and transmitting in the foregoing fourth aspect.
  • a communication device including a transceiver, a processor and a memory.
  • the processor is used to control the transceiver to send and receive signals.
  • the memory is used to store a computer program.
  • the processor is used to call and run the computer program from the memory.
  • a computer program enables the communication device to execute the method in the above-mentioned first to sixth aspects and any possible implementation manner thereof.
  • processors there are one or more processors and one or more memories.
  • the memory may be integrated with the processor, or the memory may be provided separately from the processor.
  • the communication device further includes a transmitter (transmitter) and a receiver (receiver).
  • a communication system including API callers, authorized function network elements, API open function network elements and CAPIF core function network elements.
  • a computer-readable storage medium stores a computer program or code.
  • the computer program or code When the computer program or code is run on a computer, it causes the computer to execute the above-mentioned first aspect. to the method in the sixth aspect and any possible implementation thereof.
  • a chip including at least one processor, the at least one processor is coupled to a memory, the memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that
  • the communication device installed with the chip system performs the method in the above-mentioned first to sixth aspects and any possible implementation manner thereof.
  • the chip may include an input circuit or interface for sending information or data, and an output circuit or interface for receiving information or data.
  • a computer program product includes: computer program code.
  • the communication device causes the communication device to execute the above-mentioned first to sixth aspects. and any of its possible implementation methods.
  • Figure 1 is a schematic diagram of an example of a network architecture applicable to this application.
  • Figure 2 is a schematic diagram of another example of a network architecture applicable to this application.
  • Figure 3 is a flow example diagram of the communication method 300 provided by the embodiment of the present application.
  • Figure 4 is a flow example diagram of the communication method 400 provided by the embodiment of the present application.
  • Figure 5 is a flow example diagram of the communication method 500 provided by the embodiment of the present application.
  • Figure 6 is a flow example diagram of the communication method 600 provided by the embodiment of the present application.
  • Figure 7 is a flow example diagram of the communication method 700 provided by the embodiment of the present application.
  • Figure 8 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • Figure 9 is a schematic structural diagram of another communication device provided by an embodiment of the present application.
  • the technical solution provided by this application can be applied to various communication systems, such as: new radio (NR) system, long term evolution (LTE) system, LTE frequency division duplex (FDD) system , LTE time division duplex (TDD) system, etc.
  • NR new radio
  • LTE long term evolution
  • FDD frequency division duplex
  • TDD time division duplex
  • D2D device-to-device
  • V2X vehicle-to-everything
  • M2M machine-to-machine
  • MTC machine type Communication
  • Internet of Things Internet of things, IoT
  • the part operated by the operator can be called the public land mobile network (PLMN), or the operator network, etc.
  • PLMN is a network established and operated by the government or its approved operators for the purpose of providing land mobile communication services to the public. It is mainly a public network where mobile network operators (MNOs) provide mobile broadband access services to users. .
  • MNOs mobile network operators
  • the PLMN described in the embodiments of this application may specifically be a network that meets the requirements of 3GPP standards, referred to as 3GPP. network.
  • 3GPP networks generally include but are not limited to fifth-generation mobile communications (5th-generation, 5G) networks, fourth-generation mobile communications (4th-generation, 4G) networks, and other future communication systems, such as (6th-generation, 6G) Network etc.
  • the embodiments of this application will take the PLMN or 5G network as an example for description.
  • FIG. 1 is a schematic diagram of an example of a network architecture applicable to this application, taking the 5G network architecture based on the service-based architecture SBA in the non-roaming scenario defined in the 3GPP standardization process as an example.
  • the network architecture can include three parts, namely the terminal equipment part, the data network (DN) and the operator network PLMN part. The following is a brief description of the functions of each part of the network element.
  • the terminal device part may include a terminal device 110, which may also be called user equipment (UE).
  • the terminal device 110 in this application is a device with wireless transceiver function, which can communicate with one or Multiple core network (CN) devices communicate.
  • Terminal equipment 110 may also be referred to as an access terminal, terminal, subscriber unit, subscriber station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, user agent or user device, etc.
  • the terminal device 110 can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it can also be deployed on water (such as ships, etc.); it can also be deployed in the air (such as aircraft, balloons, satellites, etc.).
  • the terminal device 110 may be a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a smart phone, a mobile phone, a wireless local loop (WLL) ) website, personal digital assistant (PDA), etc.
  • the terminal device 110 may also be a handheld device with wireless communication function, a computing device or other device connected to a wireless modem, a vehicle-mounted device, a wearable device, a drone device or a terminal in the Internet of Things, the Internet of Vehicles, or a 5G network As well as any form of terminals in the future network, relay user equipment or terminals in the future evolved 6G network, etc.
  • the relay user equipment may be, for example, a 5G residential gateway (RG).
  • the terminal device 110 may be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control (industrial control), a wireless terminal in self-driving (self-driving), a remote Wireless terminals in remote medical, wireless terminals in smart grid, wireless terminals in transportation safety, wireless terminals in smart city, and smart home wireless terminals, etc.
  • the terminal equipment here refers to the 3GPP terminal.
  • the embodiments of the present application do not limit the type or type of terminal equipment. For ease of explanation, this application will take UE to refer to terminal equipment as an example for subsequent explanation.
  • the PLMN part of the operator's network may include, but is not limited to, the (radio) access network ((R)AN) 120 and the core network (core network, CN) part.
  • the (R)AN 120 can be regarded as a sub-network of the operator's network and is an implementation system between the service nodes and terminal equipment 110 in the operator's network.
  • the terminal device 110 To access the operator's network, the terminal device 110 first passes through the (R)AN 120, and then can be connected to the service node of the operator's network through the (R)AN 120.
  • the access network device (RAN device) in the embodiment of this application is a device that provides wireless communication functions for the terminal device 110. It can also be called a network device.
  • the RAN device includes but is not limited to: the next generation base station in the 5G system.
  • Node node (next generation node base station, gNB), evolved node B (eNB) in long term evolution (LTE), wireless network controller (radio network controller, RNC), node B (node B, NB), base station controller (BSC), base transceiver station (BTS), home base station (for example, home evolved nodeB, or home node B, HNB), base band unit , BBU), transmission point (transmitting and receiving point, TRP), transmission point (transmitting point, TP), small base station equipment (pico), mobile switching center, or network equipment in future networks, etc.
  • the names of devices with access network device functions may be different.
  • access network equipment For convenience of description, in all embodiments of this application, the above-mentioned devices that provide wireless communication functions for the terminal equipment 110 are collectively called access network equipment or simply RAN or AN. It should be understood that this article does not limit the specific type of access network equipment.
  • the CN part may include but is not limited to the following network functions (Network Function, NF): user plane function (UPF) 130, network exposure function (NEF) 131, network function repository function (network function repository) function, NRF) 132. Policy control function (PCF) 133. Unified data management function (UDM) 134. Unified data repository function (UDR) 135. Network data analysis function ( network data analytics function (NWDAF) 136. Authentication Server Function (AUSF) 137. Access and mobility management function (AMF) 138. Session management function (SMF) 139 .
  • Network Function, NF user plane function
  • NEF network exposure function
  • NRF network function repository function
  • PCF Policy control function
  • UDM Unified data management function
  • UDR Unified data repository function
  • NWDAF network data analytics function
  • AUSF Authentication Server Function
  • AMF Access and mobility management function
  • Session management function (SMF) 139 Session management function (SMF) 139 .
  • Data network DN 140 also known as packet data network (PDN)
  • PDN packet data network
  • DN can also be deployed by operators, that is, DN is part of the PLMN.
  • This application does not impose restrictions on whether a DN belongs to a PLMN.
  • the operator network PLMN can access multiple data network DNs 140, and a variety of services can be deployed on the data network DN 140 to provide data and/or voice services to the terminal device 110.
  • the data network DN 140 can be a private network of a smart factory.
  • the sensors installed in the workshop of the smart factory can be the terminal devices 110.
  • the data network DN 140 is deployed with a control server of the sensor, and the control server can provide services for the sensor.
  • the sensor can communicate with the control server, obtain instructions from the control server, and transmit the collected sensor data to the control server according to the instructions.
  • the data network DN 140 may be an internal office network of a certain company, and the mobile phones or computers of the company's employees may be the terminal devices 110. The employees' mobile phones or computers may access information, data resources, etc. on the company's internal office network.
  • the terminal device 110 can establish a connection with the operator network through an interface (such as N1, etc.) provided by the operator network, and use data and/or voice services provided by the operator network.
  • the terminal device 110 can also access the data network DN 140 through the operator network, and use operator services deployed on the data network DN 140, and/or services provided by third parties.
  • UPF 130 is a gateway provided by the operator. It is the gateway for communication between the operator's network and the data network DN 140.
  • UPF network functions 130 include user plane related functions such as data packet routing and transmission, data packet detection, business usage reporting, quality of service (QoS) processing, legal interception, uplink data packet detection, downlink data packet storage, etc.
  • QoS quality of service
  • NEF 131 is a control plane function provided by the operator. It mainly enables third parties to use the services provided by the network, supports the network to open its capabilities, events and data analysis, provides PLMN security configuration information from external applications, and exchanges information inside and outside the PLMN. Conversion, providing the operator network with an API interface open to the outside world, providing interaction between the external server and the internal operator network, etc.
  • NRF 132 is a control plane function provided by operators, which can be used to maintain real-time information on network functions and services in the network. For example, services supported by network service discovery, maintenance of NF configuration data (NF profile) of NF instances, service discovery of service communication proxy (SCP), maintenance of SCP configuration data (SCP profile) of SCP instances, sending related new Registration, de-registration, notification of updated NF and SCP, maintaining the health status of NF and SCP operations, etc.
  • NF profile NF configuration data
  • SCP service communication proxy
  • SCP profile service configuration data
  • sending related new Registration, de-registration, notification of updated NF and SCP maintaining the health status of NF and SCP operations, etc.
  • PCF 133 is a control plane function provided by operators. It supports a unified policy framework to govern network behavior, and provides policy rules and contract information related to policy decisions to other control functions.
  • UDM 134 is a control plane function provided by the operator. It is responsible for storing the user permanent identifier (subscriber permanent identifier, SUPI) and the publicly used subscription identifier (generic public subscription identifier, GPSI) of the subscribed user in the operator's network. ), credential and other information. SUPI is first encrypted during transmission, and the encrypted SUPI is called a hidden user subscription identifier (SUCI). The information stored by the UDM network function 134 can be used for authentication and authorization of the terminal device 110 to access the operator's network.
  • SUPI subscriber permanent identifier
  • GPSI Global System for Mobile communications
  • SUCI hidden user subscription identifier
  • the contract users of the above-mentioned operator network can specifically be users who use the services provided by the operator network, such as users who use China Telecom’s mobile phone chip card (subscriber identity module, SIM) card, or users who use China Mobile’s mobile phone chip card. Users etc.
  • the trust certificate of the above-mentioned contract user can be a long-term key stored in the mobile phone chip card or a small file stored with information related to the encryption of the mobile phone chip card, used for authentication and/or authorization. It should be noted that in the embodiments of this application, permanent identifiers, credentials, security contexts, authentication data (cookies), and information related to token verification/authentication and authorization are not distinguished or limited for the convenience of description. .
  • UDR 135 is a control plane function provided by the operator. It provides UDM with the function of storing and obtaining contract data, provides PCF with the function of storing and obtaining policy data, and stores and obtains the user's NF group ID (group ID) information.
  • NWDAF 136 is a control plane function provided by the operator. Its main function is to collect data from NF, external application function AF, and operation and maintenance management (operations, administration and maintenance, OAM) systems, etc., and provide NWDAF to NF and AF. Business registration, data openness and data analysis, etc.
  • AUSF 137 is a control plane function provided by the operator. It is usually used for first-level authentication, that is, the authentication between the terminal device 110 (subscriber) and the operator's network. After receiving the authentication request initiated by the contracted user, the AUSF network function 137 can authenticate and/or authorize the contracted user through the authentication information and/or authorization information stored in the UDM network function 134, or generate the contracted user's profile through the UDM network function 134. Authentication and/or authorization information. The AUSF network function 137 may feedback authentication information and/or authorization information to the subscriber.
  • AMF 138 is a control plane network function provided by the operator network. It is responsible for the access control and mobility management of the terminal device 110 accessing the operator network, such as mobility status management, assigning user temporary identities, authenticating and authorizing users. and other functions.
  • SMF 139 is a control plane network function provided by the operator network and is responsible for managing the protocol data unit of the terminal device 110 (protocol data unit, PDU) session.
  • the PDU session is a channel used to transmit PDUs.
  • the terminal equipment needs to transmit PDUs to each other through the PDU session and the data network DN 140.
  • the PDU session is established, maintained and deleted by the SMF network function 139.
  • SMF network functions 139 include session management (e.g. session establishment, modification and release, including tunnel maintenance between user plane functions UPF 130 and (R)AN 120), selection and control of UPF network functions 130, service and session continuity ( Service and session continuity (SSC) mode selection, roaming and other session-related functions.
  • session management e.g. session establishment, modification and release, including tunnel maintenance between user plane functions UPF 130 and (R)AN 120
  • selection and control of UPF network functions 130 e.g. session establishment, modification and release, including tunnel maintenance between user plane functions UPF 130 and (R)AN 120),
  • AF 141 is a control plane network function provided by the operator network. It is used to provide application layer information. It can interact with the policy framework through network open function network elements or directly interact with the policy framework to make policy decision requests, etc. Can be within the carrier's network, or outside the carrier's network.
  • NF can be implemented by hardware or software.
  • Nnef, Nnrf, Npcf, Nudm, Nudr, Nnwdaf, Nausf, Namf, Nsmf, N1, N2, N3, N4, and N6 are interface serial numbers.
  • the meaning of the above interface serial number may refer to the meaning defined in the 3GPP standard protocol. This application does not limit the meaning of the above interface serial number.
  • the interface names between various network functions in the figure are just an example. In specific implementations, the interface names of the system architecture may also be other names, and this application does not limit this.
  • the names of the messages (or signaling) transmitted between the various network elements are only examples and do not constitute any limitation on the function of the messages themselves.
  • network functions (such as NEF 131...SMF139) are collectively referred to as NF. That is, the NF described later in the embodiment of this application can be replaced by any network function.
  • FIG. 1 only schematically describes part of the network functions, and the NF described later is not limited to the network functions shown in (a) of FIG. 1 .
  • the above-mentioned network architecture applied to the embodiments of the present application is only a network architecture described from the perspective of a service-oriented architecture.
  • the network architecture applicable to the embodiments of the present application is not limited to this. Any network architecture that can realize the functions of each of the above network elements All network architectures are applicable to the embodiments of this application.
  • AMF, SMF, UPF, NEF, AUSF, NRF, PCF, and UDM shown in the figure can be understood as network elements used to implement different functions in the core network, and can, for example, be combined into network slices as needed.
  • These core network elements can be independent devices, or can be integrated into the same device to implement different functions. This application does not limit the specific forms of the above network elements.
  • FIG. 1 is a schematic diagram of another example of a network architecture applicable to the present application, such as the CAPIF architecture.
  • the network architecture includes API callers, CCF, AEF, AuF, resource owner client (resource owner client), resource owner (RO), etc.
  • the functions of each network element are described below. Simple explanation.
  • API Invoker Usually provided by a third-party application provider that signs a service agreement with the PLMN operator.
  • API Invoker can be AF or UE. Mainly used to provide API caller identity and other information required for API caller authentication, support authentication; support mutual authentication with CAPIF; obtain authorization before accessing service API; discover service API information; call service API.
  • CCF Mainly used to authenticate API callers based on the identity and other information required for API caller authentication; support mutual authentication with API callers; provide authorization for API callers before accessing the service API; publish , store and support the discovery of service API information; control business API access according to the policy configured by the PLMN operator; store service API call logs and provide service API call logs to authorized entities; bill based on service API call logs; monitor services API calls; adding new API callers and exiting API callers; storing policy configurations related to CAPIF and business APIs; supporting access logs for auditing (such as detecting abuse); supporting publishing and discovery using another CAPIF core function in CAPIF docking Service API information.
  • AEF is the provider of service API and the service communication entrance between service API and API callers. In 3GPP networks, AEF can be NEF. It is mainly used to authenticate API callers based on the identity and other information required for API caller authentication provided by the CAPIF core function; verify the authorization provided by the CAPIF core function; record the service API calls of the CAPIF core function.
  • AuF used to obtain user authorization.
  • AuF can provide an access token to the client after successfully authenticating the resource owner to provide user authorization.
  • Resource owner client The client that initiates the request, usually a browser, editor, web crawler or other tool used by the resource owner.
  • RO An entity that can grant access to protected resources. Resource owners can be individuals. In the application, it can be a signatory of 3GPP.
  • User consent information The user consent information involved in this application is used to indicate whether the user agrees to certain data operations. Specifically, the user consent information includes two parts: data processing purpose and user consent result, where the data processing purpose is used to indicate the purpose of the data operation.
  • the purpose of data operations includes but is not limited to: model training, data analysis, data sharing, non-terrestrial network location query, RAN data analysis, or RAN data model training, etc.
  • the purpose of data processing can be used to indicate that the purpose of data operation is model training, data analysis, or data sharing.
  • the purpose of data processing can also be called the purpose of data use, the purpose of data acquisition, etc.
  • the name of the information (or message) in this application is not limited in any way, as long as it can realize the corresponding function.
  • the user consent result is used to indicate whether the user agrees to the purpose of the data operation. For example, granted means agreement, not granted means disagreement. For example, 1 represents agreement and 0 represents disagreement.
  • the user consent information in this application may also include a network identifier.
  • the network identifier is used to identify the destination network that supports the user's consent or disapproval of data operations.
  • the network identifier can be a public land mobile network PLMN ID.
  • Integrity protection refers to the use of physical means or cryptographic methods to ensure that information has not been tampered with or modified without authorization during the process of generation, transmission, storage, and thereafter.
  • AF can request to obtain some 3GPP information processed by the 3GPP network. This information may include the processing of network data or the processing of user data. Especially for the processing of user data, AF should need to obtain the user's authorization. For example, AF can request 3GPP to send the user's location information to the outside. If the user's authorization is not obtained, the user's private information may be exposed. Therefore, a method is urgently needed for AF to obtain user authorization before requesting the 3GPP network to process user data.
  • Figure 2 (a) is the process of calling a specific API from CAPIF's CCF authorization API Invoker to AEF based on Oauth 2.0 client_credential in TLS with OAuth token, which specifically includes the following steps.
  • API caller (API Invoker) sends registration request message #1 to CCF.
  • CCF receives registration request message #1 from the API caller.
  • the registration request message #1 includes registration information and registration API.
  • the registration information includes API Invoker information, such as registration details, registration requirements, etc.
  • Registration API contains a list of APIs that need to be registered.
  • CCF sends registration response message #1 to the API caller.
  • the API caller receives registration response message #1 from CCF.
  • the registration response message #1 contains registration status, registered information and Service API information.
  • the registration status is used to indicate whether the registration result is successful or failed.
  • Registered information includes API Invoker ID, as well as authorization and authentication methods. Among them, the API Invoker ID is assigned by CCF to the API Invoker, and the authorization and authentication methods are used to indicate which authorization and authentication methods are used.
  • the authorization and authentication methods include TLS-PSK, PKI, and TLS with OAuth token. In this implementation, it is assumed that the authorization and authentication method is TLS with OAuth token.
  • Service API information is used to indicate registered API information, including one or more of the following: service API name, AEF location, IP address or domain name, port number, protocol, etc.
  • the API caller sends discovery service request message #1 to CCF.
  • CCF receives discovery service request message #1 from the API caller.
  • the discovery service request message #1 contains the API Invoker ID and request information.
  • the request information includes criteria for discovering certain APIs, such as preferred AEF locations, protocols, etc.
  • CCF sends discovery service response message #1 to the API caller.
  • the API caller receives discovery service response message #1 from CCF.
  • the discovery service response message #1 contains service API information.
  • the service API information responds to the API requested in step S213, and its information elements are the same as those in step S213.
  • CCF receives authorization request message #1 from the API caller.
  • the authorization request message #1 contains the API Invoker ID, service API name, and authorization method.
  • the authorization method indicates the Oauth method using the client credential client_credential mode.
  • CCF sends authorization response message #1 to the API caller.
  • the API caller receives the authorization response message #1 from CCF.
  • the authorization response message #1 contains token #1, and token #1 contains a statement and a signature.
  • the statement contains the following content: timeout, API Invoker ID, service API ID.
  • the signature is the digital signature of token#1 by CCF.
  • CCF After CCF confirms that the API Invoker can access the API name authorization according to the local policy, it sends the authorization response message #1 to the API Invoker.
  • API caller sends API call request message #1 to AEF.
  • AEF receives API call request message #1 from the API caller.
  • API call request message #1 contains API Invoker ID, service API ID and token #1.
  • the specific implementation method of verifying token#1 includes the following verification content:
  • AEF verifies the signature of token #1.
  • AEF verifies the signature of token #1 through the preconfigured CCF credentials (such as certificate).
  • AEF verifies the declaration part of token#1: AEF determines whether the API Invoker ID in the token#1 declaration is consistent with the API Invoker ID in the message; or, AEF determines whether the service API ID in the token#1 declaration is consistent with the message. The service API ID requested in the request is consistent; or, AEF determines whether the current token#1 has timed out based on the timeout time.
  • AEF sends API call response message #1 to API Invoker.
  • API Invoker receives call response message #1 from AEF
  • step S218 For example, if the judgment in step S218 above is passed, AEF agrees to the API call request and sends the call response message #1 to the API Invoker. On the contrary, if the judgment fails, the API call request information will be rejected.
  • Figure 2(b) is the process of CAPIF's access control policy-based CCF authorization API Invoker to AEF calling a specific API based on TLS-PSK or PKI, which specifically includes the following steps.
  • API caller (API Invoker) sends registration request message #11 to CCF.
  • CCF receives registration request message #11 from the API caller.
  • the registration request message #11 includes registration information and registration API.
  • CCF sends registration response message #11 to the API caller.
  • the API caller receives registration response message #11 from CCF.
  • the registration response message #11 includes registration status, registered information and Service API information.
  • the authorization and authentication method is TLS-PSK or PKI.
  • the API caller sends discovery service request message #11 to CCF.
  • CCF receives discovery service request message #11 from the API caller.
  • the discovery service request message #11 contains API Invoker ID and request information.
  • CCF sends discovery service response message #11 to the API caller.
  • the API caller receives discovery service response message #11 from CCF.
  • steps S221-S224 is similar to the above-mentioned steps S211-S214, and for the sake of simplicity, details will not be described here.
  • the API Invoker establishes a transport layer security (TLS) connection with CCF.
  • TLS transport layer security
  • CCF in step S222 is the TLS-PSK or PKI method
  • the API Invoker and CCF need to establish TLS connections in different ways. This application does not specifically limit the specific implementation method of establishing a TLS connection.
  • API Invoker sends API call request message #11 to AEF.
  • AEF receives API call request message #11 from API Invoker.
  • API call request message #1 contains API Invoker ID and service API ID.
  • the AEF sends the access control policy request message #11 to the CCF.
  • the CCF receives the obtain access control policy request message #11 from the AEF.
  • the obtain access control policy request message #11 includes AEF ID, API Invoker ID, and service API ID.
  • the CCF sends the obtain access control policy response message #11 to the AEF.
  • the AEF receives the obtain access control policy response message #11 from the CCF.
  • the obtain access control policy response message #11 includes access control policy information.
  • the access control policy information includes the access policy allowed by the API Invoker ID to request the service API ID, such as the maximum number of calls, the number of allowed calls per second, the allowed call time, etc.
  • AEF controls the API Invoker's call to the API.
  • AEF controls the API Invoker's call to the API based on the received access control policy.
  • AEF sends API call response message #11 to API Invoker.
  • API Invoker receives API call response message #11 from AEF.
  • Figure 2(c) is a general authorization process based on the OAuth2.0 authorization code (authorization code grant) mode, which specifically includes the following steps.
  • the client (Client) inputs information #a to the user agent (User agent).
  • the user agent receives information #a from the client.
  • information #a includes authorization server (authorization server, AuS) uniform resource locator (Uniform Resource Locator, URL), redirect URL, scope (scope) and response type (response type).
  • authorization server authorization server
  • AuS uniform resource locator
  • URL Uniform Resource Locator
  • redirect URL redirect URL
  • scope scope
  • response type response type
  • the AuS URL sent by the Client to the User agent is the AuS URL of app 2
  • the redirect URL is the URL of app 1
  • the scope is authorization.
  • Scope such as authorizing the use of avatar and mobile phone number resources
  • the response type is code, which is the authorization code mode.
  • the user agent sends the authorization request message #a to AuS.
  • AuS receives the authorization request message #a from the user agent.
  • the authorization request message #a includes redirect URL, scope and response type.
  • response type is code.
  • the user agent can determine the address of AuS based on the AuS URL.
  • AuS authenticates between the user agent and the RO.
  • AuS can skip the authentication process with RO.
  • AuS returns the authentication request web page to the user agent, and the user agent displays the authentication request web page to the RO.
  • AuS returns a prompt message requesting authentication to the user agent, and the user agent displays the message requesting authentication to the RO.
  • the AuS deployed by app 2 requires the user to enter a username and password. If the user agent already has relevant authentication information, this step can be omitted.
  • AuS sends user consent request message #a to the user agent, and the user agent sends user consent request message #a to RO.
  • the RO receives the user consent request message #a from the user agent, and the user agent receives the user consent request message #a from the AuS.
  • RO sends user consent response message #a to the user agent, and the user agent sends user consent response message #a to AuS.
  • AuS receives the user consent response message #a from the user agent, and the user agent receives the user consent response message #a from the RO.
  • the user agent After the user clicks Agree or Disagree, the user agent returns the response authorization content to AuS, and AuS obtains the user's Authorization.
  • AuS sends authorization response message #a to the user agent, and the user agent sends authorization response message #a to the client.
  • the client receives the authorization response message #a from the proxy
  • the user agent receives the authorization response message #a from the proxy.
  • the authorization response message #a includes redirect URL and code.
  • AuS After obtaining user authorization, AuS generates an authorization code and sends an authorization response message #a to the user agent.
  • S237 The client sends the access token request message #a to AuS through the backend application.
  • AuS receives the access token request message #a from the client through the backend application.
  • the access token request message #a is used to request to obtain a token.
  • AuS returns access token (access token) response message #a to the client.
  • the client receives the return access token response message #a from AuS.
  • the access token response message #a contains access token.
  • the client sends the access request message #a to the RO Server through the backend application.
  • RO Server receives the access request message #a from the client through the backend application.
  • the access request message #a contains access token.
  • RO Server verifies access token.
  • RO Server returns access response message #a to the client.
  • the client receives the access response message #a from the RO Server.
  • the access response message #a includes the resources requested by the client.
  • the client displays the web page to the user based on the redirect URL and the returned resources.
  • the user can see the web page of app 1 logged in using his own app 2 avatar.
  • Figure 2(d) is a general authorization process based on the implicit grant mode of OAuth2.0. This authorization process is similar to the authorization code mode, and is mainly oriented to scenarios where the client is only a front-end application. Specifically, it includes the following steps.
  • the client inputs information #aa to the user agent.
  • the user agent receives information #aa from the client.
  • the information #aa includes AuS URL, redirect URL, scope and response type.
  • the AuS URL sent by the Client to the User agent is the AuS URL of app 2
  • the redirect URL is the URL of app 1
  • the scope is authorization.
  • Scope such as authorizing the use of avatar and mobile phone number resources, and the response type is token.
  • the user agent sends the authorization request message #aa to AuS.
  • AuS receives the authorization request message #aa from the user agent.
  • the authorization request message #aa includes redirect URL, scope and response type.
  • response type is token.
  • AuS returns the authorization request webpage to the user agent, and the user agent displays the authorization request webpage to the RO.
  • AuS sends user consent request message #aa to the user agent, and the user agent sends user consent request message #aa to RO.
  • the RO receives the user consent request message #aa from the user agent, and the user agent receives the user consent request message #aa from the AuS.
  • RO sends user consent response message #aa to the user agent, and the user agent sends user consent response message #aa to AuS.
  • AuS receives the user consent response message #aa from the user agent, and the user agent receives the user consent response message #aa from the RO.
  • the user agent After the user clicks Agree or Disagree, the user agent returns the response authorization content to AuS, and AuS obtains the user's authorization.
  • steps S242-S245 is similar to the above-mentioned steps S232-S235, and for the sake of simplicity, details will not be described here.
  • AuS sends the access token response message #aa to the user agent, and the user agent sends the token response message #aa to the client.
  • the client receives the token response message #aa from the user agent, and the user agent receives the token response message #aa from AuS.
  • the token response message #aa includes the access token.
  • the client sends the access request message #aa to the RO Server through the backend application.
  • RO Server receives the access request message #aa from the client through the back-end application.
  • the access request message #a contains access token.
  • RO Server returns access response message #aa to the client.
  • the client receives the access response message #aa from the RO Server.
  • steps S247-S249 is similar to the above-mentioned steps S239, S230 and S240, and for the sake of brevity, they will not be described again here.
  • the current API Invoker can be authorized to access a specific API, but it cannot be implemented that the API Invoker is authorized to access the data of a specific user of a specific API, and the user has not been introduced. In other words, if the user's authorization is not obtained, AF may expose the user's private information when requesting the 3GPP network to process user data.
  • this application provides a communication method and communication device that actively obtains a more fine-grained user authorization token (token contains user identification) through API Invoker, and uses the token to access AEF, so that AEF can authorize API Invoker Access an API and process a user's data.
  • token contains user identification
  • AEF can authorize API Invoker Access an API and process a user's data.
  • the method disclosed in this application can avoid exposure of user privacy and reduce potential security risks faced by network functions in mobile communication networks.
  • “at least one” refers to one or more, and “plurality” refers to two or more.
  • “And/or” describes the association of associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A, B can be singular or plural.
  • the character "/” generally indicates that the related objects are in an "or” relationship.
  • “At least one of the following” or similar expressions thereof refers to any combination of these items, including any combination of a single item (items) or a plurality of items (items).
  • At least one of a, b and c can mean: a, or, b, or, c, or, a and b, or, a and c, or, b and c, or, a , b and c.
  • a, b and c can be single or multiple respectively.
  • for indication may include both for direct indication and for indirect indication.
  • certain indication information when used to indicate A, it may include that the indication information directly indicates A or indirectly indicates A, but it does not mean that the indication information must carry A.
  • the instruction methods involved in this application should be understood to cover various methods that can enable the party to be instructed to obtain the information to be instructed.
  • the information to be instructed can be sent together as a whole, or can be divided into multiple sub-information and sent separately, and the sending cycle and/or sending timing of these sub-information can be the same or different. This application does not limit the specific sending method.
  • the "instruction information" in this application can be an explicit instruction, that is, a direct instruction through signaling, or it can be obtained based on the parameters indicated by the signaling, combined with other rules or other parameters, or obtained through derivation. It can also be an implicit indication, that is, obtained based on rules or relationships, or based on other parameters, or derivation. This application does not specifically limit this.
  • protocol may refer to a standard protocol in the communication field, which may include, for example, 5G protocol, NR protocol, and related protocols applied in future communication systems. This application does not limit this.
  • Preconfigured may include predefined. For example, protocol definition. Among them, “pre-defined” can be achieved by pre-saving corresponding codes, tables or other information that can be used to indicate relevant information in the device. This application does not limit the specific implementation method.
  • storage may refer to saving in one or more memories.
  • the one or more memories may be a separate device, or may be integrated in an encoder or decoder, a processor, or a communication device.
  • the one or more memories may also be partially provided separately and partially integrated in the decoder, processor, or communication device.
  • the type of memory can be any form of storage medium, and this application is not limited thereto.
  • FIG 3 is a schematic flowchart of the communication method 300 provided by the embodiment of the present application. As shown in Figure 3, the method includes the following steps.
  • the API caller (API Invoker) sends an authorization request message to the authorization function network element (such as AuF).
  • the authorization function network element such as AuF
  • the authorization function network element receives the authorization request message from the API caller.
  • the authorization request message is used to request the authorization of the target user, and the authorization request message includes the identification of the target user.
  • the authorization request message also includes: the identification of the target API (Service API ID); and/or the identification of the API caller (API Invoker ID).
  • API Invoker ID is used to identify the API Invoker.
  • the API Invoker can be a UE or an AF, which is not specifically limited in this application.
  • target user can be understood as the resource owner RO, and the two names can be used interchangeably. This application does not specifically limit this.
  • the target user's identity is used to identify the user, such as but not limited to the user's user permanent identifier (subscription permanent identifier, SUPI), user hidden identifier (subscription conceaaled identifier, SUCI), general public user identifier (generic public subscription identifier, GPSI), permanent equipment identifier (permanent equipment identifier, PEI) or (mobile subscriber international ISDN/PSTN number, MSISDN), ISDN is the integrated service digital network (integrated service digital network), PSTN is the public switched telephone Network (public switched telephone ntwork), etc. MSISDN can be understood as the user's identity that can be disclosed to the outside world, such as the user's phone number.
  • target API is used to indicate the API that requires authorization.
  • Service API ID is used to indicate the identity of the API that the API Invoker expects to call.
  • the API indication is used to indicate the specific operation method for the user's personal data, such as collection, reading, analysis, sharing, etc.
  • the Service API ID may include but is not limited to: locating Nnef_Location, obtaining Nnef_UEIdentifier_Get, subscribing to analysis Nnwdaf_AnalyticsSubscription_Subscribe and other messages.
  • a server calls the AEF API to request the UE identity through the API call request message #A, such as Nnef_UEIdentifier_Get.
  • the input user information is set to the IP address or domain name of a certain UE, and the AF ID is set to the ID of the discussion server.
  • This action Requests on behalf of the server to obtain the identification information of the user (UE) corresponding to the IP address or domain name.
  • the API call request message #A instructs the server to read the user's personal data (ie, identity information).
  • the authorization request message also includes response type and/or range indication information.
  • the response type is used to indicate the current authorization method, for example, code indicates the authorization code mode, and token indicates the implicit mode.
  • the scope indication information is used to indicate the scope of authorization, for example, it can include the Service API ID and the identity of the target user.
  • the authorization request message may be an OAuth2.0 Authorization Request message.
  • the API caller sends an authorization request message to the authorization function network element according to the authorization instruction.
  • the authorization indication is used to indicate that the request to operate the target user's data requires authorization from the target user.
  • the authorization indication may come from the AEF. That is, before the API caller sends the authorization request message to the authorization function network element, the method also includes S301-S303:
  • the API caller sends a second API call request message to AEF.
  • AEF receives the second API call request message from the API caller.
  • the second API call request message is used to request to call the target API to operate the target user's data.
  • the message includes the identification of the target user;
  • the second API call request message also includes the identification of the target API and/or the identification of the API caller.
  • the second API call request message may itself carry information about the target API.
  • the second API call request message may be a Service API Invocation Request message.
  • AEF determines that the request to operate the target user's data requires authorization from the target user.
  • AEF determines that the user consent information of the target user is not stored locally, and the user consent information indicates that the target user agrees to operate the target user's data.
  • AEF can determine that calling the target API requires authorization from the target user based on the locally configured API list.
  • the APIs in the API list are all APIs that require user consent.
  • the API list may be pre-configured by AEF, or may be configured by other network elements for AEF, which is not specifically limited in this application.
  • AEF does not save the user consent information of the target user. It can be understood that AEF does not store the target user's UE context locally, or it can also be understood that the target user's user consent information is not saved in the locally stored UE context of the target user. .
  • the API list can also correspond to the address of the authorized function network element, that is, the AEF obtains the address of the authorized function network element based on the target API, so that the AEF can subsequently request the AuF to obtain authorization from the target user.
  • the AEF can send an acquisition request message to the UDM to reduce unnecessary signaling overhead.
  • user consent information includes the purpose of data processing and the results of user consent.
  • the purpose of data processing is used to indicate the purpose of operating the user's personal data, such as model training, data analysis, data sharing, etc.
  • the user consent result is used to indicate whether the user agrees to the purpose of using the data. For example, granted means agreement, not granted means disagreement.
  • User ID 2 is converted from User ID 1, which also represents the target user UE, but is converted for different network element interactions.
  • the AEF can directly perform step S309. F's address and requests AuF to obtain the user's authorization. For example, by carrying bit "1" in Authorization Instruction #1, the API Invoker is instructed to require the user's authorization to operate on the user's personal data;
  • AuF address (such as IP address or domain name).
  • the AuF address can be preconfigured on AEF in advance. For example, each API in the AEF's local preconfigured API list corresponds to an AuF address. Then AEF can determine the AuF address that the API Invoker needs to find based on the Service API ID;
  • Authorization method used to indicate the specific method of authorization, such as OAuth 2.0 authorization code mode, implicit mode, etc.
  • Cause value used to indicate that the request to operate the target user's data requires authorization from the target user.
  • the reason value can be cause#1, which is used to indicate that the API caller needs to obtain the target user's authorization before operating the target user's personal data.
  • the AEF sends a second API call response message to the API caller, and the second API call response message includes authorization indication #1.
  • the second API call response message also includes the identification of the target API and/or the identification of the target user.
  • the Service API ID is used to indicate the API that needs to be authorized
  • the target user's ID is used to indicate the target user that needs to be authorized.
  • the second API call response message is a redirect request message.
  • the redirect request message #A may be an HTTP message with status code 302.
  • the authorization indication may come from the CCF. That is, before the API caller sends the authorization request message to the authorization function network element, the method also includes S304-S305:
  • the API caller sends a second request message to CCF.
  • CCF receives the second request message from the API caller.
  • the second request message is used to request to register the API caller to the CCF or for the API caller to discover the API.
  • the second request message may be a registration request message or a discovery service request message.
  • the second request message may be an Onboard Service Request message or a Discovery Service Request message.
  • CCF sends authorization instruction #2 to the API caller.
  • the API caller receives authorization indication #2 from CCF.
  • authorization instruction #2 includes the address of the authorized functional network element.
  • the CCF sends a second response message (ie, an example of the second API call response message) to the API caller, and the second response message includes authorization indication #2.
  • a second response message ie, an example of the second API call response message
  • the second response message also includes the identification of the target API and/or the identification of the target user.
  • the second response message is a registration response message or a discovery service response message.
  • the second response message may be an Onboard Service Response message or a Discovery Service Response message.
  • the second API call response message is a redirect request message.
  • the redirect request message may be an HTTP message with status code 302. For example, if the redirect request message requires the API caller to perform a temporary redirect (moved temporarily), the API caller should continue to send requests to the AuF address.
  • the authorization instruction #2 may include one or more of the following:
  • Explicit instructions that is, the authorization instruction #2 is used to instruct the API Invoker to determine the address of AuF and request AuF to obtain the user's authorization. For example, by carrying bit "1" in Authorization Instruction #2, the API Invoker is instructed to require the user's authorization to operate on the user's personal data;
  • AuF address (such as IP address or domain name).
  • the AuF address can be preconfigured on AEF in advance. For example, each API in the AEF's local preconfigured API list corresponds to an AuF address. Then AEF can determine the AuF address that the API Invoker needs to find based on the Service API ID;
  • Authorization method used to indicate the specific method of authorization, such as OAuth 2.0 authorization code mode, implicit mode, etc.
  • the authorization indication #2 includes a reason value, and the reason value is used to indicate that the request to operate the data of the target user requires authorization of the target user.
  • the second response message also includes the Service API ID and/or the identification of the target user.
  • the Service API ID is used to indicate the API that needs to be authorized
  • the target user's ID is used to indicate the target user that needs to be authorized.
  • the second response message is a redirection request message.
  • the redirect request message may be an HTTP message with status code 302.
  • the API caller can determine the address of AuF and send an authorization request message to AuF.
  • the API Invoker can determine the AuF address corresponding to the Service API ID based on the local preconfigured AuF address list, and request the AuF to obtain the user's authorization; for another example, If the authorization instruction contains (2) the address of AuF, the API Invoker can directly send the authorization request message #A to AuF based on the AuF address.
  • the API Invoker can determine the response type based on the (3) authorization method in Authorization Instruction #1 or Authorization Instruction #2.
  • This response type can be carried in the authorization request message. For example, if the authorization method is the authorization code mode of OAuth 2.0, the response type should be code; if the authorization method is the implicit mode of OAuth2.0, the response type should be token.
  • the API caller determines the address of the authorization function network element according to the reason value (4) in authorization instruction #1 or authorization instruction #2; further, the API caller determines the address of the authorization function network element according to the address of the authorization function network element.
  • the network element sends an authorization request message.
  • the API caller obtains the address of the authorized function network element from the configured address list based on the reason value in authorization instruction #1 or authorization instruction #2. For example, the API caller determines through the cause value, such as cause#1, that the request to operate the target user's personal data requires obtaining the authorization of the target user, and then finds the corresponding AuF address based on the address list, or based on the AuF address sent by AEF, Authorize AuF.
  • the cause value such as cause#1
  • the API caller determines the response type according to the authorization type.
  • the API caller determines to request AuF to obtain the user's authorization according to the authorization instructions, which can realize user authorization control for specific APIs and improve the flexibility of user authorization.
  • CCF can forward as an intermediate node to obtain user authorization from AuF.
  • the API caller does not need to send an authorization request message to AuF according to the authorization instruction, which can reduce the signaling overhead of the API.
  • CCF receives the authorization request message from the API caller.
  • the API caller can determine the response type, and sends an authorization request message to CCF.
  • the API Invoker can determine the response type corresponding to the Service API ID based on the local preconfigured response type, and request the CCF to obtain the user's authorization. For example, if explicit instructions are received, the API invoker sets the response type to code or token.
  • the API Invoker can determine the response type based on the (3) authorization method in Authorization Instruction #1 or Authorization Instruction #2.
  • This response type can be carried in the authorization request message. For example, if the authorization method is the authorization code mode of OAuth 2.0, the response type should be code; if the authorization method is the implicit mode of OAuth2.0, the response type should be token.
  • the API caller determines the authorization response type based on the reason value (4) in authorization instruction #1 or authorization instruction #2. For example, if the received reason value indicates that the request to operate the target user's data requires authorization from the target user, the API invoker sets the response type to code or token.
  • the CCF sends an authorization request message to the authorization function network element.
  • the authorization function network element receives the authorization request message from the CCF.
  • the authorization request message includes the identity of the API caller, the identity of the target API, and the identity of the target user.
  • the CCF before the CCF sends the authorization request message to the authorized function network element, the CCF can determine the address of the authorized function network element based on the address list; and based on the address of the authorized function network element, sends the authorization to the authorized function network element. Request message.
  • the address list is used to indicate the mapping relationship between the identifier of the target API and the address of the authorized function network element.
  • the address list may be locally configured by the CCF, may be pre-configured by the CCF, or may be configured by other network functional network elements for the CCF, which is not specifically limited.
  • the first token is used to indicate that the API caller has the authority to access the target user's data, and the first token includes the target user's identity.
  • the first token also includes one or more of the following: timeout; identity of the API caller; identity of the target API; signer.
  • the signer is used to indicate the signing entity, so that AuF can select different certificates to verify the first token according to different signers.
  • the signer may be used to indicate the identity of the network element that signed the first token, or to indicate the identity of the network element that generated the first token, or to indicate the identity of the authorized function network element.
  • the signer can be an AuF ID or CAPIF ID, an AuF type or a CAPIF type, or any of the following: authorization code, implicit, client credential, user password credential authorization, user authorization or Network function authorization.
  • the first token also includes one or more of the following: the generation time of the first token, the validity period of the first token, the validity expiration time of the first token, etc.
  • the first token also includes other parameters, such as resources allowed to be used, network slice information, etc., which are not specifically limited in this application.
  • the authorization function network element first generates a statement based on the above parameters; then generates a signature based on the statement; and finally generates a first token with integrity protection based on the statement and signature.
  • generating the first token based on the target user's identification information can achieve more fine-grained authorization, that is, the API caller can be authorized to have access to the target API to operate the target user's personal data.
  • the authorization function network element sends an authorization response message to the API caller.
  • the API caller receives the authorization response message from the authorization function network element.
  • the authorization response message includes a first token with integrity protection, the first token is used to indicate that the API caller has the authority to access the target user's data, and the first token includes the identification of the target user;
  • the authorization response message includes the first token with integrity protection.
  • the authorization response message includes failure indication information, and the failure indication information is used to indicate that the user has not Authorization API Invoker calls Service API to operate user data.
  • the authorization response message may be an OAuth2.0 Authorization Response message.
  • the API caller receives the authorization response message from the authorization function network element, and can also forward it through CCF as an intermediate node, corresponding to the following steps S331 and S332.
  • the authorization function network element sends an authorization response message to the CCF.
  • the CCF receives the authorization response message from the authorization function network element.
  • CCF sends an authorization response message to the API caller.
  • the API caller receives the authorization response message from the authorization function network element.
  • the authorization response message includes a first token with integrity protection.
  • the first token is used to indicate that the API caller has the authority to access the target user's data.
  • the first token includes the identity of the target user.
  • the API caller can send a first API call request message to the AEF based on the first token obtained in the above step S330 or S305, for requesting to call the target API to operate the target user's personal data.
  • S340 The API caller sends the first API call request message to AEF.
  • AEF receives the first API call request message from the API caller.
  • the first API call request message is used to request to call the target API to operate the target user's data, and the first API call request message includes the target user's identity and the first token.
  • the first API call request message also includes the identification of the target API (Service API ID) and/or the identification of the API caller (API Invoker ID).
  • the first API call request message may itself carry information about the target API.
  • the first API call request message may be a Service API Invocation Request message.
  • the first API call request message also includes a second token.
  • the second token is used to indicate that the API caller has the authority to call the target API.
  • the second token includes the identity of the API caller and the name of the target API. logo.
  • the API caller before the API caller sends the first API call request message to AEF, the API caller can request the CCF to obtain the second token, that is, the method also includes the following steps S306-S307:
  • the API caller sends the first request message to CCF.
  • CCF receives the first request message from the API caller.
  • the first request message is used to request permission to call the target API, and the first request message includes the identifier of the API caller and the identifier of the target API.
  • the first request message may be a registration API Invoker request message or a discovery service request message.
  • the first request message may be an Onboard API Invoker Request message or a Discovery Service Request message.
  • CCF sends the second token to the API caller.
  • the API caller receives the second token from CCF.
  • the second token includes the identification of the target API.
  • the second token further includes at least one of the following: the identity of the API caller; the timeout period, and the signature.
  • the second token also includes one or more of the following: the generation time of the second token, the validity period of the second token, the validity expiration time of the second token, etc.
  • AEF can determine that the API caller has the authority to call the target API, that is, the method also includes step S308.
  • AEF determines that the API caller has the authority to call the target API based on the second token.
  • AEF can separately verify the signature of the second token, the identity of the API caller, the identity of the target API, the timeout period, etc.
  • the AEF can verify the signature of the second token through the preconfigured CCF credentials (such as a certificate).
  • AEF continues to verify the information part in the second token.
  • AEF determines that the identity of the target API carried in the second token is the same as the identity of the target API carried in the first API call request message, and determines that the API caller has the authority to call the target API.
  • AEF determines whether the API Invoker ID carried in the second token is consistent with the API Invoker ID in the API call request message.
  • AEF determines whether the current token has timed out based on the timeout period carried in the second token.
  • AEF determines the second token based on the validity period of the second token being 5 hours, the generation time of the second token being 2:30, and the time AEF receiving the API call request message being 10:30. has expired, thereby denying the API Invoker's request to access the target API.
  • the validity deadline of AEF according to the second token is 12:30, the time when AEF receives the API call request message is 12:00, and the signature and specific information content carried in the second token are verified and passed. , you can accept API Invoker's target API call request.
  • AEF can usually further determine whether the API caller has the authority to operate the target user's data after determining whether the API caller has the authority to call the target API. That is to say, this application does not limit the execution order of step S308 and step S350.
  • S350 AEF determines whether the API caller has the authority to operate the target user's data based on the first token.
  • the first token includes two parts: a statement and a signature. Therefore, AEF needs to determine whether the API caller has the authority to operate the target user's data based on the two parts: the statement and the signature.
  • the specific implementation method includes the following two steps.
  • Step 1 AEF verifies the signature of the first token.
  • the AEF verifies the integrity protection of the first token based on the credentials of the authorized function network element, which is the network element that generated the first token.
  • the credentials of the authorized functional network element may be pre-configured by the AEF.
  • the AEF may obtain the credentials of the authorized functional network element based on the signer.
  • the first token also includes the signer.
  • AEF can obtain the credentials of authorized functional network elements based on the signer.
  • AEF can pre-configure the certificate corresponding to the signer, that is, AEF can obtain the certificate corresponding to the signer AuF ID or CAPIF ID, and then verify the signature of the first token;
  • AEF can pre-configure credentials corresponding to different signer types, that is, AEF can obtain the credentials corresponding to AuF or CAPIF, and then verify the signature of the first token; if the signer is any of the following One item: authorization code, implicit, client certificate, user password certificate.
  • AEF can pre-configure certificates corresponding to different signer types, that is, authorization code, implicit, or user password certificates can use AuF certificates, and client certificates can Use CAPIF credentials; if the signer is user authorization or network function authorization, AEF pre-configures credentials corresponding to different signer types, that is, user authorization can use AuF credentials, and network function authorization can use CAPIF credentials.
  • AEF successfully verifies the signature of the first token using the preconfigured credentials, it means that the first token has not been tampered with. Otherwise, the verification fails and AEF can reject the API Invoker's call request to the target API.
  • AEF will continue to verify the statement part of step two, that is, verify the content information of the first token.
  • Step 2 AEF verifies the information content in the claim of the first token.
  • the statement includes the identification of the target user.
  • the AEF determines whether the identity of the target user carried in the first token is the same as the identity of the target user carried in the first API call request message.
  • the statement also includes at least one of the following: timeout; identity of the API caller; identity of the target API, etc.
  • the AEF determines whether the API caller's identity carried in the first token is the same as the API caller's identity carried in the first API call request message.
  • the AEF determines whether the identity of the target API carried in the first token is the same as the identity of the target API carried in the first API call request message.
  • the statement may also include one or more of the following: the generation time of the first token, the validity period of the first token, the validity deadline of the first token, etc.
  • the validity period of the first token is 12h
  • the generation time of the first token is 2:30
  • the time when AEF receives the API call request message #B is 12:30 then AEF is in the first token. If the signature and specific information content are verified, the API call request from the API Invoker can be accepted.
  • the validity deadline of the first token is 12:30
  • the time when AEF receives the API call request message #B is 12:00 then AEF will pass the verification of the signature and specific information content of the first token. , can accept API call requests from API Invoker, etc.
  • AEF can determine that the API caller has the authority to operate the target user. Data permissions. Otherwise, AEF may determine that the API caller does not have permission to manipulate the target user's data.
  • S360 AEF determines whether to provide the API caller with permission to access the target user's data based on the determination result.
  • the verification result of the first token for example, if the first token verification is successful
  • two methods can be used: For example, verify the second token to determine whether the API caller has the permission to access the target API; or AEF verifies the access control list to CCF and requests to obtain the access policy for the API caller to call the target API.
  • AEF provides the API caller with the permission to access the target user's data.
  • the access policy indicating that the API caller is allowed to call the target API may be obtained from the AEF.
  • the AEF sends a third request message to the CCF and receives the access policy from the CCF.
  • the third request message is used to request to obtain the access policy for the API caller to call the target API.
  • the third request message includes the identifier of the API caller and the identifier of the target API.
  • the access policy is used to indicate whether the API caller is allowed to call the target API. .
  • AEF can provide the API caller with the permission to access the target user's data. That is, the method also includes step S309.
  • the API caller receives the first API call response message from AEF.
  • the first API call response message is used to return the result of the API Invoker ID calling the target API to operate the user data.
  • the authorization API Invoker ID has the permission to call the target API to operate user data.
  • API call request message #B such as Nnef_UEIdentifier_Get
  • the input user information is set to the IP address or domain name of a certain UE
  • the AF ID is set to the ID of the discussion server.
  • the AEF will return the API call response message #B, which contains the external identifier of the UE, such as GPSI.
  • AEF can send a contract information update message to the UDM to update the target user's user consent information, and the user consent information is used to instruct the target user to agree to the operation.
  • Target user data when the API caller has the authority to operate the target user's data, AEF can send a contract information update message to the UDM to update the target user's user consent information, and the user consent information is used to instruct the target user to agree to the operation.
  • Target user data can be used to instruct the target user to agree to the operation.
  • the subscription information update request message is used to update the user consent information of the UE.
  • the subscription information update message may include one or more of the following: user identification, data processing purpose, API Invoker ID, timeout, and user consent result.
  • the data processing purpose is converted according to the Server API ID, and the user consent result can be obtained according to the user consent information #A in step S420.
  • the number of times AuF requests RO authorization can be reduced by updating the UE subscription information on UDM through AEF.
  • the API Invoker obtains the first token for more fine-grained user authorization from the authorization function network element and uses the first token to access the AEF, thereby enabling the AEF to authorize the API Invoker to access an API and Process a user's data.
  • This method introduces the consideration of user authorization when processing user data, which can prevent users' private information from being exposed and reduce potential security risks faced by network functions in mobile communication networks.
  • the granularity is only NF1 authorizing NF2 to access a certain API.
  • This implementation introduces AuF and more fine-grained tokens, thereby introducing users in the authorization process.
  • the granularity can reach NF1 to authorize NF2 to access an API and call a user's data.
  • FIG 4 is a flow example diagram of the communication method 400 provided by the embodiment of the present application. As shown in Figure 4, the method includes the following steps.
  • the API caller (API Invoker) sends the API call request message #A (that is, an example of the second API call request message) to the AEF.
  • API call request message #A that is, an example of the second API call request message
  • AEF receives the API call request message #A from the API caller.
  • the API call request message #A is used to request to call the Service API (ie, an example of the target API) to operate the user's personal data.
  • the API call request message #A includes the API caller's identification (API Invoker ID) .
  • the API Invoker ID is used to identify the API Invoker.
  • Service API ID is used to indicate the identity of the API that the API Invoker expects to call.
  • the API indicates the specific operation method for the user's personal data, such as collection, reading, analysis, sharing, etc.
  • the API Invoker can be UE or AF.
  • AEF can be NEF, AEF is The provider of Service API is also the service communication entrance of API Invoker. This application does not limit this.
  • the API call request message #A also includes user identification 1 (that is, an example of the identification of the target user), and/or the identification of the target API (Service API ID).
  • the user identifier 1 may include but is not limited to SUPI, SUCI, GPSI, PEI or MSISDN.
  • the API call request message #A itself carries the Service API ID.
  • the API call request message #A may include but is not limited to: locating Nnef_Location, obtaining Nnef_UEIdentifier_Get, subscribing to analysis Nnwdaf_AnalyticsSubscription_Subscribe and other messages.
  • user identification 1 is not limited in this application, as long as it can be used to identify the user. In this application, there are no restrictions on the name of the API call request message (or information), as long as the corresponding function can be implemented.
  • AEF determines whether the current API call requires user consent, and generates a redirection request message #A (ie, an example of a redirection request message).
  • the redirect request message #A is used to instruct the API Invoker to request AuF to obtain the user's authorization.
  • AEF can determine whether the current API requires user consent based on local configuration information.
  • the local configuration information can be an API list, and all APIs in the API list are APIs that require user consent.
  • the API list can also correspond to the AuF address, that is, each API corresponds to an AuF address, and AEF can determine the AuF address corresponding to the Service API based on the API list.
  • AEF can generate redirect request message #A.
  • the AEF when it is determined that the API Invoker requires user consent to call the current Service API, and the AEF does not successfully obtain the user consent information of the UE from the UDM, the AEF can generate a redirect request message #A. For example, the AEF sends a subscription information acquisition request message to the UDM to request to obtain the subscription information of the UE.
  • the subscription information acquisition request message includes user ID 2.
  • the subscription information acquisition response message sent by UDM to the AEF does not contain the user consent information of the UE.
  • the subscription information acquisition request message may be a Nudm_SDM_Get Request message
  • the subscription information acquisition response message may be a Nudm_SDM_Get Response message.
  • AEF needs to notify the API Invoker and look for AuF for user authorization.
  • the AEF can directly perform step S470.
  • AEF sends a redirect request message #A to the API caller.
  • the API caller receives the redirect request message #A from AEF.
  • the redirection message #A includes an authorization indication.
  • the authorization indication may include one or more of the following:
  • Explicit instructions that is, the authorization instructions are used to instruct the API Invoker to determine the address of AuF and request AuF to obtain the user's authorization. For example, by carrying bit "1" in the authorization indication, the API Invoker is instructed to require the user's authorization to operate on the user's personal data;
  • AuF address (such as IP address or domain name).
  • the AuF address can be preconfigured on AEF in advance. For example, each API in the AEF's local preconfigured API list corresponds to an AuF address. Then AEF can determine the AuF address that the API Invoker needs to find based on the Service API ID;
  • Authorization method used to indicate the specific method of authorization, such as OAuth 2.0 authorization code mode, implicit mode, etc.
  • the redirect message #A also includes Service API ID, and/or user ID 1.
  • Service API ID is used to indicate the API that requires authorization.
  • the redirect request message #A may be an HTTP message with status code 302.
  • step S403 may be replaced by: AEF sends an authorization instruction to the API caller, where the authorization instruction includes a reason value, and the reason value is used to indicate that the request to operate the target user's data requires the authorization of the target user.
  • the API caller determines the address of the authorized function network element based on the cause value; the API caller sends an authorization request message to the authorized function network element based on the address of the authorized function network element.
  • the API caller obtains the address of the authorized function network element from the preconfigured address list based on the reason value.
  • the API caller sends the authorization request message #A (ie, an example of the authorization request message) to AuF.
  • #A ie, an example of the authorization request message
  • AuF receives the authorization request message #A from the API caller.
  • the authorization request message #A is used to request to obtain the user's authorization, and the authorization request message #A includes user identification 1 (that is, an example of the identification of the target user).
  • the authorization request message #A also includes Service API ID, and/or API Invoker ID.
  • the Service API ID, and/or User ID 1 is obtained from redirect message #A.
  • the authorization request message #A also includes response type and/or range indication information.
  • the response type is used to indicate the current authorization method, for example, code indicates the authorization code mode, and token indicates the implicit mode.
  • the scope indication information is used to indicate the scope of authorization, for example, it can include Service API ID and user ID 1.
  • the API Invoker sends an authorization request message #A to AuF based on the redirect request message #A in step S403.
  • the API Invoker determines the AuF address for authorization based on the authorization instruction. For example, if the authorization instructions include (1) explicit instructions, then the API Invoker can determine the AuF address corresponding to the Service API ID based on the local preconfigured AuF address list, and request the AuF to obtain the user's authorization; for another example, if authorization The indication contains (2) the address of AuF. At this time, the API Invoker can directly send the authorization request message #A to AuF based on the AuF address.
  • the API Invoker can determine the response type based on (3) authorization method in the authorization indication.
  • This response type may be carried in the authorization request message #A. For example, if the authorization method is the authorization code mode of OAuth 2.0, the response type should be code; if the authorization method is the implicit mode of OAuth2.0, the response type should be token.
  • the authorization request message #A may be an OAuth2.0 Authorization Request message.
  • AuF interacts with the RO client to obtain user consent information #A.
  • AuF determines the authorization response message #A (that is, an example of the authorization response message).
  • the authorization response message #A includes a token with integrity protection, and the token includes the user ID 1.
  • the authorization response message #A includes failure indication information, and the failure indication information is used to indicate that the user is not authorized to call the Service API to operate the API Invoker.
  • AuF sends authorization response message #A to the API caller.
  • the API caller receives the authorization response message #A from AuF.
  • the API caller sends an access token request message #A to AuF.
  • AuF receives the access token request message #A from the API caller.
  • AuF sends the access token response message #A to the API caller.
  • the API caller receives the access token response message #A from AuF.
  • the access token response message #A includes a token with integrity protection, and the token includes user identification 1.
  • the signature of the token with integrity protection may be the digital signature of the token by AuF.
  • the token can also include claims, which include one or more of the following: timeout, API Invoker ID, service API ID, and signer.
  • the signer is used to indicate the signing entity, so that AuF can select different certificate verification tokens according to different signers.
  • the signer can be an AuF ID or CAPIF ID, an AuF type or a CAPIF type, or any of the following: authorization code, implicit, client credential, user password credential authorization, user authorization or Network function authorization.
  • the statement may also include one or more of the following: token generation time, token validity period, token validity expiration time, etc.
  • the statement may also include other parameters, such as resources allowed to be used, network slicing information, etc., which are not specifically limited in this application.
  • the specific implementation method may refer to the authorization method based on the OAuth2.0 authorization code (authorization code grant) mode shown in (c) of Figure 2 for authorization.
  • the specific implementation method can refer to the authorization method based on the implicit grant mode of OAuth2.0 shown in (d) of Figure 2 for authorization.
  • the authorization method based on the implicit grant mode of OAuth2.0 shown in (d) of Figure 2 for authorization.
  • the API caller sends the API call request message #B (that is, an example of the first API call request message) to the AEF.
  • AEF receives the API call request message #B from the API caller.
  • the API call request message #B includes user identification 1 (that is, an example of the target user's identification), and a token with integrity protection (that is, an example of the first token). Among them, token includes user ID 1.
  • the API call request message #B includes API Invoker ID, and/or Service API ID.
  • the token includes one or more of the following: timeout, API Invoker ID, Service API ID, signer.
  • the signer can not be placed in the token declaration, but carried in the API call request message #B.
  • the specific implementation method of AEF verification token includes the following two steps:
  • Step 1 AEF verifies the signature of the token, that is, verifies the integrity protection of the token.
  • AEF verifies the signature of the token based on the preconfigured AuF credentials (such as certificate).
  • AEF determines what kind of credentials to use to verify the token's signature based on the signer (which can be carried in the token's declaration or in the API call request message #B). For example, if the signer is AuF ID or CAPIF ID, AEF can pre-configure the certificate corresponding to the signer, that is, AEF can obtain the certificate corresponding to the signer AuF ID or CAPIF ID, and then verify the signature of the token; for another example, if the signature Either AuF or CAPIF, AEF can pre-configure credentials corresponding to different signer types, that is, AEF can obtain the credentials corresponding to AuF or CAPIF, and then verify the signature of the token; if the signer is any of the following: authorization code, implicit , client credentials, user password credentials, AEF can pre-configure credentials corresponding to different signer types, that is, authorization code, implicit, or user password credentials can use AuF credentials, and client credentials can use CAPIF credentials; if the signer It is user authorization or network function
  • AEF will continue to verify the statement part of step two, that is, verify the content information of the first token.
  • Step 2 AEF verifies the token’s declaration.
  • AEF can determine whether the user ID 1 in the API call request message #B is consistent with the user ID 1 in the token.
  • AEF determines whether the API Invoker ID in the API call request message #B is consistent with the API Invoker ID in the token; or, AEF determines whether the Service API ID in the API call request message #B is consistent with the Service API ID in the token. Consistent; or, AEF determines whether the token is still valid based on the timeout period in the token compared with the current time, etc.
  • the token can usually be reused by API Invoekr within the validity period.
  • the statement may also include one or more of the following: token generation time, token validity period, token validity expiration time, etc.
  • the validity period of the token is 12h
  • the generation time of the token is 2:30
  • the time when AEF receives the API call request message #B is 12:30 then AEF will pass the verification of the signature and specific information content of the token.
  • the valid expiration time of the token is 12:30, and the time when AEF receives the API call request message #B is 12:00, then AEF can accept the API Invoker's request if the token's signature and specific information content are verified.
  • AEF can accept the API call request from the API Invoker, that is, AEF executes the following steps S470 and S406. If the above judgment fails, AEF can reject the API call request of the API Invoker.
  • AEF sends API call response message #B to the API caller.
  • the API caller receives the API call response message #B from AEF.
  • the API call response message #B is used to return the result of the API Invoker ID calling the target API to operate the user data.
  • the authorized API Invoker ID has the permission to call the target API to operate user data.
  • API call request message #B such as Nnef_UEIdentifier_Get
  • the input user information is set to the IP address or domain name of a certain UE
  • the AF ID is set to the ID of the discussion server.
  • the AEF will return the API call response message #B, which contains the external identifier of the UE, such as GPSI.
  • the AEF sends the subscription information update request message #A to the UDM.
  • UDM receives the subscription information update request message #A from the AEF.
  • the subscription information update request message #A is used to update the user consent information of the UE.
  • the subscription information update message #A can include one or more of the following: user identification 2, data processing purpose, API Invoker ID, timeout time, User agrees with the results.
  • the user identification 2 is converted according to the user identification 1, which can be SUPI
  • the data processing purpose is converted according to the Server API ID
  • the user consent result can be obtained according to the user consent information #A in step S420.
  • the number of times AuF requests RO authorization can be reduced by updating the UE subscription information on UDM through AEF.
  • the method disclosed in this application generates a more fine-grained token (including user identification 1) by introducing AuF, so that the user consent information is considered in the authorization process, and the granularity can reach NF1 to authorize NF2 to access a certain API and call a certain user's data. .
  • a more fine-grained token including user identification 1
  • the granularity is only for NF1 to authorize NF2 to access a certain API.
  • This implementation requires user authorization when processing user data, protects user privacy information, and can avoid user privacy exposure. , Reduce potential security risks faced by network functions in mobile communication networks.
  • FIG. 5 is a flow example diagram of the communication method 500 provided by the embodiment of the present application.
  • This implementation provides the API Invoker with the information required for user authorization through CCF, and decouples the token for calling the API from the token for operating the user's personal data.
  • the method includes the following steps.
  • the API caller sends a registration request message #AA or a discovery request message #AA (that is, an example of the second request message) to the CCF.
  • CCF receives the registration request message #AA from the API caller, or the discovery request message #AA.
  • the registration request message #AA or the discovery request message #AA includes user identification 1 (that is, an example of the target user) and Server API ID (that is, an example of the identification of the target API).
  • the specific meaning of the registration request message #AA or the discovery request message #AA can be referred to the specific meaning of the message in the above step S211 or S213.
  • the registration request message #AA is used to register the API caller to CCF.
  • the discovery request message #AA is used by API callers to discover the target API.
  • CCF sends a registration response message #AA or a discovery response message #AA (that is, an example of the second API call response message) to the API caller.
  • the API caller receives the registration response message #AA from CCF, or the discovery response message #AA.
  • the registration response message #AA or the discovery response message #AA includes an authorization indication.
  • the specific meaning of the registration response message #AA or the discovery response message #AA can be referred to the specific meaning of the message in the above step S212 or S214.
  • the authorization indication may include one or more of the following:
  • Explicit instructions that is, the authorization instructions are used to instruct the API Invoker to determine the address of AuF and request AuF to obtain the user's authorization. For example, by carrying bit "1" in the authorization indication, the API Invoker is instructed to require the user's authorization to operate on the user's personal data;
  • AuF address (such as IP address or domain name).
  • the AuF address can be preconfigured on AEF in advance. For example, each API in the AEF's local preconfigured API list corresponds to an AuF address. Then AEF can determine the AuF address that the API Invoker needs to find based on the Service API ID;
  • Authorization method used to indicate the specific method of authorization, such as OAuth 2.0 authorization code mode, implicit mode, etc.
  • the registration response message #AA, or the discovery response message #AA also includes Service API ID, and/or user ID 1.
  • Service API ID is used to indicate the API that requires authorization.
  • the API caller sends the authorization request message #AA (ie, an example of the first request message) to the CCF according to the authorization instruction.
  • #AA ie, an example of the first request message
  • CCF receives the authorization request message #AA from the API caller.
  • the authorization request message #AA is used to request permission to call the Service API.
  • the authorization request message #AA includes the API Invoker ID and the Service API ID.
  • CCF sends the authorization response message #AA to the API caller.
  • the API caller receives the authorization response message #AA from CCF.
  • the authorization response message #AA includes token1 (that is, an example of the second token), and token1 is used to indicate that the API Invoker has the authority to access the Service API.
  • the API caller determines to request AuF for authorization according to the authorization instruction.
  • APIInvoker needs to additionally request AuF for user authorization. Therefore, when the API Invoker prepares to call a specific Service API ID, and the Service API ID has a corresponding authorization instruction, the API Invoker should determine the AuF address for authorization based on the authorization instruction.
  • the API Invoker determines the AuF address for authorization based on the authorization instruction. For example, if the authorization instruction contains (1) an explicit instruction, then the API Invoker can request AuF to obtain the user's authorization based on the preconfigured AuF address; for another example, if the authorization instruction contains (2) the address of AuF, then the API Invoker According to the address of the AuF, request the AuF to obtain the user's authorization.
  • the API Invoker can determine which response type to use based on (3) authorization method in the authorization instruction. For example, if the authorization method is the authorization code mode of OAuth 2.0, the response type should be code, if the authorization method is OAuth2. Implicit mode of 0, the response type should be token, etc.
  • S506 The API caller sends the authorization request message #AA (that is, an example of the authorization request message) to AuF.
  • AuF receives the authorization request message #AA from the API caller.
  • the authorization request message #AA is used to request to obtain the user's authorization.
  • the authorization request message #AA includes user identification 1 (ie, an example of the identification of the target user).
  • the authorization request message #AA also includes Service API ID, and/or API Invoker ID.
  • the authorization request message #AA also includes response type and/or range indication information.
  • the response type is used to indicate the current authorization method, for example, code indicates the authorization code mode, and token indicates implicit.
  • the scope indication information is used to indicate the scope of authorization, which can include Service API ID and user ID 1.
  • the authorization request message #AA may be an OAuth2.0 Authorization Request message.
  • AuF determines whether the current API call requires user consent.
  • AuF can determine whether the current API requires user consent based on local configuration information.
  • the local configuration information can be an API list, and all APIs in the API list are APIs that require user consent.
  • the API Invoker requires user consent to call the current Service API, and the AuF does not have the UE context corresponding to user ID 1, or the UE context corresponding to user ID 1 does not save the user consent information of the UE.
  • AuF determines that it needs to authorize the RO client.
  • AuF determines that it needs to authorize the RO client.
  • AuF interacts with the RO client to obtain user consent information #AA.
  • AuF determines the authorization response message #AA.
  • the authorization response message #AA includes token2 with integrity protection (ie, an example of the first token ), the token2 includes user ID 1.
  • the authorization response message #AA includes failure indication information, and the failure indication information is used to indicate that the user is not authorized to use the API Invoker to call the Service API to operate the user. data.
  • the AEF sends the subscription information update request message #AA to the UDM.
  • UDM receives the subscription information update request message #AA from the AEF.
  • the subscription information update request message #AA is used to update the user consent information of the UE.
  • the subscription information update message #AA can include one or more of the following: user identification 2, data processing purpose, API Invoker ID, timeout time, User agrees with the results.
  • the user identification 2 is converted according to the user identification 1, which can be SUPI
  • the data processing purpose is converted according to the Server API ID
  • the user consent result can be obtained according to the user consent information #AA in step S508.
  • AuF updates the UE subscription information on UDM, which can reduce the number of times AuF requests RO authorization.
  • AuF sends the authorization response message #AA (that is, an example of the authorization response message) to the API caller.
  • #AA that is, an example of the authorization response message
  • the API caller receives the authorization response message #AA from AuF.
  • the authorization response message #AA includes token2 with integrity protection, and token2 includes user identification 1.
  • the API caller sends an access token request message #AA to AuF.
  • AuF receives the access token request message #AA from the API caller.
  • AuF sends the access token response message #AA to the API caller.
  • the API caller receives the access token response message #AA from AuF.
  • the access token response message #AA includes token2 with integrity protection, and token2 includes user identification 1.
  • S514 The API caller sends the API call request message #AA (that is, an example of the first API call request message) to the AEF.
  • #AA that is, an example of the first API call request message
  • AEF receives the API call request message #AA from the API caller.
  • the API call request message #AA includes user identification 1 (ie, an example of the target user), and token 2 with integrity protection. Among them, token2 includes user ID 1.
  • API call request message #AA includes one or more of the following: API Invoker ID, Service API ID, token1.
  • the token2 includes one or more of the following: timeout, API Invoker ID, Service API ID, signer.
  • the signer may not be placed in the declaration of token2, but placed in the API call request message #AA.
  • AEF also verifies token1 based on the API call request message #AA to determine that CCF authorizes the API Invoker to access the Service API (ie, the target API).
  • verification token1 please refer to step S218 (a) of Figure 2 above.
  • step S218 (a) of Figure 2 For the sake of brevity, no further details will be given here.
  • AEF will authorize the API Invoker to call the Service API to operate the user's personal data, that is, perform step S516. Otherwise, AEF will reject the API Invoker call request.
  • AEF sends API call response message #AA to the API caller.
  • the API caller receives the API call response message #AA from AEF.
  • the API call response message #AA is used to return the result of the API Invoker ID calling the target API to operate user data.
  • the authorization API Invoker ID has the permission to call the target API to operate user data.
  • API call request message #B such as Nnef_UEIdentifier_Get
  • the input user information is set to the IP address or domain name of a certain UE
  • the AF ID is set to the ID of the discussion server.
  • the AEF will return the API call response message #B, which contains the external identifier of the UE, such as GPSI.
  • the method disclosed in this application combines CCF to provide the API Invoker with token1 that needs to be authorized for the target API, and generates a more fine-grained token2 through AuF, so that the user consent information is taken into account in the authorization process, and AEF authorizes the API Invoker to access an API. And call a user's data.
  • This implementation requires user authorization when processing user data, protects users' private information, avoids user privacy exposure, and reduces potential security risks faced by network functions in mobile communication networks.
  • FIG. 6 is a flow example diagram of the communication method 600 provided by the embodiment of the present application.
  • CCF serves as an intermediate node to forward the message interaction between AuF and API Invoker, which can achieve more fine-grained authorization on the basis of reducing the interactive signaling between API Invoker and AuF, that is, Authorize API Invoker to access an API and process a user's data.
  • the method includes the following steps.
  • the API caller sends a registration request message #Aa or a discovery request message #Aa (that is, an example of the second request message) to the CCF.
  • CCF receives the registration request message #Aa from the API caller, or the discovery request message #Aa.
  • CCF sends a registration response message #Aa or a discovery response message #Aa (that is, an example of the second API call response message) to the API caller.
  • the API caller receives the registration response message #Aa from CCF, or the discovery response message #Aa.
  • the registration response message #Aa or the discovery response message #Aa includes an authorization indication.
  • the API caller determines to request AuF for authorization according to the authorization instruction.
  • the API Invoker needs to additionally request AuF for user authorization. Therefore, when the API Invoker prepares to call a specific Service API ID, and the Service API ID has a corresponding authorization instruction, the API Invoker should determine the AuF address for authorization based on the authorization instruction.
  • steps S601-S603 For the specific implementation of steps S601-S603, reference may be made to steps S501-S502 and step S505 in the above-mentioned method 500. For the sake of brevity, they will not be described again here.
  • the API caller sends the authorization request message #Aa (that is, an example of the second request message) to the CCF.
  • CCF receives the authorization request message #Aa from the API caller.
  • the authorization request message #Aa is used to request to obtain the user's authorization.
  • the authorization request message #Aa includes the Service API ID and the user ID 1.
  • the authorization request message #Aa also includes the API Invoker ID.
  • the authorization request message #Aa also includes response type and/or range indication information.
  • the response type is used to indicate the current authorization method, for example, code indicates the authorization code mode, and token indicates implicit.
  • the scope indication information is used to indicate the scope of authorization, which can include Service API ID and user ID 1.
  • the authorization request message #Aa may be an OAuth2.0 Authorization Request message.
  • CCF sends authorization request message #Aa to AuF.
  • AuF receives the authorization request message #Aa from CCF.
  • CCF can pre-configure the address of AuF in advance, such as the mapping relationship between API Service ID and AuF.
  • CCF can obtain the address of AuF based on the Service API ID, and then send the authorization request message #Aa to AuF based on the address of AuF.
  • AuF interacts with the RO client to obtain user consent information #Aa.
  • AuF determines the authorization response message #Aa.
  • the authorization response message #Aa includes a token with integrity protection (ie, an example of the first token ), the token includes user ID 1.
  • the authorization response message #Aa includes failure indication information, and the failure indication information is used to indicate that the user is not authorized to use the API Invoker to call the Service API to operate the user. data.
  • AuF sends authorization response message #Aa to CCF.
  • CCF receives the authorization response message #Aa from AuF.
  • the authorization response message #Aa includes token #1.
  • CCF sends the authorization response message #Aa (ie, an example of the authorization response message) to the API caller.
  • the API caller receives the authorization response message #Aa from CCF.
  • the authorization response message #Aa includes token 2 with integrity protection.
  • token #2 can be the same as token #1.
  • token #2 may be generated by CCF. After receiving token #1 in step S608, CCF determines to generate token #2.
  • token #2 includes claims and signature.
  • the signature can be the digital signature of the token by CCF.
  • the statement includes one or more of the following: timeout, API Invoker ID, service API ID, user ID 1.
  • the statement may also include one or more of the following: token generation time, token validity period, token validity expiration time, etc.
  • the statement may also include other parameters, such as resources allowed to be used, network slicing information, etc., which are not specifically limited in this application.
  • the CCF sends the subscription information update request message #Aa to the UDM.
  • UDM receives the subscription information update request message #Aa from the AEF.
  • the subscription information update request message #Aa is used to update the user consent information of the UE.
  • the subscription information update message #Aa can include one or more of the following: user identification 2, data processing purpose, API Invoker ID, timeout time, User agrees with the results.
  • user identification 2 is converted according to user identification 1, which can be SUPI
  • the data processing purpose is converted according to Server API ID
  • the user consent result can be obtained according to the user consent information #Aa in step S606.
  • the number of times AuF requests RO authorization can be reduced by updating the UE subscription information on UDM through CCF.
  • the API caller sends the API call request message #Aa (that is, an example of the first API call request message) to the AEF.
  • AEF receives the API call request message #Aa from the API caller.
  • the API call request message #Aa includes token #2 and user ID 1.
  • AEF may refer to step S460 to verify token#2.
  • AEF verification token#2 includes the following verification content:
  • AEF verifies the signature of token #2.
  • AEF verifies the signature of token #2 through the preconfigured CCF credentials (such as certificate).
  • AEF can determine whether the user ID 1 in the API call request message #Aa is consistent with the user ID 1 in the token.
  • AEF determines whether the API Invoker ID in the API call request message #Aa is consistent with the API Invoker ID in the token; or, AEF determines whether the Service API ID in the API call request message #Aa is consistent with the Service API ID in the token. Consistent; or, AEF determines whether the token is still valid based on the timeout period in the token compared with the current time, etc.
  • the token can usually be reused by API Invoekr within the validity period.
  • the statement may also include one or more of the following: token generation time, token validity period, token validity expiration time, etc.
  • the validity period of the token is 12h
  • the generation time of the token is 2:30
  • the time when AEF receives the API call request message #B is 12:30 then AEF will pass the verification of the signature and specific information content of the token.
  • the valid expiration time of the token is 12:30, and the time when AEF receives the API call request message #B is 12:00, then AEF can accept the API Invoker's request if the token's signature and specific information content are verified.
  • AEF sends API call response message #Aa to the API caller.
  • the API caller receives the API call response message #Aa from AEF.
  • the API call response message #Aa is used to return the result of the API Invoker ID calling the target API to operate user data.
  • the authorization API Invoker ID has the permission to call the target API to operate user data.
  • API call request message #Aa such as Nnef_UEIdentifier_Get
  • the input user information is set to the IP address or domain name of a certain UE
  • the AF ID is set to the ID of the discussion server.
  • the AEF will return the API call response message #Aa, which contains the external identifier of the UE, such as GPSI.
  • the method disclosed in this application is based on the token in (a) of Figure 2, and introduces CCF as an intermediate node to forward messages between API Invoker and AuF, which can achieve more detailed signaling on the basis of reducing the interactive signaling between API Invoker and AuF.
  • Granular authorization allows the user consent information to be considered during the authorization process to achieve the AEF authorization API Invoker to access a certain API and call a certain user's data.
  • using CCF instead of AuF to generate tokens can reduce the number of credentials configured by AEF without configuring AuF credentials. It can also reuse existing tokens without defining new tokens, thereby reducing the number of standard protocols. change.
  • This implementation requires user authorization when processing user data, protects users' private information, avoids user privacy exposure, and reduces potential security risks faced by network functions in mobile communication networks.
  • Figure 7 is a flow example diagram of the communication method 700 provided by the embodiment of the present application.
  • the difference from the above method 600 is that this implementation is only upgraded on AEF and AuF, and can achieve more fine-grained authorization without affecting the API Invoker, that is, authorizing the API Invoker to access an API and process a user The data.
  • the method includes the following steps.
  • the API caller sends the API call request message # ⁇ to AEF.
  • AEF receives the API call request message # ⁇ from the API caller.
  • the API call request message # ⁇ is used to request to call the Service API to operate the user's personal data, and the API call request message # ⁇ includes the identity of the API caller.
  • the API call request message # ⁇ also includes user identification 1 and/or Service API ID.
  • the API call request message # ⁇ itself carries the Service API ID.
  • the API call request message #A may include but is not limited to: locating Nnef_Location, obtaining Nnef_UEIdentifier_Get, subscribing to analysis Nnwdaf_AnalyticsSubscription_Subscribe and other messages.
  • AEF determines whether the current API call requires user consent, and generates an authorization request message # ⁇ .
  • AEF can determine whether the current API requires user consent based on local configuration information.
  • the local configuration information can be an API list, and all APIs in the API list are APIs that require user consent.
  • the API list can also correspond to the AuF address, that is, each API corresponds to an AuF address, and AEF can determine the AuF address corresponding to the Service API based on the API list.
  • the API Invoker requires user consent to call the current Service API, and the AEF does not have the UE context corresponding to user ID 1, or the UE context corresponding to user ID 1 does not save the user consent information of the UE.
  • AEF determines that user authorization needs to be provided to AuF.
  • AEF determines that user authorization needs to be performed to AuF.
  • the subscription information acquisition request message may be a Nudm_SDM_Get Request message
  • the subscription information acquisition response message may be a Nudm_SDM_Get Response message.
  • the AEF can directly perform step S791.
  • AEF sends the authorization request message # ⁇ to AuF.
  • AuF receives the authorization request message # ⁇ from AEF.
  • the authorization request message # ⁇ includes API Invoker ID, user ID 2, and service API ID.
  • the user identity 2 is obtained from the user identity 1.
  • the AEF can obtain the user identity 2 from other network elements through the user identity 1, so that the user identity 2 can be recognized by the AuF and determine the address of the RO, that is, steps S740-S760 are executed.
  • S740 optionally, perform authentication between AuF and RO clients.
  • this step can be omitted.
  • the specific authentication methods can refer to the authentication methods defined in existing standards. For the sake of simplicity, they will not be described again here.
  • AuF sends user consent request message # ⁇ to the RO client.
  • the RO client receives the user consent request message # ⁇ from AuF.
  • AuF sends a user consent request message # ⁇ to the RO.
  • the user consent request message # ⁇ may include Client ID, scope and other contents.
  • the RO client sends the user consent response message # ⁇ to the AuF.
  • AuF receives the user consent response message # ⁇ from the RO client.
  • the RO may return the user consent response message # ⁇ to AuF.
  • steps S750-S760 please refer to the steps S234-S235 in (c) of the above-mentioned Fig. 2; or, you can also refer to the steps S244-S245 in (d) of the above-mentioned Fig. 2. For the sake of brevity, no further details will be given here.
  • AuF sends the authorization response message # ⁇ to AEF.
  • AEF receives the authorization response message # ⁇ from AuF.
  • the authorization response message # ⁇ contains the authorization result, which is used to indicate whether the user agrees to the API Invoker calling the Service API to operate the user's personal data.
  • the authorization result is obtained by AuF based on the content of the user consent response message #a. For example, if the user clicks to agree, the authorization result is authorized; if the user clicks to disagree, the authorization result is not authorized.
  • the AEF sends the subscription information update request message # ⁇ to the UDM.
  • UDM receives the subscription information update request message # ⁇ from the AEF.
  • the AEF sends a subscription information update message # ⁇ to the UDM, and the subscription information update message # ⁇ is used to update the user consent information of the UE.
  • the contract information update message # ⁇ may contain one or more of the following: user identification 2, data processing purpose, API Invoker ID, timeout time, and user consent result.
  • user identification 2 is converted from the user identification 1 and can be SUPI; the data processing purpose is converted from the Server API ID; the user consent result is obtained according to step S760.
  • update through AEF The UE subscription information on UDM can reduce the number of times AuF requests RO authorization.
  • AEF determines whether to authorize based on the authorization result.
  • step S770 if the authorization result in step S770 indicates that the user has been authorized, the AEF may execute step S791. If the authorization result indicates that the user does not authorize, AEF can reject the API call request of the API Invoker.
  • AEF sends API call response message # ⁇ to the API caller.
  • the API caller receives the API call response message # ⁇ from AEF.
  • the API call response message # ⁇ is used to authorize the API Invoker ID to have the authority to call the target API to operate user data.
  • the authorization API Invoker ID has the permission to call the target API to operate user data.
  • API call request message #Aa such as Nnef_UEIdentifier_Get
  • the input user information is set to the IP address or domain name of a certain UE
  • the AF ID is set to the ID of the discussion server.
  • the AEF will return the API call response message #Aa, which contains the external identifier of the UE, such as GPSI.
  • the method disclosed in this application can achieve more fine-grained authorization without affecting the API Invoker, that is, authorizing the API Invoker to access a certain API and process a certain user's data, so that the user consent information is considered during the authorization process to achieve AEF authorizes API Invoker to access an API and call a user's data.
  • This implementation requires user authorization when processing user data, protects users' private information, avoids user privacy exposure, and reduces potential security risks faced by network functions in mobile communication networks.
  • the communication method embodiment of the present application is described in detail above with reference to FIGS. 1 to 7 .
  • the communication device side embodiment of the present application will be described in detail with reference to FIGS. 8 and 9 . It should be understood that the description of the device embodiments corresponds to the description of the method embodiments. Therefore, the parts not described in detail can be referred to the previous method embodiments.
  • FIG 8 is a schematic block diagram of a communication device provided by an embodiment of the present application.
  • the device 1200 may include a transceiver unit 1210 and a processing unit 1220.
  • the transceiver unit 1210 can communicate with the outside, and the processing unit 1220 is used for data processing.
  • the transceiver unit 1210 may also be called a communication interface or a transceiver unit.
  • the device 1200 can implement steps or processes corresponding to those performed by the API caller in the above method embodiment, wherein the processing unit 1220 is used to perform the processing of the API caller in the above method embodiment.
  • the transceiver unit 1210 is used to perform operations related to the API caller's transceiver in the above method embodiment.
  • the transceiver unit 1210 is configured to send an authorization request message to the authorization function network element, where the authorization request message includes the identity of the API caller;
  • the transceiver unit 1210 is also configured to receive an authorization response message from the authorization function network element.
  • the authorization response message includes a first token with integrity protection.
  • the first token is used to indicate that the API caller has the authority to access the target user's data.
  • the first token includes the identification of the target user;
  • the transceiver unit 1210 is also used to send a first API call request message to the API open function network element AEF.
  • the first API call request message is used to request to call the target API to operate the target user's data.
  • the first API call request message includes the target user. The id and first token.
  • the device 1200 can implement the steps or processes performed by the network element corresponding to the API opening function in the above method embodiment, wherein the transceiver unit 1210 is used to perform the API opening in the above method embodiment.
  • the processing unit 1220 is configured to perform operations related to the processing of the API open functional network element in the above method embodiment.
  • the transceiver unit 1210 is used to receive a first API call request message from the API caller.
  • the first API call request message is used to request to call the target API to operate the target user's data.
  • the first API call request message includes: The integrity-protected first token and the identity of the target user.
  • the first token is used to indicate that the API caller has the permission to access the target user's data.
  • the first token includes the identity of the target user;
  • the processing unit 1220 is configured to determine whether the API caller has the authority to operate the target user's data based on the first token;
  • the processing unit 1220 is also configured to determine whether to provide the API caller with permission to access the target user's data based on the determination result.
  • the device 1200 can implement steps or processes corresponding to those performed by the authorized function network element in the above method embodiment, wherein the transceiver unit 1210 is used to perform the authorized function network element in the above method embodiment.
  • the processing unit 1220 is configured to perform operations related to the processing of the authorized function network element in the above method embodiment.
  • the transceiver unit 1210 is configured to receive an authorization request message from the application software programming interface API caller, where the authorization request message includes the API caller's identity;
  • the processing unit 1220 is configured to authorize the function network when it is determined that the target user agrees to the API caller's operation of the target user's data. Generate a first token with integrity protection, the first token is used to indicate that the API caller has permission to access the target user's data, and the first token includes the identification of the target user;
  • the transceiver unit 1210 is also configured to send an authorization response message to the API caller, where the authorization response message includes the first token.
  • the device 1200 can implement steps or processes corresponding to the CCF execution in the above method embodiment, wherein the transceiver unit 1210 is used to perform operations related to the transmission and reception of CCF in the above method embodiment.
  • the processing unit 1220 is configured to perform operations related to CCF processing in the above method embodiment.
  • the transceiver unit 1210 is used to receive a second request message from the API caller.
  • the second request message is used to request to call the target API to operate the target user's data.
  • the second request message includes the target user's identity and the target API.
  • the identification; the transceiver unit 1210 is also used to send authorization instructions to the API caller.
  • the device 1200 here is embodied in the form of a functional unit.
  • the term "unit” as used herein may refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (such as a shared processor, a proprietary processor, or a group of processors) used to execute one or more software or firmware programs. processor, etc.) and memory, merged logic circuitry, and/or other suitable components to support the described functionality.
  • ASIC application specific integrated circuit
  • processor such as a shared processor, a proprietary processor, or a group of processors
  • memory merged logic circuitry, and/or other suitable components to support the described functionality.
  • the device 1200 can be specifically the sending end in the above embodiment, and can be used to perform various processes and/or steps corresponding to the sending end in the above method embodiment, or, The device 1200 may be specifically a receiving end in the above embodiments, and may be used to perform various processes and/or steps corresponding to the receiving end in the above method embodiments. To avoid duplication, they will not be described again here.
  • the device 1200 of each of the above solutions has the function of realizing the corresponding steps performed by the sending end in the above method, or the device 1200 of each of the above solutions has the function of realizing the corresponding steps of the receiving end of the above method.
  • the functions described can be implemented by hardware, or can be implemented by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above functions; for example, the transceiver unit can be replaced by a transceiver (for example, the sending unit in the transceiver unit can be replaced by a transmitter, and the receiving unit in the transceiver unit can be replaced by a receiving unit. (machine replacement), other units, such as processing units, etc., can be replaced by processors to respectively perform the sending and receiving operations and related processing operations in each method embodiment.
  • the above-mentioned transceiver unit may also be a transceiver circuit (for example, it may include a receiving circuit and a transmitting circuit), and the processing unit may be a processing circuit.
  • the device in Figure 8 can be the receiving end or the transmitting end in the aforementioned embodiment, or it can be a chip or a chip system, such as a system on chip (SoC).
  • SoC system on chip
  • the transceiver unit may be an input-output circuit or a communication interface.
  • the processing unit is a processor or microprocessor or integrated circuit integrated on the chip. No limitation is made here.
  • Figure 9 shows a communication device 2000 provided by an embodiment of the present application.
  • the device 2000 includes a processor 2010 and a transceiver 2020.
  • the processor 2010 and the transceiver 2020 communicate with each other through an internal connection path, and the processor 2010 is used to execute instructions to control the transceiver 2020 to send signals and/or receive signals.
  • the device 2000 may also include a memory 2030, which communicates with the processor 2010 and the transceiver 2020 through internal connection paths.
  • the memory 2030 is used to store instructions, and the processor 2010 can execute the instructions stored in the memory 2030.
  • the device 2000 is used to implement various processes and steps corresponding to the API caller in the above method embodiment.
  • the transceiver 2020 is configured to send an authorization request message to the authorization function network element, where the authorization request message includes the identity of the API caller;
  • the transceiver 2020 is also used to receive an authorization response message from the authorization function network element.
  • the authorization response message includes a first token with integrity protection.
  • the first token is used to indicate that the API caller has the authority to access the target user's data.
  • the first token includes the identification of the target user;
  • the transceiver 2020 is also used to send a first API call request message to the API open function network element AEF.
  • the first API call request message is used to request to call the target API to operate the target user's data.
  • the first API call request message includes the target user. The id and first token.
  • the device 2000 is used to implement various processes and steps corresponding to the authorization function network element in the above method embodiment.
  • the transceiver 2020 is configured to receive an authorization request message from the application software programming interface API caller, where the authorization request message includes the identity of the API caller;
  • Processor 2010, configured to authorize the functional network element when it is determined that the target user agrees to the API caller's operation of the target user's data.
  • Generate a first token with integrity protection the first token is used to indicate that the API caller has permission to access the target user's data, and the first token includes the identification of the target user;
  • the transceiver 2020 is also used to send an authorization response message to the API caller, where the authorization response message includes the first token.
  • the device 2000 is used to implement various processes and steps corresponding to the AEF in the above method embodiment.
  • the transceiver 2020 is used to receive a first API call request message from the API caller.
  • the first API call request message is used to request to call the target API to operate the target user's data.
  • the first API call request message includes: The integrity-protected first token and the identity of the target user.
  • the first token is used to indicate that the API caller has the permission to access the target user's data.
  • the first token includes the identity of the target user;
  • Processor 2010, configured to determine whether the API caller has the authority to operate the target user's data based on the first token
  • the processor 2010 is also configured to determine whether to provide the API caller with permission to access the target user's data based on the determination result.
  • the device 2000 is used to implement various processes and steps corresponding to the CCF in the above method embodiment.
  • the transceiver 2020 is used to receive a second request message from the API caller.
  • the second request message is used to request to call the target API to operate the target user's data.
  • the second request message includes the identification of the target user and the target API. logo;
  • Transceiver 2020 also used to send authorization instructions to API callers.
  • the device 2000 may be specifically the sending end or the receiving end in the above embodiment, or may be a chip or a chip system.
  • the transceiver 2020 may be the transceiver circuit of the chip, which is not limited here.
  • the device 2000 can be used to perform various steps and/or processes corresponding to the sending end or the receiving end in the above method embodiments.
  • the memory 2030 may include read-only memory and random access memory and provide instructions and data to the processor.
  • a portion of the memory may also include non-volatile random access memory.
  • the memory may also store device type information.
  • the processor 2010 can be used to execute instructions stored in the memory, and when the processor 2010 executes the instructions stored in the memory, the processor 2010 is used to execute various steps of the above method embodiment corresponding to the sending end or the receiving end. and/or process.
  • each step of the above method can be completed by instructions in the form of hardware integrated logic circuits or software in the processor.
  • the steps of the methods disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware processor for execution, or can be executed by a combination of hardware and software modules in the processor.
  • the software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field.
  • the storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.
  • the processor in the embodiment of the present application may be an integrated circuit chip with signal processing capabilities. During the implementation process, each step of the above method embodiment can be completed through an integrated logic circuit of hardware in the processor or instructions in the form of software.
  • the above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
  • DSP digital signal processor
  • ASIC application-specific integrated circuit
  • FPGA field programmable gate array
  • the processor in the embodiment of the present application can implement or execute the various methods, steps and logical block diagrams disclosed in the embodiment of the present application.
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.
  • the steps of the method disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field.
  • the storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
  • the memory in the embodiment of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories.
  • the non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically removable memory. Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
  • Volatile memory may be random access memory (RAM), which is used as an external cache.
  • RAM static random access memory
  • DRAM dynamic random access memory
  • SDRAM synchronous dynamic random access memory
  • double data rate SDRAM double data rate SDRAM
  • DDR SDRAM double data rate SDRAM
  • ESDRAM enhanced synchronous dynamic random access memory
  • SLDRAM synchronous link dynamic random access memory
  • direct memory bus random access memory direct rambus RAM, DR RAM
  • the present application also provides a computer program product.
  • the computer program product includes: computer program code.
  • the computer program code When the computer program code is run on a computer, it causes the computer to execute the above embodiments. Methods.
  • the present application also provides a computer-readable medium.
  • the computer-readable medium stores program code.
  • the program code When the program code is run on a computer, it causes the computer to execute the above-described embodiments. Methods.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.
  • the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of the present application is essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product.
  • the computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk and other media that can store program code. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请实施例提供了一种通信方法和通信装置。该方法包括：API调用者向授权功能网元发送授权请求消息，API调用者接收来自授权功能网元的具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；API调用者向API开放功能网元AEF发送第一API调用请求消息，用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。本申请所揭示的方法，能够避免用户隐私暴露，减少网络功能面临的潜在的安全风险。

Description

通信方法和通信装置
本申请要求于2022年08月12日提交国家知识产权局、申请号为202210972025.2、申请名称为“通信方法和通信装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，并且更具体地，涉及一种通信方法和通信装置。
背景技术
当前，在第三代合作伙伴项目(3rd generation partnership project，3GPP)标准能力放开架构中，提供了一种3GPP对外提供服务的方法。例如，应用功能(application function，AF)网元可以请求3GPP网络对一些信息进行处理，这些信息可以是属于网络的数据，也可以是属于用户的数据。例如，AF可以请求3GPP对外发送用户的位置信息。然而，在这个过程中，用户的隐私信息可能被非法暴露。
发明内容
本申请提供一种通信方法和通信装置，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
第一方面，提供了一种通信方法，该方法可以由应用软件编程接口(application programming interface，API)调用者执行，或者，也可以由用于API调用者的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由API调用者执行为例进行说明。
该方法包括：应用软件编程接口API调用者(API Invoker)向授权功能网元(例如，(authorization function，AuF))发送授权请求消息，授权请求消息包括目标用户的标识；API调用者接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；API调用者向API开放功能网元(API exposing function，AEF)发送第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。
根据本申请提供的方案，API Invoker可以主动从AuF获得更细粒度的用户授权的token，并使用该token接入AEF，从而使可以AEF授权API Invoker访问某个API并处理某个用户的数据。本申请所揭示的方法，在对用户数据进行处理时引入用户是否授权的考量，能够避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
结合第一方面，在第一方面的某些实现方式中，在API调用者向授权功能网元发送授权请求消息之前，API调用者向AEF发送第二API调用请求消息，第二API调用请求消息用于请求调用目标API以操作目标用户的数据，第二API调用请求消息包括目标用户的标识；API调用者接收来自AEF的授权指示；其中，API调用者向授权功能网元发送授权请求消息，包括：API调用者根据授权指示，向授权功能网元发送授权请求消息。
基于上述方案，AEF向API Invoker提供授权指示，使得API调用者确定请求调用目标API以操作目标用户的数据需要用户的授权，进而基于接收到的授权指示向授权功能网元发起授权请求。在API调用流程中引入目标用户的授权，能够避免用户隐私信息的暴露，减少通信网络中潜在的安全风险。
结合第一方面，在第一方面的某些实现方式中，授权指示包括授权功能网元的地址；其中，API调用者接收来自AEF的授权指示，包括：API调用者接收来自AEF的第二API调用响应消息，第二API调用响应消息包括授权指示。
基于上述方案，API调用者可以通过授权指示中携带的授权功能网元的地址，向授权功能网元发送授权请求消息。
结合第一方面，在第一方面的某些实现方式中，在API调用者向授权功能网元发送授权请求消息 之前，API调用者向通用API框架核心功能网元(common API framework core function，CCF)发送第二请求消息，第二请求消息用于请求用于将API调用者注册到CCF，或者用于API调用者发现目标API；API调用者接收来自CCF的授权指示；其中，API调用者向授权功能网元发送授权请求消息，包括：API调用者根据授权指示，向授权功能网元发送授权请求消息。
基于上述方案，CCF向API Invoker提供授权指示，使得API调用者确定请求调用目标API以操作目标用户的数据需要用户的授权，进而基于接收到的授权指示向授权功能网元发起授权请求。在API调用流程中引入目标用户的授权，能够避免用户隐私信息的暴露，减少通信网络中潜在的安全风险。
结合第一方面，在第一方面的某些实现方式中，授权指示包括授权功能网元的地址；其中，API调用者接收来自CCF的授权指示，包括：API调用者接收来自CCF的第二API调用响应消息，第二API调用响应消息包括授权指示。
应理解，这里来自CCF的第二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调用者向AEF发送第一API调用请求消息之前，API调用者向通用API框架核心功能网元CCF发送第一请求消息，第一请求消息用于请求获取调用目标API的权限，第一请求消息包括API调用者的标识和目标API的标识；API调用者接收来自CCF的第二令牌。
基于上述方案，API调用者可以在请求调用目标API以操作目标用户的数据时，携带第一令牌和第二令牌，即实现API调用者可以被授权具有调用(或者访问)目标API的权限，同时可以被授权具有调用目标API以操作目标用户的数据的权限，能够确保此次API调用流程的完整性和安全性，对于 保护用户的隐私安全提供了双层保障，减少潜在的通信风险。
结合第一方面，在第一方面的某些实现方式中，第一令牌包括还包括以下一项或者多项：超时时间；API调用者的标识；目标API的标识；签名者。
基于上述方案，通过在第一令牌中提供更多的声明信息，能够进一步确保此次API调用的安全性，为保护用户隐私信息不被泄露提供多层保障，有利于降低网络通信的风险。
结合第一方面，在第一方面的某些实现方式中，授权请求消息还包括：目标API的标识；和/或目标用户的标识。
基于上述方案，通过在授权请求消息中携带目标API的标识；和/或目标用户的标识，使得API调用者的调用请求更有针对性，便于后续授权功能网元生成的第一令牌中具有更多的声明内容信息，有利于在API调用流程中为目标用户提供更安全的保护措施，避免用户个人数据被泄露等风险的存在。
第二方面，提供了一种通信方法，该方法可以由API开放功能网元AEF执行，或者，也可以由用于API开放功能网元的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由API开放功能网元执行为例进行说明。
该方法包括：AEF接收来自API调用者的第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括具有完整性保护的第一令牌和目标用户的标识，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限；根据确定结果，AEF确定是否向API调用者提供访问目标用户的数据的权限。
根据本申请提供的方案，在API调用流程中，AEF通过验证更细粒度的、用于用户授权的第一令牌，可以确定API调用者是否具有操作目标用户的数据的权限；并且进一步地，AEF可以根据确定结果确定是否向API调用者提供访问目标用户的数据的权限。基于AEF对于API调用请求的多层验证，能够避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
结合第二方面，在第二方面的某些实现方式中，AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限，包括：AEF根据授权功能网元的凭证，对第一令牌的完整性保护进行验证，授权功能网元为生成第一令牌的网元；在第一令牌的完整性保护验证通过的情况下，AEF判断第一令牌中携带的目标用户的标识，是否与第一API调用请求消息中携带的目标用户的标识相同。
基于上述方案，AEF首先通过授权功能网元的凭证可以实现对第一令牌的完整性保护的验证。进一步地，AEF再判断第一令牌中携带的目标用户的标识，是否与第一API调用请求消息中携带的目标用户的标识相同。通过双重验证来确保第一令牌的真实性和准确性，进而为后续接受API调用者所请求的操作目标用户的数据提供安全保障，避免对用户的隐私造成泄露，以及增加潜在的风险。
结合第二方面，在第二方面的某些实现方式中，第一令牌还包括签名者；其中，在AEF根据授权功能网元的凭证，对第一令牌进行完整性验证之前，方法还包括：AEF根据签名者，获取授权功能网元的凭证。
基于上述方案，通过对第一令牌签名，能够确定该用户授权的真实性和可靠性，便于后续AEF验证第一令牌是确定该用户同意授权操作目标用户的个人数据这一信息是否真实有效，避免中途被其他网元恶意篡改造成对目标用户的侵害，以及产生潜在的风险。
结合第二方面，在第二方面的某些实现方式中，第一令牌还包括API调用者的标识，第一API调用请求消息还包括API调用者的标识，AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限，还包括：AEF判断第一令牌中携带的API调用者的标识，是否与第一API调用请求消息中携带的API调用者的标识相同。
基于上述方案，分别在第一令牌以及第一API调用请求消息中携带API调用者的标识，AEF通过判断两个API调用者的标识是否相同，进而可以确认该第一令牌是否有效，防止第一令牌中途被恶意篡改，降低目标用户的个人信息被泄露的风险。
结合第二方面，在第二方面的某些实现方式中，第一令牌还包括目标API的标识，第一API调用请求消息还包括目标API的标识，AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限，还包括：AEF判断第一令牌中携带的目标API的标识，是否与第一API调用请求消息中携带的目标API的标识相同。
基于上述方案，分别在第一令牌以及第一API调用请求消息中携带目标API的标识，AEF通过判断两个目标API的标识是否相同，进而可以确认该第一令牌是否有效，防止第一令牌中途被恶意篡改，降低目标用户的个人信息被泄露的风险。同时，通过验证目标API的标识还可以进一步确定是否授权API调用者具有调用目标API的权限。
结合第二方面，在第二方面的某些实现方式中，第一API调用请求消息还包括第二令牌；其中，在确定API调用者是否具有操作目标用户的数据的权限之前，AEF根据第二令牌，确定API调用者具有调用目标API的权限。
基于上述方案，通过在第一API调用请求消息中携带第二令牌，并在验证第二令牌通过的情况下确定API调用者具有调用目标API的权限。该实现方式对于API调用者的调用请求提供多层验证，确保API调用请求操作的用户数据的安全可靠性。
结合第二方面，在第二方面的某些实现方式中，第二令牌还包括目标API的标识，第一API调用请求消息还包括目标API的标识；其中，AEF根据第二令牌，确定API调用者具有调用目标API的权限，包括：AEF确定第二令牌中携带的目标API的标识，与第一API调用请求消息中携带的目标API的标识相同。
基于上述方案，AEF通过判断第二令牌，以及第一API调用请求消息中携带的两个A目标API的标识是否相同，进而可以确认该API调用者是否可以被授权调用目标API。基于该实现方式加入对第二令牌的验证，能够降低目标用户的个人信息被泄露的风险，提供API调用流程的双重保险，安全性更高。
结合第二方面，在第二方面的某些实现方式中，在AEF接收来自API调用者的第一API调用请求消息之前，AEF接收来自API调用者的第二API调用请求消息，第二API调用请求消息用于请求调用目标API以操作目标用户的数据，第二API调用请求消息包括目标用户的标识；AEF向API调用者发送授权指示，授权指示用于指示请求操作目标用户的数据需要目标用户的授权。
基于上述方案，AEF向API Invoker提供授权指示，使得API调用者确定请求调用目标API以操作目标用户的数据需要用户的授权，进而基于接收到的授权指示向授权功能网元发起授权请求。在API调用流程中引入目标用户的授权，能够避免用户隐私信息的暴露，减少通信网络中潜在的安全风险。
结合第二方面，在第二方面的某些实现方式中，授权指示包括授权功能网元的地址；其中，AEF向API调用者发送授权指示，包括：AEF向API调用者发送第二API调用响应消息，第二API调用响应消息包括授权指示。
基于上述方案，API调用者可以通过授权指示中携带的授权功能网元的地址，向授权功能网元发送授权请求消息。
结合第二方面，在第二方面的某些实现方式中，第二API调用响应消息为重定向请求消息。
基于上述方案，API调用者在接收到重定向请求消息后，根据重定向请求消息中携带的授权指示，确定授权功能网元的地址，进而向授权功能网元发送授权请求消息，该实现方式中API调用者可以不清楚授权指示信息的具体含义。
结合第二方面，在第二方面的某些实现方式中，授权指示包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。
基于上述方案，API调用者通过授权指示中携带的原因值以及授权功能网元的地址，可以确定需要向授权功能网元获取目标用户的授权，进而向授权功能网元发送授权请求消息，该实现方式中API调用者是清楚授权指示信息的具体含义的，使得API调用者更有针对性地请求获取用户的授权。
结合第二方面，在第二方面的某些实现方式中，在AEF向API调用者发送授权指示之前，AEF确定请求操作目标用户的数据需要目标用户的授权。
基于上述方案，AEF在确定请求操作目标用户的数据需要目标用户的授权的情况下，向API调用者发送授权指示，用于指示请求操作目标用户的数据需要目标用户的授权。
结合第二方面，在第二方面的某些实现方式中，AEF确定请求操作目标用户的数据需要目标用户的授权，包括：AEF向统一数据管理功能网元UDM发送获取请求消息，获取请求消息用于请求获取目标用户的用户同意信息；AEF接收来自UDM的响应消息；AEF根据响应消息，确定请求操作目标用户的数据需要目标用户的授权。
基于上述方案，AEF基于UDM的响应消息可以确定请求操作目标用户的数据需要目标用户的授权，进而向API调用者发送授权指示，用于向授权功能网元进行用户的授权。
结合第二方面，在第二方面的某些实现方式中，在AEF向UDM发送获取请求消息之前，AEF确定AEF没有保存有目标用户的用户同意信息，用户同意信息指示目标用户同意操作目标用户的数据。
基于上述方案，AEF在确保本地未存储有目标用户的用户同意信息的情况下，再向UDM请求获取目标用户的用户同意信息，能够避免造成不必要的信令开销，减少交互次数。
结合第二方面，在第二方面的某些实现方式中，AEF向通用API框架核心功能网元CCF发送第三请求消息，第三请求消息用于请求获取API调用者调用目标API的访问策略，第三请求消息包括API调用者的标识和目标API的标识；其中，根据确定结果，AEF确定是否向API调用者提供访问目标用户的数据的权限，包括：在API调用者具有操作目标用户的数据的权限，且访问策略指示允许API调用者调用目标API的情况下，AEF向API调用者提供访问目标用户的数据的权限。
需要说明的是，上述AEF向CCF发送第三请求消息，请求获取API调用者调用目标API的访问策略，以及上述API调用者向CCF发送第一请求消息，请求获取访问目标API的第二令牌，这两种实现方式是并列方案。当然，本申请也不排除API调用者向CCF请求获取第二令牌后，向AEF发送第一API调用请求消息，AEF在判断API是否具有访问目标API的权限的时候，再次向CCF请求获取API调用者调用目标API的访问策略，通过访问策略以及第二令牌双重验证，能够保证API调用流程的更安全性。
基于上述方案，AEF可以向CCF请求获取访问目标API的访问策略，进而确定是否允许API调用者调用目标API。同时，基于API调用者具有操作目标用户的数据的权限的情况下，AEF可以确定是否向API调用者提供访问目标用户的数据的权限。通过考虑目标API的调用权限，以及操作目标用户的数据的权限，能够保证API调用者的调用请求的可靠性，保障目标用户的数据的安全性，降低目标用户的个人数据在通信网络中的潜在风险。
结合第二方面，在第二方面的某些实现方式中，在API调用者具有操作目标用户的数据的权限的情况下，AEF向统一数据管理功能UDM发送签约信息更新消息，签约信息更新消息用于更新目标用户的用户同意信息，用户同意信息用于指示目标用户同意操作目标用户的数据。
基于上述方案，在API调用者具有操作目标用户的数据的权限的情况下，AEF可以更新UDM上的签约信息，以减少AuF请求RO授权的次数，在保障目标用户的个人数据的安全性的基础上，减少信令开销。
第三方面，提供了一种通信方法，该方法可以由授权功能网元(authorization function，AuF)执行，或者，也可以由用于AuF的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由AuF执行为例进行说明。
该方法包括：授权功能网元接收来自应用软件编程接口API调用者的授权请求消息，授权请求消息包括目标用户的标识；在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元生成具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；授权功能网元向API调用者发送授权响应消息，授权响应消息包括第一令牌。
根据本申请提供的方案，授权功能网元在确定目标用户同意API调用者操作目标用户的数据的情况下，向API Invoker提供更细粒度的用户授权的token，便于后续使用该token接入AEF，从而使可以AEF授权API Invoker访问某个API并处理某个用户的数据。本申请所揭示的方法，在对用户数据进行处理时引入用户是否授权的考量，能够避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
结合第三方面，在第三方面的某些实现方式中，授权请求消息还包括目标API的标识和目标用户的标识，授权功能网元生成具有完整性保护的第一令牌，包括：授权功能网元根据API调用者的标识、目标API的标识和目标用户的标识生成声明；授权功能网元根据声明生成签名；授权功能网元根据声明和签名生成具有完整性保护的第一令牌。
基于上述方案，授权功能网元基于授权请求消息中携带的API调用者的标识、目标API的标识和目标用户的标识，以及在用户同意授权操作目标用户的数据的情况下，生成第一令牌，确保第一令牌 的完整性、真实性以及有针对性，能够降低后续操作用户的个人数据造成对用户隐私信息的暴露风险。
结合第三方面，在第三方面的某些实现方式中，第一令牌包括还包括以下一项或者多项：超时时间；API调用者的标识；目标API的标识；签名者。
基于上述方案，通过在第一令牌中提供更多的声明信息，能够进一步确保此次API调用的安全性，为保护用户隐私信息不被泄露提供多层保障，有利于降低网络通信的风险。
结合第三方面，在第三方面的某些实现方式中，授权请求消息还包括：目标API的标识；和/或目标用户的标识。
基于上述方案，通过在授权请求消息中携带目标API的标识；和/或目标用户的标识，使得API调用者的调用请求更有针对性，便于后续授权功能网元生成的第一令牌中具有更多的声明内容信息，有利于在API调用流程中为目标用户提供更安全的保护措施，避免用户个人数据被泄露等风险的存在。
第四方面，提供了一种通信方法，该方法可以由通用API框架核心功能网元(Common API Framework Core Function，CCF)执行，或者，也可以由用于CAPIF核心功能网元的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由CAPIF核心功能网元执行为例进行说明。
该方法包括：通用应用软件编程接口API框架核心功能网元CCF接收来自API调用者的第二请求消息，第二请求消息用于请求用于将API调用者注册到CCF，或者用于API调用者发现目标API；CCF向API调用者发送授权指示。
根据本申请提供的方案，CCF向API Invoker提供授权指示，使得API调用者确定请求调用目标API以操作目标用户的数据需要用户的授权，进而基于接收到的授权指示向授权功能网元发起授权请求。在API调用流程中引入目标用户的授权，能够避免用户隐私信息的暴露，减少通信网络中潜在的安全风险。
结合第四方面，在第四方面的某些实现方式中，授权指示包括授权功能网元的地址；其中，CCF向API调用者发送授权指示，包括：CCF向API调用者第二响应消息，第二响应消息包括授权指示。
基于上述方案，API调用者可以通过授权指示中携带的授权功能网元的地址，向授权功能网元发送授权请求消息。
结合第四方面，在第四方面的某些实现方式中，第二响应消息为重定向请求消息。
基于上述方案，API调用者在接收到重定向请求消息后，根据重定向请求消息中携带的授权指示，确定授权功能网元的地址，进而向授权功能网元发送授权请求消息，该实现方式中API调用者可以不清楚授权指示信息的具体含义。
结合第四方面，在第四方面的某些实现方式中，授权指示还包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。
基于上述方案，API调用者通过授权指示中携带的原因值以及授权功能网元的地址，可以确定需要向授权功能网元获取目标用户的授权，进而向授权功能网元发送授权请求消息，该实现方式中API调用者是清楚授权指示信息的具体含义的，使得API调用者更有针对性地请求获取用户的授权。
结合第四方面，在第四方面的某些实现方式中，CCF接收来自API调用者的授权请求消息，授权请求消息包括API调用者的标识、目标API的标识以及目标用户的标识；CCF向授权功能网元发送授权请求消息；CCF接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；CCF向API调用者发送授权响应消息。
基于上述方案，CCF作为中间节点，转发AuF与API Invoker之间的消息，可以在减少API Invoker与AuF交互信令的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。
结合第四方面，在第四方面的某些实现方式中，在CCF向授权功能网元发送授权请求消息之前，CCF根据预配置的地址列表，确定授权功能网元的地址；CCF根据授权功能网元的地址，向授权功能网元发送授权请求消息。
基于上述方案，CCF在确定请求操作目标用户的数据需要目标用户的授权的情况下，可以找到目标API对应的授权功能网元的地址，并向授权功能网元发送授权请求消息。
结合第四方面，在第四方面的某些实现方式中，CCF接收来自API调用者的第一请求消息，第一 请求消息用于请求获取调用目标API的权限，第一请求消息包括API调用者的标识和目标API的标识；CCF向API调用者发送第二令牌，第二令牌用于指示API调用者具有调用目标API的权限，第二令牌包括API调用者的标识和目标API的标识。
基于上述方案，CCF通过向API调用者下发第二令牌，指示API调用者具有调用目标API的权限。进一步地，便于后续API调用者在请求调用目标API以操作目标用户的数据时，携带第一令牌和第二令牌，即实现API调用者可以被授权具有调用(或者访问)目标API的权限，同时可以被授权具有调用目标API以操作目标用户的数据的权限，对于保护用户的隐私安全提供了双层保障，减少潜在的通信风险。
结合第四方面，在第四方面的某些实现方式中，CCF接收来自AEF的第三请求消息，第三请求消息用于请求获取API调用者调用目标API的访问策略，访问策略用于指示是否允许API调用者调用目标API，第三请求消息包括API调用者的标识和目标API的标识；CCF向AEF发送访问策略。
基于上述方案，CCF可以向AEF发送访问目标API的访问策略，指示是否允许API调用者调用目标API。通过考虑目标API的调用权限，以及操作目标用户的数据的权限，能够保证API调用请求的可靠性，保障目标用户的数据的安全性，降低目标用户的个人数据在通信网络中的潜在风险。
第五方面，提供了一种通信方法，该方法可以由授权功能网元执行，或者，也可以由用于授权功能网元的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由授权功能网元执行为例进行说明。
该方法包括：授权功能网元接收来自应用软件编程接口API开放功能网元AEF的授权请求消息，授权请求消息包括API调用者的标识和目标用户标识；在确定目标用户授权API调用者操作目标用户的数据的情况下，授权功能网元向AEF发送获取授权响应消息，获取授权响应消息包括授权结果，授权结果用于指示目标用户是否授权API调用者操作目标用户的数据。
根据本申请提供的方案，在API调用流程中，可以在不影响API Invoker的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。授权功能网元通过向AEF发送授权结果，用于AEF确定API调用者是否具有操作目标用户的数据的权限，避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
第六方面，提供了一种通信方法，该方法可以由API开放功能网元(API exposing function，AEF)执行，或者，也可以由用于API开放功能网元的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由API开放功能网元执行为例进行说明。
该方法包括：应用软件编程接口API开放功能网元AEF向授权功能网元发送授权请求消息，授权请求消息包括API调用者的标识和目标用户的标识；AEF接收来自授权功能网元的授权响应消息，授权响应消息包括授权结果，授权结果用于指示目标用户是否授权API调用者操作目标用户的数据。
根据本申请提供的方案，在API调用流程中，可以在不影响API Invoker的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。AEF通过接收来自授权功能网元的授权结果，可以确定API调用者是否具有操作目标用户的数据的权限，避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
结合第六方面，在第六方面的某些实现方式中，在AEF向API调用者发送授权指示之前，AEF确定请求操作目标用户的数据需要目标用户的授权。
示例性的，AEF可以根据本地配置的API列表确定目标API的调用需要目标用户的授权。可选地，API列表可以是AEF预配置的，也可以是其他网元为AEF配置的，本申请对此不作具体限定。
可选地，API列表还可以对应授权功能网元的地址，即AEF根据目标API获得授权功能网元的地址。
基于上述方案，AEF在确定请求操作目标用户的数据需要目标用户的授权的情况下，向API调用者发送授权指示，用于指示请求操作目标用户的数据需要目标用户的授权。
结合第六方面，在第六方面的某些实现方式中，AEF确定请求操作目标用户的数据需要目标用户的授权，包括：AEF向统一数据管理功能网元UDM发送获取请求消息，获取请求消息用于请求获取目标用户的用户同意信息；AEF接收来自UDM的响应消息；AEF根据响应消息，确定请求操作目标用户的数据需要目标用户的授权。
可选地，该响应消息可以用于指示UDM未保存有目标用户的用户同意信息，或者可以用于指示请求操作目标用户的数据需要该目标用户的授权等。
基于上述方案，AEF基于UDM的响应消息可以确定请求操作目标用户的数据需要目标用户的授权，进而向API调用者发送授权指示，用于向授权功能网元进行用户的授权。
结合第六方面，在第六方面的某些实现方式中，在AEF向UDM发送获取请求消息之前，AEF确定AEF没有保存有目标用户的用户同意信息，用户同意信息指示目标用户同意操作目标用户的数据。
需要说明的是，AEF没有保存有目标用户的用户同意信息，可以理解为AEF本地未存储目标用户的UE上下文，也可以理解为本地存储的目标用户的UE上下文中未保存目标用户的用户同意信息。
基于上述方案，AEF在确保本地未存储有目标用户的用户同意信息的情况下，再向UDM请求获取目标用户的用户同意信息，能够避免造成不必要的信令开销，减少交互次数。
结合第六方面，在第六方面的某些实现方式中，AEF向授权功能网元发送授权请求消息，包括：AEF根据预配置的地址列表，确定授权功能网元的地址；AEF根据授权功能网元的地址，向授权功能网元发送授权请求消息。
基于上述方案，AEF根据地址列表可以找到目标API对应的授权功能网元的地址，并向授权功能网元发送授权请求消息。
结合第六方面，在第六方面的某些实现方式中，在API调用者具有操作目标用户的数据的权限的情况下，AEF向统一数据管理功能UDM发送签约信息更新消息，签约信息更新消息用于更新目标用户的用户同意信息，用户同意信息用于指示目标用户同意操作目标用户的数据。
示例性的，签约信息更新消息包括以下一项或者多项：目标用户的标识；数据处理目的，数据处理目的是根据API得到的；API调用者的标识；超时时间；用户同意结果。
基于上述方案，在API调用者具有操作目标用户的数据的权限的情况下，AEF可以更新UDM上的签约信息以减少AuF请求RO授权的次数，在授权API Invoker访问某个API并处理某个用户的数据的情况下，保障用户数据的安全性的同时可以减少信令开销。
第七方面，提供了一种API调用者。该网元包括：处理网元，用于生成授权请求消息；收发单元，用于向授权功能网元发送授权请求消息，授权请求消息包括API调用者的标识；收发单元，还用于接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；收发单元，还用于向API开放功能网元AEF发送第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。
该收发单元可以执行前述第一方面中的接收和发送的处理，处理单元可以执行前述第一方面中除了接收和发送之外的其他处理。
第八方面，提供了一种API开放功能网元AEF。该网元包括：收发单元，用于接收来自API调用者的第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括具有完整性保护的第一令牌和目标用户的标识，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；处理单元，用于根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限；处理单元，还用于根据确定结果，AEF确定是否向API调用者提供访问目标用户的数据的权限。
该收发单元可以执行前述第二面或第六方面中的接收和发送的处理，处理单元可以执行前述第二方面或第六方面中除了接收和发送之外的其他处理。
第九方面，提供了一种授权功能网元。该网元包括：收发单元，用于接收来自应用软件编程接口API调用者的授权请求消息，授权请求消息包括API调用者的标识；处理单元，用于在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元生成具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；收发单元，还用于向API调用者发送授权响应消息，授权响应消息包括第一令牌。
该收发单元可以执行前述第三面或第五方面中的接收和发送的处理，处理单元可以执行前述第三方面或第五方面中除了接收和发送之外的其他处理。
第十方面，提供了一种CAPIF核心功能网元。该网元包括：收发单元，用于接收来自API调用者 的第二请求消息，第二请求消息用于请求用于将API调用者注册到CCF，或者用于API调用者发现目标API；收发单元，还用于向API调用者发送授权指示。
该收发单元可以执行前述第四方面中的接收和发送的处理，处理单元可以执行前述第四方面中除了接收和发送之外的其他处理。
第十一方面，提供了一种通信装置，包括收发器、处理器和存储器，该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信装置执行上述第一方面至第六方面及其任一种可能实现方式中的方法。
可选地，所述处理器为一个或多个，所述存储器为一个或多个。
可选地，所述存储器可以与所述处理器集成在一起，或者所述存储器与处理器分离设置。
可选地，该通信装置还包括，发射机(发射器)和接收机(接收器)。
第十二方面，提供了一种通信系统，包括API调用者、授权功能网元、API开放功能网元和CAPIF核心功能网元。
第十三方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序或代码，所述计算机程序或代码在计算机上运行时，使得所述计算机执行上述第一方面至第六方面及其任一种可能实现方式中的方法。
第十四方面，提供了一种芯片，包括至少一个处理器，所述至少一个处理器与存储器耦合，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片系统的通信装置执行上述第一方面至第六方面及其任一种可能实现方式中的方法。
其中，该芯片可以包括用于发送信息或数据的输入电路或者接口，以及用于接收信息或数据的输出电路或者接口。
第十五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码被通信装置运行时，使得所述通信装置执行上述第一方面至第六方面及其任一种可能实现方式中的方法。
附图说明
图1是适用本申请的网络架构的一例示意图。
图2是适用本申请的网络架构的另一例示意图。
图3是本申请实施例提供的通信方法300的流程示例图。
图4是本申请实施例提供的通信方法400的流程示例图。
图5是本申请实施例提供的通信方法500的流程示例图。
图6是本申请实施例提供的通信方法600的流程示例图。
图7是本申请实施例提供的通信方法700的流程示例图。
图8是本申请实施例提供的一种通信装置的结构示意图。
图9是本申请实施例提供的另一种通信装置的结构示意图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
本申请提供的技术方案可以应用于各种通信系统，例如：新无线(new radio，NR)系统、长期演进(long term evolution，LTE)系统、LTE频分双工(frequency division duplex，FDD)系统、LTE时分双工(time division duplex，TDD)系统等。本申请提供的技术方案还可以应用于设备到设备(device to device，D2D)通信，车到万物(vehicle-to-everything，V2X)通信，机器到机器(machine to machine，M2M)通信，机器类型通信(machine type communication，MTC)，以及物联网(internet of things，IoT)通信系统或者其他通信系统。
在通信系统中，由运营者运营的部分可称为公共陆地移动网络(public land mobile network，PLMN)，也可以称为运营商网络等。PLMN是由政府或其所批准的经营者为公众提供陆地移动通信业务目的而建立和经营的网络，主要是移动网络运营商(mobile network operator，MNO)为用户提供移动宽带接入服务的公共网络。本申请实施例中所描述的PLMN，具体可为符合3GPP标准要求的网络，简称3GPP 网络。3GPP网络通常包括但不限于第五代移动通信(5th-generation，5G)网络、第四代移动通信(4th-generation，4G)网络，以及未来的其他通信系统，例如(6th-generation，6G)网络等。
为了方便描述，本申请实施例中将以PLMN或5G网络为例进行说明。
图1的(a)是适用本申请的网络架构的一例示意图，以3GPP标准化过程中定义的非漫游场景下，基于服务化架构SBA的5G网络架构为例。如图所示，该网络架构可以包括三部分，分别是终端设备部分、数据网络(data network，DN)和运营商网络PLMN部分。下面对各部分的网元的功能进行简单说明。
终端设备部分可以包括终端设备110，该终端设备110也可以称为用户设备(user equipment，UE)。本申请中的终端设备110是一种具有无线收发功能的设备，可以经无线接入网(radio access network，RAN)140中的接入网设备(或者也可以称为接入设备)与一个或多个核心网(core network，CN)设备进行通信。终端设备110也可称为接入终端、终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、用户代理或用户装置等。终端设备110可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(例如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。终端设备110可以是蜂窝电话(cellular phone)、无绳电话、会话启动协议(session initiation protocol，SIP)电话、智能电话(smart phone)、手机(mobile phone)、无线本地环路(wireless local loop，WLL)站、个人数字处理(personal digital assistant，PDA)等。或者，终端设备110还可以是具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它设备、车载设备、可穿戴设备、无人机设备或物联网、车联网中的终端、5G网络以及未来网络中的任意形态的终端、中继用户设备或者未来演进的6G网络中的终端等。其中，中继用户设备例如可以是5G家庭网关(residential gateway，RG)。例如终端设备110可以是虚拟现实(virtual reality，VR)终端、增强现实(augmented reality，AR)终端、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。这里的终端设备指的是3GPP终端。本申请实施例对终端设备的类型或种类等并不限定。为便于说明，本申请后续以UE代指终端设备为例进行说明。
运营商网络PLMN部分可以包括但不限于(无线)接入网((radio)access network，(R)AN)120和核心网(core network，CN)部分。
(R)AN 120可以看作是运营商网络的子网络，是运营商网络中业务节点与终端设备110之间的实施系统。终端设备110要接入运营商网络，首先是经过(R)AN 120，进而可通过(R)AN 120与运营商网络的业务节点连接。本申请实施例中的接入网设备(RAN设备)，是一种为终端设备110提供无线通信功能的设备，也可以称为网络设备，RAN设备包括但不限于：5G系统中的下一代基站节点(next generation node base station，gNB)、长期演进(long term evolution，LTE)中的演进型节点B(evolved node B，eNB)、无线网络控制器(radio network controller，RNC)、节点B(node B，NB)、基站控制器(base station controller，BSC)、基站收发台(base transceiver station，BTS)、家庭基站(例如，home evolved nodeB，或home node B，HNB)、基带单元(base band unit，BBU)、传输点(transmitting and receiving point，TRP)、发射点(transmitting point，TP)、小基站设备(pico)、移动交换中心，或者未来网络中的网络设备等。采用不同无线接入技术的系统中，具备接入网设备功能的设备的名称可能会有所不同。为方便描述，本申请所有实施例中，上述为终端设备110提供无线通信功能的装置统称为接入网设备或简称为RAN或AN。应理解，本文对接入网设备的具体类型不作限定。
CN部分可以包括但不限于如下网络功能(Network Function，NF)：用户面功能(user plane function，UPF)130、网络开放功能(network exposure function，NEF)131、网络功能存储库功能(network function repository function，NRF)132、策略控制功能(policy control function，PCF)133、统一数据管理功能(unified data management，UDM)134、统一数据存储库功能(unified data repository，UDR)135、网络数据分析功能(network data analytics function，NWDAF)136、认证服务器功能(Authentication Server Function，AUSF)137、接入与移动性管理功能(access and mobility management function，AMF)138、会话管理功能(session management function，SMF)139。
数据网络DN 140，也可以称为分组数据网络(packet data network，PDN)，通常是位于运营商网 络之外的网络，例如第三方网络。当然，在一些实现方式中，DN也可以由运营商进行部署，即DN属于PLMN中的一部分。本申请对DN是否属于PLMN不作限制。运营商网络PLMN可以接入多个数据网络DN 140，数据网络DN 140上可部署多种业务，可为终端设备110提供数据和/或语音等服务。例如，数据网络DN 140可以是某智能工厂的私有网络，智能工厂安装在车间的传感器可以是终端设备110，数据网络DN 140中部署了传感器的控制服务器，控制服务器可为传感器提供服务。传感器可与控制服务器通信，获取控制服务器的指令，根据指令将采集的传感器数据传送给控制服务器等。又例如，数据网络DN 140可以是某公司的内部办公网络，该公司员工的手机或者电脑可为终端设备110，员工的手机或者电脑可以访问公司内部办公网络上的信息、数据资源等。终端设备110可通过运营商网络提供的接口(例如N1等)与运营商网络建立连接，使用运营商网络提供的数据和/或语音等服务。终端设备110还可通过运营商网络访问数据网络DN 140，使用数据网络DN 140上部署的运营商业务，和/或第三方提供的业务。
下面对CN包含的NF功能进行进一步简要说明。
1、UPF 130是由运营商提供的网关，是运营商网络与数据网络DN 140通信的网关。UPF网络功能130包括数据包路由和传输、数据包检测、业务用量上报、服务质量(quality of service，QoS)处理、合法监听、上行数据包检测、下行数据包存储等用户面相关的功能。
2、NEF 131是由运营商提供的控制面功能，主要使能第三方使用网络提供的服务，支持网络开放其能力、事件及数据分析、从外部应用给PLMN安全配备信息、PLMN内外交互信息的转换，提供运营商网络对外开放的API接口，提供给外部服务端与内部运营商网络的交互等。
3、NRF 132是由运营商提供的控制面功能，可用于维护网络中网络功能、服务的实时信息。例如支持网络服务发现、维护NF实例的NF配置数据(NF profile)支持的服务、支持通信代理(service communication proxy，SCP)的服务发现、维护SCP实例的SCP配置数据(SCP profile)、发送有关新注册、去注册、更新的NF和SCP的通知、维护NF和SCP运行的健康状态等。
4、PCF 133是由运营商提供的控制面功能，它支持统一的策略框架来治理网络行为、向其他控制功能提供策略规则、策略决策相关的签约信息等。
5、UDM 134是由运营商提供的控制面功能，负责存储运营商网络中签约用户的用户永久标识符(subscriber permanent identifier，SUPI)、签约用户的公开使用的签约标识(generic public subscription identifier，GPSI)，信任状(credential)等信息。其中SUPI在传输过程中会先进行加密，加密后的SUPI被称为隐藏的用户签约标识符(subscription concealed identifier，SUCI)。UDM网络功能134所存储的这些信息可用于终端设备110接入运营商网络的认证和授权。其中，上述运营商网络的签约用户具体可为使用运营商网络提供的业务的用户，例如使用中国电信的手机芯卡(subscriber identity module，SIM)卡的用户，或者使用中国移动的手机芯卡的用户等。上述签约用户的信任状可以是手机芯卡中存储的长期密钥或者跟手机芯卡加密相关的信息等存储的小文件，用于认证和/或授权。需要说明的是，永久标识符、信任状、安全上下文、认证数据(cookie)、以及令牌等同验证/认证、授权相关的信息，在本申请实施例中，为了描述方便起见不做区分、限制。
6、UDR 135是由运营商提供的控制面功能，为UDM提供存储和获取签约数据的功能、为PCF提供存储和获取策略数据、存储和获取用户的NF群组ID(group ID)信息等。
7、NWDAF 136是由运营商提供的控制面功能，其主要功能是从NF、外部应用功能AF以及运维管理(operations，administration and maintenance，OAM)系统等处收集数据，对NF和AF提供NWDAF业务注册、数据开放和分析数据等。
8、AUSF 137是由运营商提供的控制面功能，通常用于一级认证，即终端设备110(签约用户)与运营商网络之间的认证。AUSF网络功能137接收到签约用户发起的认证请求之后，可通过UDM网络功能134中存储的认证信息和/或授权信息对签约用户进行认证和/或授权，或者通过UDM网络功能134生成签约用户的认证和/或授权信息。AUSF网络功能137可向签约用户反馈认证信息和/或授权信息。
9、AMF 138是由运营商网络提供的控制面网络功能，负责终端设备110接入运营商网络的接入控制和移动性管理，例如包括移动状态管理，分配用户临时身份标识，认证和授权用户等功能。
10、SMF 139是由运营商网络提供的控制面网络功能，负责管理终端设备110的协议数据单元 (protocol data unit，PDU)会话。PDU会话是一个用于传输PDU的通道，终端设备需要通过PDU会话与数据网络DN 140互相传送PDU。PDU会话由SMF网络功能139负责建立、维护和删除等。SMF网络功能139包括会话管理(例如会话建立、修改和释放，包含用户面功能UPF 130和(R)AN 120之间的隧道维护)、UPF网络功能130的选择和控制、业务和会话连续性(service and session continuity，SSC)模式选择、漫游等会话相关的功能。
11、AF 141是由运营商网络提供的控制面网络功能，用于提供应用层信息，可以通过网络开放功能网元，与策略框架交互或直接与策略框架交互进行策略决策请求等。可以位于运营商网络内，或位于运营商网络外。
可以理解的是，上述网元或者功能既可以是硬件设备中的物理实体，也可以是在专用硬件上运行的软件实例，或者是共享平台(例如，云平台)上实例化的虚拟化功能。简单来说，一个NF可以由硬件来实现，也可以由软件来实现。
图1的(a)中Nnef、Nnrf、Npcf、Nudm、Nudr、Nnwdaf、Nausf、Namf、Nsmf、N1、N2、N3、N4，以及N6为接口序列号。示例性的，上述接口序列号的含义可参见3GPP标准协议中定义的含义，本申请对于上述接口序列号的含义不做限制。需要说明的是，图中的各个网络功能之间的接口名称仅仅是一个示例，在具体实现中，该系统架构的接口名称还可能为其他名称，本申请对此不作限定。此外，上述各个网元之间的所传输的消息(或信令)的名称也仅仅是一个示例，对消息本身的功能不构成任何限定。
为方便说明，本申请实施例中将网络功能(如NEF 131…SMF139)统称/简称为NF，即本申请实施例中后文所描述的NF可替换为任一个网络功能。另外，图1的(a)仅示意性地描述了部分网络功能，后文所描述的NF不局限于图1的(a)中示出的网络功能。
应理解，上述应用于本申请实施例的网络架构仅是从服务化架构的角度描述的网络架构，适用本申请实施例的网络架构并不局限于此，任何能够实现上述各个网元的功能的网络架构都适用于本申请实施例。
还应理解，图中所示的AMF、SMF、UPF、NEF、AUSF、NRF、PCF、UDM可以理解为核心网中用于实现不同功能的网元，例如可以按需组合成网络切片。这些核心网网元可以各自独立的设备，也可以集成于同一设备中实现不同的功能，本申请对于上述网元的具体形态不作限定。
还应理解，上述命名仅为便于区分不同的功能而定义，不应对本申请构成任何限定。本申请并不排除在5G网络以及未来其它的网络中采用其他命名的可能。例如，在6G网络中，上述各个网元中的部分或全部可以沿用5G中的术语，也可能采用其他名称等。
图1的(b)是适用本申请的网络架构的另一例示意图，例如CAPIF架构。如图所示，该网络架构包括API调用者、CCF、AEF、AuF、资源拥有者客户端(resource owner client)、资源拥有者(resource owner，RO)等，下面对各个网元的功能进行简单说明。
1、API调用者(API Invoker)：通常由与PLMN运营商签订服务协议的第三方应用程序提供商提供。API Invoker可以是AF，也可以是UE。主要用于提供API调用者身份和API调用者鉴权所需的其他信息，支持鉴权；支持与CAPIF的相互认证；在访问服务API之前获得授权；发现服务API信息；调用服务API。
2、CCF：主要用于根据API调用者鉴权所需的身份和其他信息对API调用者进行鉴权；支持与API调用者的相互认证；在访问服务API之前为API调用者提供授权；发布、存储和支持服务API信息的发现；根据PLMN运营商配置的策略控制业务API访问；存储服务API调用的日志，并将服务API调用日志提供给授权实体；根据服务API调用日志计费；监控服务API调用；加入新的API调用者和退出API调用者；存储CAPIF和业务API相关的策略配置；支持访问日志进行审计(例如检测滥用)；支持在CAPIF对接中使用另一个CAPIF核心函数发布、发现服务API信息。
3、AEF：AEF是服务API的提供者，也是服务API与API调用者的服务通信入口。在3GPP网络中，AEF可以是NEF。主要用于根据CAPIF核心函数提供的API调用者鉴权所需的身份和其他信息，对API调用者进行鉴权；验证CAPIF核心职能提供的授权；记录CAPIF核心函数的服务API调用。
4、AuF：用于获得用户授权。AuF可以在成功认证资源拥有者后向客户端提供接入令牌，以提供用户授权。
5、资源拥有者客户端：发起请求的客户端，通常是浏览器，编辑器，网络爬虫或其他资源所有者所使用的工具。
6、RO：能够授予对受保护资源的访问权限的实体。资源所有者可以是个人。在申请中，可以是3GPP的签约者。
为便于理解本申请实施例，首先对本申请中涉及到的术语或技术做简单说明。
1、用户同意信息：本申请中涉及的用户同意信息用于指示用户对某些数据操作是否同意。具体地，用户同意信息包括两个部分数据处理目的和用户同意结果，其中，数据处理目的用于指示对数据操作的目的。
例如，对数据操作的目的包括但不限于：模型训练、数据分析、数据共享、非地面网络位置查询、RAN数据分析、或RAN数据模型训练等等。数据处理目的可以用于指示对数据操作的目的是模型训练、数据分析、或数据共享。
可选地，数据处理目的还可以称为数据使用目的、数据获取目的等，本申请中信息(或消息)的名称不做任何限定，能够实现相应的功能即可。
用户同意结果用于指示是否同意该数据操作的目的，例如，granted代表同意，not granted代表不同意。还例如，1代表同意，0代表不同意。
示例性地，本申请中用户同意信息还可以包括网络标识。该网络标识用于标识支持用户同意或者不同意数据操作的目的网络，例如，该网络标识可以是公共陆地移动网络PLMN ID。
2、完整性保护(Integrity protection)
完整性保护是指通过物理手段或密码学方法来确保信息在生成、传输、存储过程中，以及之后没有被篡改或没有被未经授权的修改。
其中，通过密码学方法对信息进行完整性保护可以有多种方式。例如，使用非对称密钥中的私钥(private key)对信息进行数字签名，或者使用单向函数(如哈希函数Hash)，以对称密钥(共享密钥)及信息作为输入参数，用来生成消息认证码(message authentication code，MAC)、或者不使用密钥而单独使用单向函数(如哈希函数Hash)，以信息作为输入参数，用来生成哈希值Hash value。
现有的3GPP架构下，AF可以请求获得3GPP网络处理一些3GPP的信息。这些信息可以包含对于网络数据的处理，也可以包含用户数据的处理。特别对于用户数据的处理，AF应该需要获得用户的授权。例如，AF可以请求3GPP对外发送用户的位置信息，如果未获得用户的授权，可能会暴露了用户的隐私信息。因此，亟需一种方法来使AF在请求3GPP网络处理用户数据前，获得用户的授权。
下面结合图2介绍对API调用者到AEF调用特定的API的方案进行说明。
图2的(a)是CAPIF基于TLS with OAuth token中的Oauth 2.0 client_credential的CCF授权API Invoker到AEF调用特定的API的流程，具体包括如下多个步骤。
S211，API调用者(API Invoker)向CCF发送注册请求消息#1。
对应的，CCF接收来自API调用者的注册请求消息#1。
其中，该注册请求消息#1包含注册信息和登记API。
示例性的，注册信息包含API Invoker的信息，例如登记细节、注册需求等。登记API包含需要登记的API列表。
S212，CCF向API调用者发送注册响应消息#1。
对应的，API调用者接收来自CCF的注册响应消息#1。
其中，该注册响应消息#1包含注册状态、已登记信息以及Service API信息。
示例性的，注册状态用于指示注册的结果为成功或者失败。已登记信息包含API Invoker ID，以及授权及认证方法。其中，API Invoker ID由CCF为API Invoker分配，授权及认证方法用于指示使用何种授权及认证方法，授权及认证方法包含TLS-PSK、PKI和TLS with OAuth token。在该实现方式中，假设授权及认证方法为TLS with OAuth token。Service API信息用于指示已登记的API的信息，包含以下一项或者多项：服务API名称、AEF位置、IP地址或域名、端口号和协议等。
S213，API调用者向CCF发送发现服务请求消息#1。
对应的，CCF接收来自API调用者的发现服务请求消息#1。
其中，该发现服务请求消息#1包含API Invoker ID和请求信息。
示例性的，请求信息包含发现某些API的标准，例如偏好的AEF位置、协议等。
S214，CCF向API调用者发送发现服务响应消息#1。
对应的，API调用者接收来自CCF的发现服务响应消息#1。
其中，该发现服务响应消息#1包含service API信息，service API信息响应于步骤S213所请求的API，其信元与步骤S213中的信元相同。
S215，API调用者向CCF发送获得授权请求消息#1。
对应的，CCF接收来自API调用者的获得授权请求消息#1。
其中，该获得授权请求消息#1包含API Invoker ID、服务API名称，以及授权方式，该授权方式指示使用客户端凭证client_credential模式的Oauth方式。
应理解，由于步骤S212中CCF选择的授权及认证方法为TLS with OAuth token，则API Invoker需要向CCF发送获得授权请求消息#1。
S216，CCF向API调用者发送获得授权响应消息#1。
对应的，API调用者接收来自CCF的获得授权响应消息#1。
其中，该获得授权响应消息#1包含token#1，token#1包含声明和签名。声明包含以下内容：超时时间，API Invoker ID，service API ID。签名为CCF对token#1的数字签名。
示例性的，CCF根据本地策略确认API Invoker可访问API name授权后，向API Invoker发送获得授权响应消息#1。
S217，API调用者向AEF发送API调用请求消息#1。
对应的，AEF接收来自API调用者的API调用请求消息#1。
其中，API调用请求消息#1包含API Invoker ID，service API ID以及token#1。
S218，AEF根据API调用请求消息#1校验token#1。
其中，具体校验token#1的实现方式包括如下验证内容：
(1)AEF校验token#1的签名。AEF通过预配置的CCF的凭证(如证书)，校验token#1的签名。
(2)AEF校验token#1的声明部分：AEF判断token#1声明中的API Invoker ID是否和消息中的API Invoker ID一致；或者，AEF判断token#1声明中的service API ID是否和消息中请求的service API ID一致；或者，AEF根据超时时间判断当前token#1是否已超时。
S219，AEF向API Invoker发送API调用响应消息#1。
对应的，API Invoker接收来自AEF的调用响应消息#1
示例性的，若上述步骤S218中的判断通过，则AEF同意API调用请求，并向API Invoker发送调用响应消息#1。反之，若判断不通过，则拒绝API调用请求息。
图2的(b)是CAPIF基于TLS-PSK或PKI的基于access control policy的CCF授权API Invoker到AEF调用特定的API的流程，具体包括如下多个步骤。
S221，API调用者(API Invoker)向CCF发送注册请求消息#11。
对应的，CCF接收来自API调用者的注册请求消息#11。
其中，该注册请求消息#11包含注册信息和登记API。
S222，CCF向API调用者发送注册响应消息#11。
对应的，API调用者接收来自CCF的注册响应消息#11。
其中，该注册响应消息#11包含注册状态、已登记信息以及Service API信息。
在该实现方式中，假设授权及认证方法为TLS-PSK或PKI。
S223，API调用者向CCF发送发现服务请求消息#11。
对应的，CCF接收来自API调用者的发现服务请求消息#11。
其中，该发现服务请求消息#11包含API Invoker ID和请求信息。
S224，CCF向API调用者发送发现服务响应消息#11。
对应的，API调用者接收来自CCF的发现服务响应消息#11。
需要说明的是，步骤S221-S224的具体实现方式与上述步骤S211-S214类似，为了简洁，此处不再赘述。
S225，API Invoker与CCF建立传输层安全协议(transport layer security，TLS)连接。
应理解，由于步骤S222中CCF选择的授权及认证方法为TLS-PSK或PKI方法，API Invoker与CCF需要通过不同的方式建立TLS连接。本申请对建立TLS连接的具体实现方式不作具体限定。
S226，API Invoker向AEF发送API调用请求消息#11。
对应的，AEF接收来自API Invoker的API调用请求消息#11。
其中，API调用请求消息#1包含API Invoker ID以及service API ID。
S227，AEF向CCF发送获得接入控制策略请求消息#11。
对应的，CCF接收来自AEF的获得接入控制策略请求消息#11。
其中，该获得接入控制策略请求消息#11包含AEF ID、API Invoker ID，以及service API ID。
S228，CCF向AEF发送获得接入控制策略响应消息#11。
对应的，AEF接收来自CCF的获得接入控制策略响应消息#11。
其中，该获得接入控制策略响应消息#11包含接入控制策略信息。
示例性的，接入控制策略信息包含API Invoker ID对请求service API ID允许的访问策略，例如最多调用次数、每秒允许调用次数、允许调用时间等。
S229，AEF控制API Invoker对API的调用。
示例性的，AEF根据接收到的接入控制策略控制API Invoker对API的调用。
S220，AEF向API Invoker发送API调用响应消息#11。
对应的，API Invoker接收来自AEF的API调用响应消息#11。
图2的(c)是通用的基于OAuth2.0的授权码(authorization code grant)模式的授权流程，具体包括如下多个步骤。
S231，客户端(Client)向用户代理(User agent)输入信息#a。
对应的，用户代理接收来自客户端的信息#a。
其中，信息#a包括授权服务器(authorization server，AuS)统一资源定位符(Uniform Resource Locator，URL)，重定向URL，范围(scope)以及响应类型(response type)。
示例性的，用户在某app 1上勾选了使用app 2登录，并点击登录，Client因此向User agent发送的AuS URL为app 2的AuS的URL，redirect URL为app 1的URL，scope为授权范围，例如授权使用头像和手机号资源，响应类型为code，即授权码模式。
S232，用户代理向AuS发送授权请求消息#a。
对应的，AuS接收来自用户代理的授权请求消息#a。
其中，授权请求消息#a包括redirect URL，scope以及response type。response type为code。
需要说明的是，用户代理可以根据AuS URL确定AuS的地址。
S233，AuS与资源拥有者RO之间进行认证。
可选地，AuS通过用户代理与RO之间进行认证。
可选地，若AuS与RO之前已做过认证，且AuS仍保存有通过认证的信息，则AuS可跳过与RO的认证过程。
对应的，若用户代理为浏览器时，AuS向用户代理返回请求认证网页，用户代理向RO展示请求认证网页。
对应的，若用户代理为应用客户端时，AuS向用户代理返回请求认证的提示消息，用户代理向RO展示请求认证的消息。
示例性的，app 2部署的AuS要求用户输入用户名及密码。若用户代理已有相关认证信息，则该步骤可省略。
S234，AuS向用户代理发送用户同意请求消息#a，用户代理向RO发送用户同意请求消息#a。
对应的，RO接收来自用户代理的用户同意请求消息#a，用户代理接收来自AuS的用户同意请求消息#a。
S235，RO向用户代理发送用户同意响应消息#a，用户代理向AuS发送用户同意响应消息#a。
对应的，AuS接收来自用户代理的用户同意响应消息#a，用户代理接收来自RO的用户同意响应消息#a。
示例性的，用户点击同意或不同后，用户代理向AuS返回响应授权内容，AuS因此获得了用户的 授权。
S236，AuS向用户代理发送授权响应消息#a，用户代理向客户端发送授权响应消息#a。
对应的，客户端接收来自用于代理的授权响应消息#a，用户代理接收来自的授权响应消息#a。
其中，授权响应消息#a包括redirect URL及code。
示例性的，在获得用户授权后，AuS生成授权码code，并向用户代理发送授权响应消息#a。
S237，客户端通过后端应用向AuS发送接入token请求消息#a。
AuS通过后端应用接收来自客户端的接入token请求消息#a。
其中，该接入token请求消息#a用于请求获取token。该接入token请求消息#a包含code、授权类型＝”授权码(authorization code)”，client ID及redirect URL。
S238，AuS向客户端返回接入token(access token)响应消息#a。
对应的，客户端接收来自AuS的返回接入token响应消息#a。
其中，该接入token响应消息#a包含access token。
S239，客户端通过后端应用向RO Server发送接入请求消息#a。
对应的，RO Server通过后端应用接收来自客户端的接入请求消息#a。
其中，该接入请求消息#a包含access token。
S230，RO Server校验access token。
S240，RO Server向客户端返回接入响应消息#a。
对应的，客户端接收来自RO Server的接入响应消息#a。
其中，接入响应消息#a包括客户端所请求的资源。
示例性的，客户端根据redirect URL及返回的资源向用户展示网页。此时，用户可以看到使用自己的app 2的头像登录的app 1的网页。
图2的(d)是通用的基于OAuth2.0的隐式(implict grant)模式的授权流程。该授权流程与授权码模式类似，主要面向client仅为前端应用的场景。具体包括如下多个步骤。
S241，客户端向用户代理输入信息#aa。
对应的，用户代理接收来自客户端的信息#aa。
其中，信息#aa包括AuS URL，redirect URL，scope以及response type。
示例性的，用户在某app 1上勾选了使用app 2登录，并点击登录，Client因此向User agent发送的AuS URL为app 2的AuS的URL，redirect URL为app 1的URL，scope为授权范围，例如授权使用头像和手机号资源，响应类型为token。
S242，用户代理向AuS发送授权请求消息#aa。
对应的，AuS接收来自用户代理的授权请求消息#aa。
其中，授权请求消息#aa包括redirect URL，scope以及response type。response type为token。
S243，AuS与资源拥有者RO之间进行认证。
对应的，AuS向用户代理返回请求授权网页，用户代理向RO展示请求授权网页。
S244，AuS向用户代理发送用户同意请求消息#aa，用户代理向RO发送用户同意请求消息#aa。
对应的，RO接收来自用户代理的用户同意请求消息#aa，用户代理接收来自AuS的用户同意请求消息#aa。
S245，RO向用户代理发送用户同意响应消息#aa，用户代理向AuS发送用户同意响应消息#aa。
对应的，AuS接收来自用户代理的用户同意响应消息#aa，用户代理接收来自RO的用户同意响应消息#aa。
示例性的，用户点击同意或不同后，用户代理向AuS返回响应授权内容，AuS因此获得了用户的授权。
需要说明的是，步骤S242-S245的具体实现方式与上述步骤S232-S235类似，为了简洁，此处不再赘述。
S246，AuS向用户代理发送接入token响应消息#aa，用户代理向客户端发送token响应消息#aa。
对应的，客户端接收来自用户代理的token响应消息#aa，用户代理接收来自AuS的token响应消息#aa。
其中。token响应消息#aa包括access token。
S247，客户端通过后端应用向RO Server发送接入请求消息#aa。
对应的，RO Server通过后端应用接收来自客户端的接入请求消息#aa。
其中，该接入请求消息#a包含access token。
S248，RO Server校验access token。
S249，RO Server向客户端返回接入响应消息#aa。
对应的，客户端接收来自RO Server的接入响应消息#aa。
需要说明的是，步骤S247-S249的具体实现方式与上述步骤S239、S230和S240类似，为了简洁，此处不再赘述。
综上所述，当前API Invoker可被授权访问特定的API，但是不能实现API Invoker被授权访问特定API的特定用户的数据，用户未被引入进来。也就是说，如果未获得用户的授权，AF在请求3GPP网络处理用户数据时可能会暴露用户的隐私信息。
有鉴于此，本申请提供一种通信方法和通信装置，通过API Invoker主动获得更细粒度的用户授权的token(token包含用户标识)，并使用该token接入AEF，从而使可以AEF授权API Invoker访问某个API并处理某个用户的数据。本申请所揭示的方法能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
为了便于理解本申请实施例，作出以下几点说明：
第一，在本申请中，如果没有特殊说明以及逻辑冲突，不同的实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
第二，在本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。在本申请的文字描述中，字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b和c中的至少一项(个)，可以表示：a，或，b，或，c，或，a和b，或，a和c，或，b和c，或，a、b和c。其中a、b和c分别可以是单个，也可以是多个。
第三，在本申请中，“第一”、“第二”以及各种数字编号(例如，#1、#2等)指示为了描述方便进行的区分，并不用来限制本申请实施例的范围。例如，区分不同的消息等，而不是用于描述特定的顺序或先后次序。应理解，这样描述的对象在适当情况下可以互换，以便能够描述本申请的实施例以外的方案。
第四，在本申请中，“当……时”、“在……的情况下”以及“如果”等描述均指在某种客观情况下设备会做出相应的处理，并非是限定时间，且也不要求设备在实现时一定要有判断的动作，也不意味着存在其它限定。
第五，在本申请中，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
第六，在本申请中，“用于指示”可以包括用于直接指示和用于间接指示。当描述某一指示信息用于指示A时，可以包括该指示信息直接指示A或间接指示A，而并不代表该指示信息中一定携带有A。
本申请涉及的指示方式应理解为涵盖可以使得待指示方获知待指示信息的各种方法。待指示信息可以作为整体一起发送，也可以分成多个子信息分开发送，而且这些子信息的发送周期和/或发送时机可以相同，也可以不同，本申请对具体的发送方法不作限定。
本申请中的“指示信息”可以是显式指示，即通过信令直接指示，或者根据信令指示的参数，结合其他规则或结合其他参数或通过推导获得。也可以是隐式指示，即根据规则或关系，或根据其他参数，或推导获得。本申请对此不作具体限定。
第七，在本申请中，“协议”可以是指通信领域的标准协议，例如可以包括5G协议、NR协议以及应用于未来的通信系统中的相关协议，本申请对此不做限定。“预配置”可以包括预先定义。例如，协议定义。其中，“预先定义”可以通过在设备中预先保存相应的代码、表格或其他可用于指示相关信息 的方式来实现，本申请对于其具体的实现方式不做限定。
第八，在本申请中，“存储”可以是指保存在一个或者多个存储器中。所述一个或者多个存储器可以是单独的设置，也可以是集成在编码器或者译码器、处理器、或通信装置中。所述一个或者多个存储器，也可以是一部分单独设置，一部分集成在译码器、处理器、或通信装置中。存储器的类型可以是任意形式的存储介质，本申请并不对此限定。
第九，在本申请中“通信”还可以描述为“数据传输”、“信息传输”、“数据处理”等。“传输”包括“发送”和“接收”，本申请对此不作限定。
第十，在本申请中，“操作目标用户的数据”以及“访问目标用户的数据”可以表示相同的意思，即API调用者具有使用目标用户的数据的权限；类似地，“授权类型”和“授权方式”可以替换，用于指示授权的方式，例如授权码模式，或者隐式模式，本申请对具体的名称不作具体限定。
下面将结合附图详细说明本申请提供的技术方案。
图3是本申请实施例提供的通信方法300的流程示意图。如图3所示，该方法包括如下多个步骤。
S310,API调用者(API Invoker)向授权功能网元(例如AuF)发送授权请求消息。
对应的，授权功能网元接收来自API调用者的授权请求消息。
其中，授权请求消息用于请求获取目标用户的授权，授权请求消息包括目标用户的标识。
可选地，授权请求消息还包括：目标API的标识(Service API ID)；和/或API调用者的标识(API Invoker ID)。
应理解，API Invoker ID用于标识API Invoker。
示例性的，API Invoker可以是UE，也可以是AF，本申请对此不作具体限定。
需要说明的是，目标用户可以理解为资源拥有者RO，二者的名称可以替换使用，本申请对此不作具体限定。
示例性的，目标用户的标识用于标识用户，例如包括但不限于用户的用户永久标识(subscription permanent identifier，SUPI)、用户隐藏标识符(subscription concealed identifier，SUCI)、通用公共用户标识(generic public subscription identifier，GPSI)、永久设备标识符(permanent equipment identifier，PEI)或(mobile subscriber international ISDN/PSTN number，MSISDN)，ISDN即是综合业务数字网(integrated service digital Network)，PSTN即是公共交换电话网(public switched telephone ntwork)等。MSISDN可以理解为用户对外可以公开的身份标识，比如用户的电话号码等。
应理解，目标API用于指示需要进行授权的API。Service API ID用于指示API Invoker期望调用的API的标识，API指示了用于指示对于用户个人数据的具体操作方式，例如收集、读取、分析、共享等。
示例性的，Service API ID可以包括但不限于：定位Nnef_Location、获取Nnef_UEIdentifier_Get、订阅分析Nnwdaf_AnalyticsSubscription_Subscribe等消息。
例如，某一服务器通过API调用请求消息#A向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AF ID设置为讨论服务器的ID，该动作代表该服务器请求获得IP地址或域名对应的用户(UE)的标识信息。则该API调用请求消息#A指示了该服务器对用户的个人数据(即身份信息)采取读取的操作。
可选地，授权请求消息还包括响应类型，和/或范围指示信息。其中，响应类型用于指示当前的授权方式，例如code指示授权码模式，token指示隐式模式。范围指示信息用于指示授权的范围，例如可以包含Service API ID以及目标用户的标识。
示例性的，该授权请求消息可以是OAuth2.0的Authorization Request消息。
在一种可能的实现方式中，API调用者根据授权指示，向授权功能网元发送授权请求消息。
其中，授权指示用于指示请求操作目标用户的数据需要目标用户的授权。
作为示例而非限定，授权指示可以来自AEF。即在API调用者向授权功能网元发送授权请求消息之前，该方法还包括S301-S303：
S301，API调用者向AEF发送第二API调用请求消息。
对应的，AEF接收来自API调用者的第二API调用请求消息。
其中，第二API调用请求消息用于请求调用目标API以操作目标用户的数据，第二API调用请求 消息包括目标用户的标识；
可选地，第二API调用请求消息还包括目标API的标识，和/或API调用者的标识。
可选地，第二API调用请求消息可以本身就携带目标API的信息。
示例性的，该第二API调用请求消息可以是Service API Invocation Request消息。
S302，AEF确定请求操作目标用户的数据需要目标用户的授权。
在一种示例中，AEF确定本地没有保存有目标用户的用户同意信息，用户同意信息指示目标用户同意操作目标用户的数据。
示例性的，AEF可以根据本地配置的API列表，确定目标API的调用需要目标用户的授权。其中，API列表里面的API都是需要用户同意的API。可选地，API列表可以是AEF预配置的，也可以是其他网元为AEF配置的，本申请对此不作具体限定。
需要说明的是，AEF没有保存有目标用户的用户同意信息，可以理解为AEF本地未存储目标用户的UE上下文，也可以理解为本地存储的目标用户的UE上下文中未保存目标用户的用户同意信息。
可选地，API列表还可以对应授权功能网元的地址，即AEF根据目标API获得授权功能网元的地址，便于后续AEF可以向AuF请求获取目标用户的授权。
可选地，AEF可以在确定本地未获取目标用户的用户同意信息之后，向UDM发送获取请求消息，减少不必要的信令开销。
应理解，用户同意信息包括数据处理目的以及用户同意结果。其中，数据处理目的用于指示对用户个人数据操作的目的，例如包含模型训练，数据分析，数据共享等。用户同意结果用于指示用户是否同意该数据的使用目的，例如granted代表同意，not granted代表不同意。用户标识2是由用户标识1转化而来的，同样表征该目标用户UE，只是针对不同的网元交互进行的转化。
可选地，若AEF已经具备UE的用户同意信息，且用户同意信息指示同意该API Invoker调用该Service API以操作用户的个人数据，则AEF可以直接执行步骤S309。F的地址，并向AuF请求获取用户的授权。例如，通过在授权指示#1中携带比特“1”指示API Invoker对用户个人数据进行操作需要用户的授权；
(2)AuF地址(如IP地址或域名)。其中，AuF地址可以是提前预配置在AEF上的，例如AEF本地预配置的API列表中每个API对应一个AuF地址，则AEF可以根据Service API ID确定API Invoker需要寻找的AuF的地址；
(3)授权方式，用于指示授权的具体方法，例如OAuth 2.0的授权码模式、隐式模式等。
(4)原因值(cause value)，用于指示请求操作目标用户的数据需要目标用户的授权。示例性的，原因值可以是cause#1，用于指示API调用者需要获取目标用户的授权，才可以操作目标用户的个人数据。
在一种示例中，AEF向API调用者发送第二API调用响应消息，第二API调用响应消息包括授权指示#1。
可选地，第二API调用响应消息还包括目标API的标识，和/或目标用户的标识。其中，Service API ID用于指示需要进行授权的API，目标用户的标识用于指示需要进行授权的目标用户。
可选地，第二API调用响应消息为重定向请求消息。示例性的，该重定向请求消息#A可以是状态码为302的HTTP消息。
作为示例而非限定，授权指示可以来自CCF。即在API调用者向授权功能网元发送授权请求消息之前，该方法还包括S304-S305：
S304，API调用者向CCF发送第二请求消息。
对应的，CCF接收来自API调用者的第二请求消息。
其中，第二请求消息用于请求用于将API调用者注册到CCF或者用于API调用者发现API。
示例性的，第二请求消息可以是注册请求消息或发现服务请求消息。例如，该第二请求消息可以是Onboard Service Request消息，或者Discovery Service Request消息。
S305，CCF向API调用者发送授权指示#2。
对应的，API调用者接收来自CCF的授权指示#2。
其中，授权指示#2包括授权功能网元的地址。
在一种示例中，CCF向API调用者发送第二响应消息(即，第二API调用响应消息的一例)，第二响应消息包括授权指示#2。
可选地，第二响应消息还包括目标API的标识，和/或目标用户的标识。
可选地，第二响应消息为注册响应消息或发现服务响应消息。例如，该第二响应消息可以是Onboard Service Response消息，或者Discovery Service Response消息。
可选地，第二API调用响应消息为重定向请求消息。
示例性的，该重定向请求消息可以是状态码为302的HTTP消息。例如，该重定向请求消息要求API调用者执行临时重定向(moved temporarily)，则API调用者应当继续向AuF地址发送请求。
示例性的，该授权指示#2可以包括以下一项或者多项：
(1)明示的指示，即该授权指示#2用于指示API Invoker确定AuF的地址，并向AuF请求获取用户的授权。例如，通过在授权指示#2中携带比特“1”指示API Invoker对用户个人数据进行操作需要用户的授权；
(2)AuF地址(如IP地址或域名)。其中，AuF地址可以是提前预配置在AEF上的，例如AEF本地预配置的API列表中每个API对应一个AuF地址，则AEF可以根据Service API ID确定API Invoker需要寻找的AuF的地址；
(3)授权方式，用于指示授权的具体方法，例如OAuth 2.0的授权码模式、隐式模式等。
(4)原因值，用于指示请求操作目标用户的数据需要目标用户的授权。
在另一种示例中，授权指示#2包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。
可选地，该第二响应消息还包括Service API ID，和/或目标用户的标识。其中，Service API ID用于指示需要进行授权的API，目标用户的标识用于指示需要进行授权的目标用户。
可选地，第二响应消息为重定向请求消息。示例性的，该重定向请求消息可以是状态码为302的HTTP消息。
因此，基于上述步骤S303中的授权指示#1，或者步骤S305中的授权指示#2，API调用者可以确定AuF的地址，并向AuF发送授权请求消息。
示例性的，若授权指示包含(1)明示的指示，此时API Invoker可以根据本地预配置的AuF地址列表，确定Service API ID对应的AuF地址，并向AuF请求获取用户的授权；又例如，若授权指示包含(2)AuF的地址，此时API Invoker可以直接根据该AuF地址，向AuF发送授权请求消息#A。
可选地，API Invoker可以根据授权指示#1或授权指示#2中的(3)授权方式确定响应类型。该响应类型可以携带在授权请求消息中。例如，若授权方式为OAuth 2.0的授权码模式，则响应类型应为code；若授权方式为OAuth2.0的隐式模式，则响应类型应为token。
可选地，API调用者根据授权指示#1或者授权指示#2中的(4)原因值，确定授权功能网元的地址；进一步地，API调用者根据授权功能网元的地址，向授权功能网元发送授权请求消息。
可选地，API调用者根据授权指示#1或者授权指示#2中的原因值，从配置的地址列表中获取授权功能网元的地址。示例性的，API调用者通过原因值，例如cause#1确定请求操作目标用户的个人数据需要获取目标用户的授权，进而根据地址列表找到对应的AuF的地址，或者根据AEF发送的AuF的地址，向AuF进行授权。
可选地，在API调用者根据授权指示，向授权功能网元发送授权请求消息之前，API调用者根据授权类型确定响应类型。
在该实现方式中，API调用者根据授权指示确定向AuF请求获取用户的授权，可以实现面向特定API的用户授权控制，提升了用户授权的灵活性。
可选地，CCF可以作为中间节点进行转发，向AuF获得用户授权。该实现方式中API调用者无需根据授权指示向AuF发送授权请求消息，能够减少API的信令开销。
S311，API调用者向CCF发送授权请求消息。
对应的，CCF接收来自API调用者的授权请求消息。
基于上述步骤S303中的授权指示#1，或者步骤S305中的授权指示#2，API调用者可以确定响应 类型，并向CCF发送授权请求消息。
可选地，若授权指示包含(1)明示的指示，此时API Invoker可以根据本地预配置的响应类型，确定Service API ID对应的响应类型，并向CCF请求获取用户的授权。例如，若收到明示的指示，则API invoker设置响应类型为code或token。
可选地，API Invoker可以根据授权指示#1或授权指示#2中的(3)授权方式确定响应类型。该响应类型可以携带在授权请求消息中。例如，若授权方式为OAuth 2.0的授权码模式，则响应类型应为code；若授权方式为OAuth2.0的隐式模式，则响应类型应为token。
可选地，API调用者根据授权指示#1或者授权指示#2中的(4)原因值，确定授权响应类型。例如，若收到原因值用于指示请求操作目标用户的数据需要目标用户的授权，则API invoker设置响应类型为code或token。
S312，CCF向授权功能网元发送授权请求消息。
对应的，授权功能网元接收来自CCF的授权请求消息。
其中，授权请求消息包括API调用者的标识、目标API的标识以及目标用户的标识。
在一种示例中，在CCF向授权功能网元发送授权请求消息之前，CCF根据可以根据地址列表，确定授权功能网元的地址；并根据授权功能网元的地址，向授权功能网元发送授权请求消息。
示例性的，该地址列表用于指示目标API的标识与授权功能网元的地址的映射关系。
可选地，该地址列表可以是CCF本地配置的，可以是CCF预配置的，也可以是其他网络功能网元为CCF配置的本身其对此不作具体限定。
S320，AuF在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元生成具有完整性保护的第一令牌。
其中，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识。
需要说明的是，AuF确定目标用户同意API调用者操作目标用户的数据的具体实现方式可参见上述图2的(c)中步骤S233-S235；或者，也可以参见上述图2的(d)中步骤S243-S245。为了简洁，此处不再赘述。
可选地，第一令牌还包括以下一项或者多项：超时时间；API调用者的标识；目标API的标识；签名者。
其中，签名者用于指示签名的实体，以使得AuF可根据不同签名者选择不同的证书校验第一令牌。例如，签名者可以用于指示对第一令牌进行签名的网元的标识，或者用于指示生成第一令牌的网元的标识，又或者用于指示授权功能网元的标识，本申请对此不作具体限定。例如，签名者可以是AuF ID或CAPIF ID，也可以是AuF类型或CAPIF类型，也可以是以下任一项：授权码、隐式、客户端凭证、用户密码凭证授权，还可以是用户授权或网络功能授权。
可选地，第一令牌还包括以下一项或者多项：第一令牌的生成时间、第一令牌的有效时长、第一令牌的有效的截止时间等。
可选地，第一令牌还包括其他参数，例如允许使用的资源、网络切片信息等，本申请对此不作具体限定。
可选地，授权功能网元首先根据上述参数生成声明；然后根据声明生成签名；最后根据声明和签名生成具有完整性保护的第一令牌。
需要说明的是，基于目标用户的标识信息生成第一令牌，可以实现更细粒度的授权，即使得API调用者可以被授权具有访问目标API以操作目标用户的个人数据的权限。
S330，授权功能网元向API调用者发送授权响应消息。
对应的，API调用者接收来自授权功能网元的授权响应消息。
其中，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；
示例性的，若用户同意信息指示用户同意授权API Invoker调用Service API以操作用户数据，则授权响应消息包括具有完整性保护的第一令牌。反之，若用户同意信息指示用户拒绝授权API Invoker调用Service API以操作用户数据，则授权响应消息包括失败指示信息，失败指示信息用于指示用户未 授权API Invoker调用Service API以操作用户数据。
示例性的，该授权响应消息可以是OAuth2.0的Authorization Response消息。
在一种可能的实现方式中，API调用者接收来自授权功能网元的授权响应消息，还可以通过CCF作为中间节点进行转发，对应下面步骤S331和S332。
S331，授权功能网元向CCF发送授权响应消息。
对应的，CCF接收来自授权功能网元的授权响应消息。
S332，CCF向API调用者发送授权响应消息。
对应的，API调用者接收来自授权功能网元的授权响应消息。
其中，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识。
接下来，API调用者基于上述步骤S330或S305获得的第一令牌，可以向AEF发送第一API调用请求消息，用于请求调用目标API以操作目标用户的个人数据。
S340，API调用者向AEF发送第一API调用请求消息。
对应的，AEF接收来自API调用者的第一API调用请求消息。
其中，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。
可选地，第一API调用请求消息还包括目标API的标识(Service API ID)，和/或API调用者的标识(API Invoker ID)。
可选地，第一API调用请求消息可以本身就携带目标API的信息。
示例性的，该第一API调用请求消息可以是Service API Invocation Request消息。
在一种示例中，第一API调用请求消息还包括第二令牌，第二令牌用于指示API调用者具有调用目标API的权限，第二令牌包括API调用者的标识和目标API的标识。
可选地，在API调用者向AEF发送第一API调用请求消息之前，API调用者可以向CCF请求获取第二令牌，即该方法还包括下面步骤S306-S307：
S306，API调用者向CCF发送第一请求消息。
对应的，CCF接收来自API调用者的第一请求消息。
其中，第一请求消息用于请求获取调用目标API的权限，第一请求消息包括API调用者的标识和目标API的标识。
示例性的，第一请求消息可以是注册API Invoker请求消息或发现服务请求消息。例如，该第一请求消息可以是Onboard API Invoker Request消息，或者Discovery Service Request消息。
S307，CCF向API调用者发送第二令牌。
对应的，API调用者接收来自CCF的第二令牌。
其中，第二令牌包括目标API的标识。
可选地，第二令牌还包括以下至少一项：API调用者的标识；超时时间，签名。
可选地，第二令牌还包括以下一项或者多项：第二令牌的生成时间、第二令牌的有效时长、第二令牌的有效的截止时间等。
基于接收到的第二令牌，AEF可以判断API调用者具有调用目标API的权限，即该方法还包括步骤S308。
S308，可选地，AEF根据第二令牌，确定API调用者具有调用目标API的权限。
可选地，AEF可以分别校验第二令牌的签名、API调用者的标识、目标API的标识、超时时间等。
示例性的，AEF可以通过预配置的CCF的凭证(如证书)，校验第二令牌的签名。
进一步地，基于签名验证通过的情况下，AEF继续校验第二令牌中的信息部分。
示例性的，AEF通过判断第二令牌中携带的目标API的标识，与第一API调用请求消息中携带的目标API的标识相同，确定API调用者具有调用目标API的权限。
可选地，AEF判断第二令牌中携带的API Invoker ID是否和API调用请求消息中的API Invoker ID一致。
可选地，AEF根据第二令牌中携带的超时时间判断当前token是否已超时。
可选地，AEF根据第二令牌的有效时长为5h，第二令牌的生成时间为2:30，AEF接收到API调用请求消息的时间为10:30，则AEF确定该第二令牌已经失效，进而拒绝API Invoker访问目标API的请求。
可选地，AEF根据第二令牌的有效截止时间为12:30，AEF接收到API调用请求消息的时间为12:00，在第二令牌中携带的签名和具体信息内容验证通过的情况下，可以接受API Invoker的目标API调用请求。
可选地，AEF通常可以在判断API调用者是否具有调用目标API的权限之后，再进一步的判断API调用者是否具有操作目标用户的数据的权限。也就是说，本申请对步骤S308和步骤S350的执行顺序不作限定。
S350，AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限。
应理解，第一令牌包括声明和签名两部分，因此AEF需要根据声明和签名两部分，确定API调用者是否具有操作目标用户的数据的权限，具体实现方式包括下面两个步骤。
步骤一：AEF验证第一令牌的签名。
在一种示例中，AEF根据授权功能网元的凭证，对第一令牌的完整性保护进行验证，授权功能网元为生成第一令牌的网元。
可选地，授权功能网元的凭证可以是AEF预配置的。
可选地，在AEF根据授权功能网元的凭证，对第一令牌进行完整性验证之前，AEF可以根据签名者获取授权功能网元的凭证。
可选地，第一令牌还包括签名者。例如，AEF可以根据签名者，获取授权功能网元的凭证。
示例性的，若签名者是AuF ID或CAPIF ID，AEF可以预配置签名者对应的凭证，即AEF可获得签名者是AuF ID或CAPIF ID对应的凭证，进而校验第一令牌的签名；又例如，若签名者是AuF或CAPIF，AEF可以预配置不同签名者类型对应的凭证，即AEF可获得AuF或CAPIF对应的凭证，进而校验第一令牌的签名；若签名者是以下任一项：授权码、隐式、客户端凭证、用户密码凭证，AEF可以预配置不同签名者类型对应的凭证，即授权码、隐式，或用户密码凭证可以使用AuF的凭证，客户端凭证可以使用CAPIF的凭证；若签名者是用户授权或网络功能授权，AEF预配置不同签名者类型对应的凭证，即用户授权可以使用AuF的凭证，网络功能授权可以使用CAPIF的凭证。
基于此，当AEF使用预配置的凭证成功地验证该第一令牌的签名时，说明该第一令牌没有被篡改过。否则，验证失败，AEF可以拒绝API Invoker对目标API的调用请求。
应理解，当第一令牌的签名验证通过后，AEF将继续进行步骤二声明部分的验证，即对于第一令牌的内容信息进行验证。
步骤二：AEF验证第一令牌的声明中的信息内容。
其中，声明包括目标用户的标识。
在一种示例中，AEF判断第一令牌中携带的目标用户的标识，是否与第一API调用请求消息中携带的目标用户的标识相同。
可选地，声明还包括以下至少一项：超时时间；API调用者的标识；目标API的标识等。
可选地，AEF判断第一令牌中携带的API调用者的标识，是否与第一API调用请求消息中携带的API调用者的标识相同。
可选地，AEF判断第一令牌中携带的目标API的标识，是否与第一API调用请求消息中携带的目标API的标识相同。
可选地，声明中还可以包括以下一项或者多项：第一令牌的生成时间、第一令牌的有效时长、第一令牌的有效的截止时间等。
示例性的，第一令牌的有效时长为12h，第一令牌的生成时间为2:30，AEF接收到API调用请求消息#B的时间为12:30，则AEF在第一令牌的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求。再例如，第一令牌的有效截止时间为12:30，AEF接收到API调用请求消息#B的时间为12:00，则AEF在第一令牌的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求等。
需要说明的是，只有上述两个步骤都验证通过后，AEF可以确定API调用者具有操作目标用户的 数据的权限。否则，AEF可以确定API调用者不具有操作目标用户的数据的权限。
S360，AEF根据确定结果，确定是否向API调用者提供访问目标用户的数据的权限。
需要说明的是，基于第一令牌的校验结果(例如，第一令牌验证成功的情况下)，进一步确定是否向API调用者提供访问目标用户的数据的权限，可以通过两种方法，例如校验第二令牌，确定API调用者是否具有访问目标API的权限；或者；AEF向CCF校验访问控制列表，请求获取API调用者调用目标API的访问策略。
可选地，在API调用者具有操作目标用户的数据的权限，且访问策略指示允许API调用者调用目标API的情况下，AEF向API调用者提供访问目标用户的数据的权限。
可选地，用于指示允许API调用者调用目标API的访问策略可以是从AEF获得的。
示例性的，AEF向CCF发送第三请求消息，并接收来自CCF的访问策略。
其中，该第三请求消息用于请求获取API调用者调用目标API的访问策略，第三请求消息包括API调用者的标识和目标API的标识，访问策略用于指示是否允许API调用者调用目标API。
基于上述步骤S360的判断，AEF可以向API调用者提供访问目标用户的数据的权限。即，该方法还包括步骤S309。
S309，AEF向API调用者发送第一API调用响应消息。
对应的，API调用者接收来自AEF的第一API调用响应消息。
其中，该第一API调用响应消息用于返回API Invoker ID调用目标API以操作用户数据的结果。例如，授权API Invoker ID具有调用目标API以操作用户数据的权限。
示例性的，若某一服务器通过API调用请求消息#B向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AF ID设置为讨论服务器的ID，则AEF将返回API调用响应消息#B，该消息中包含该UE的外部标识，例如GPSI。
可选地，在API调用者具有操作目标用户的数据的权限的情况下，AEF可以向UDM发送签约信息更新消息，用于更新目标用户的用户同意信息，用户同意信息用于指示目标用户同意操作目标用户的数据。
其中，该签约信息更新请求消息用于更新UE的用户同意信息，该签约信息更新消息可以包括以下一项或多项：用户标识，数据处理目的，API Invoker ID，超时时间，用户同意结果。
应理解，数据处理目的是根据Server API ID转化而来，用户同意结果可以根据步骤S420的用户同意信息#A获得。
该实现方式中，通过AEF更新UDM上的UE签约信息，可以减少AuF请求RO授权的次数。
本申请提供的方案，API Invoker通过从授权功能网元获得更细粒度的用户授权的第一令牌，并使用该第一令牌接入AEF，从而使可以AEF授权API Invoker访问某个API并处理某个用户的数据。该方法在对用户数据进行处理时引入用户是否授权的考量，能够避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
考虑到当前技术方案仅限于NF之间进行授权，粒度仅为NF1授权NF2访问某个API。该实现方式引入AuF以及更细粒度的token，从而在授权过程中引入了用户，粒度可以达到NF1授权NF2访问某个API并调用某个用户的数据，接下来结合图4对获得用户授权的方法进行具体说明。
图4是本申请实施例提供的通信方法400的流程示例图。如图4所示，该方法包括如下多个步骤。
S401，可选地，API调用者(API Invoker)向AEF发送API调用请求消息#A(即，第二API调用请求消息的一例)。
对应的，AEF接收来自API调用者的API调用请求消息#A。
示例性的，该API调用请求消息#A用于请求调用Service API(即，目标API的一例)以操作用户的个人数据，该API调用请求消息#A包括API调用者的标识(API Invoker ID)。
其中，API Invoker ID用于标识API Invoker。Service API ID用于指示API Invoker期望调用的API的标识，API指示了对于用户个人数据的具体操作方式，例如收集、读取、分析、共享等。
需要说明的是，这里的用户可以理解为资源拥有者(resource owner)，二者的名称可以替换使用，本申请对此不作具体限定。
示例性的，API Invoker可以是UE，也可以是AF。在3GPP网络中，AEF可以是NEF，AEF是 Service API的提供者，也是API Invoker的服务通信入口，本申请对此不作限制。
可选地，该API调用请求消息#A还包括用户标识1(即，目标用户的标识的一例)，和/或目标API的标识(Service API ID)。
其中，用户标识1可以包括但不限于SUPI、SUCI、GPSI、PEI或MSISDN。
可选地，该API调用请求消息#A本身携带Service API ID。例如，该API调用请求消息#A可以包括但不限于：定位Nnef_Location、获取Nnef_UEIdentifier_Get、订阅分析Nnwdaf_AnalyticsSubscription_Subscribe等消息。
应理解，本申请中对于用户标识1的具体形式不做限定，能够用于标识该用户即可。本申请中对于API调用请求消息(或信息)的名称不做任何的限定，能够实现相应的功能即可。
S402，可选地，AEF判断当前API调用是否需要用户同意，生成重定向请求消息#A(即，重定向请求消息的一例)。
其中，重定向请求消息#A用于指示API Invoker向AuF请求获取用户的授权。
示例性的，AEF可以根据本地配置信息判断当前的API是否需要用户同意。例如，本地配置信息可以是一个API列表，该API列表中的所有API都是需要用户同意的API。
可选地，该API列表还可以与AuF地址对应，即每个API对应一个AuF地址，则AEF可以根据该API列表确定Service API对应的AuF地址。
在一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AEF不具备用户标识1对应的UE上下文，或者用户标识1对应的UE上下文中未保存有UE的用户同意信息的情况下，AEF可以生成重定向请求消息#A。
在另一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AEF从UDM未成功获取该UE的用户同意信息的情况下，AEF可以生成重定向请求消息#A。例如，AEF向UDM发送签约信息获取请求消息，用于请求获取该UE的签约信息。该签约信息获取请求消息包含用户标识2。对应的，UDM向AEF发送的签约信息获取响应消息中不包含UE的用户同意信息。
可选地，该签约信息获取请求消息可以为Nudm_SDM_Get Request消息，该签约信息获取响应消息可以为Nudm_SDM_Get Response消息。
基于此，AEF需要通知API Invoker，寻找AuF进行用户的授权。
可选地，若AEF已经具备UE的用户同意信息，且用户同意信息指示同意该API Invoker调用该Service API以操作用户的个人数据，则AEF可以直接执行步骤S470。
S403，可选地，AEF向API调用者发送重定向请求消息#A。
对应的，API调用者接收来自AEF的重定向请求消息#A。
其中，该重定向消息#A包括授权指示。
示例性的，该授权指示可以包括以下一项或者多项：
(1)明示的指示，即该授权指示用于指示API Invoker确定AuF的地址，并向AuF请求获取用户的授权。例如，通过在授权指示中携带比特“1”指示API Invoker对用户个人数据进行操作需要用户的授权；
(2)AuF地址(如IP地址或域名)。其中，AuF地址可以是提前预配置在AEF上的，例如AEF本地预配置的API列表中每个API对应一个AuF地址，则AEF可以根据Service API ID确定API Invoker需要寻找的AuF的地址；
(3)授权方式，用于指示授权的具体方法，例如OAuth 2.0的授权码模式、隐式模式等。
(4)原因值，用于指示请求操作目标用户的数据需要目标用户的授权。
可选地，该重定向消息#A还包括Service API ID，和/或用户标识1。其中，Service API ID用于指示需要进行授权的API。
示例性的，该重定向请求消息#A可以是状态码为302的HTTP消息。
可选地，步骤S403可替换为：AEF向API调用者发送授权指示，该授权指示包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。
可选地，API调用者根据原因值，确定授权功能网元的地址；API调用者根据授权功能网元的地址，向授权功能网元发送授权请求消息。
可选地，API调用者根据原因值，从预配置的地址列表中获取授权功能网元的地址。
S410，API调用者向AuF发送授权请求消息#A(即，授权请求消息的一例)。
对应的，AuF接收来自API调用者的授权请求消息#A。
其中，该授权请求消息#A用于请求获取用户的授权，该授权请求消息#A包括用户标识1(即，目标用户的标识的一例)。
可选地，该授权请求消息#A还包括Service API ID，和/或API Invoker ID。
可选地，Service API ID，和/或用户标识1是从重定向消息#A中获得的。
可选地，该授权请求消息#A还包括响应类型，和/或范围指示信息。其中，响应类型用于指示当前的授权方式，例如code指示授权码模式，token指示隐式模式。范围指示信息用于指示授权的范围，例如可以包含Service API ID以及用户标识1。
在一种可能的实现方式中，API Invoker根据步骤S403的重定向请求消息#A向AuF发送授权请求消息#A。
示例性的，API Invoker根据授权指示确定AuF的地址进行授权。例如，若授权指示包含(1)明示的指示，此时API Invoker可以根据本地预配置的AuF地址列表，确定Service API ID对应的AuF地址，并向AuF请求获取用户的授权；又例如，若授权指示包含(2)AuF的地址，此时API Invoker可以直接根据该AuF地址，向AuF发送授权请求消息#A。
可选地，API Invoker可以根据授权指示中的(3)授权方式确定响应类型。该响应类型可以携带在授权请求消息#A中。例如，若授权方式为OAuth 2.0的授权码模式，则响应类型应为code，若授权方式为OAuth2.0的隐式模式，则响应类型应为token。
示例性的，该授权请求消息#A可以是OAuth2.0的Authorization Request消息。
S420，AuF与RO客户端进行交互，以获取用户同意信息#A。
其中，若当前的授权方式为OAuth2.0的授权码模式，该步骤的具体实现方式可参见上述图2的(c)中步骤S233-S235；或者，若当前的授权方式为OAuth2.0的隐式模式，也可以参见上述图2的(d)中步骤S243-S245。为了简洁，此处不再赘述。
S430，AuF确定授权响应消息#A(即，授权响应消息的一例)。
示例性的，基于步骤S420，若用户同意信息#A指示用户同意授权API Invoker调用Service API以操作用户数据，则授权响应消息#A包括具有完整性保护的token，该token包括用户标识1。反之，若用户同意信息#A指示用户拒绝授权API Invoker调用Service API以操作用户数据，则授权响应消息#A包括失败指示信息，该失败指示信息用于指示用户未授权API Invoker调用Service API以操作用户数据。
S440，AuF向API调用者发送授权响应消息#A。
对应的，API调用者接收来自AuF的授权响应消息#A。
S404，可选地，API调用者向AuF发送接入token请求消息#A。
对应的，AuF接收来自API调用者的接入token请求消息#A。
S405，可选地，AuF向API调用者发送接入token响应消息#A。
对应的，API调用者接收来自AuF的接入token响应消息#A。
其中，接入token响应消息#A包括具有完整性保护的token，token包括用户标识1。
需要说明的是，上述步骤S404和S405的具体实现方式可参见上述图2的(c)中步骤S237-S238。为了简洁，此处不再赘述。
应理解，针对步骤S430和S405，具有完整性保护的token的签名可以是AuF对token的数字签名。示例性的，token还可以包括声明(claims)，声明中包括以下一项或者多项：超时时间，API Invoker ID，service API ID，签名者。其中，签名者用于指示签名的实体，以使得AuF可根据不同签名者选择不同的证书校验token。例如，签名者可以是AuF ID或CAPIF ID，也可以是AuF类型或CAPIF类型，也可以是以下任一项：授权码、隐式、客户端凭证、用户密码凭证授权，还可以是用户授权或网络功能授权。
可选地，声明中还可以包括以下一项或者多项：token的生成时间、token的有效时长、token的有效的截止时间等。
可选地，声明中还可以包括其他参数，例如允许使用的资源、网络切片信息等，本申请对此不作具体限定。
可选地，针对上述步骤S420-S405，具体实现方式可以参考上述图2的(c)所示的基于OAuth2.0的授权码(authorization code grant)模式的授权方式进行授权。针对上述步骤S420-S440，具体实现方式可以参考上述图2的(d)所示的基于OAuth2.0的隐式(implict grant)模式的授权方式进行授权。为了简洁，此处不再过多赘述。
S450，API调用者向AEF发送API调用请求消息#B(即，第一API调用请求消息的一例)。
对应的，AEF接收来自API调用者的API调用请求消息#B。
其中，API调用请求消息#B包括用户标识1(即，目标用户的标识的一例)，以及具有完整性保护的token(即，第一令牌的一例)。其中，token包括用户标识1。
可选地，API调用请求消息#B包括API Invoker ID，和/或Service API ID。
可选地，该token包括以下一项或者多项：超时时间，API Invoker ID，Service API ID，签名者。
可选地，签名者可以不放在token的声明中，而携带在API调用请求消息#B。
S460，AEF验证token。
其中，AEF验证token的具体实现方式包括如下两个步骤：
步骤一，AEF校验token的签名，即对token的完整性保护进行验证。
在一种可能的实现方式中，AEF根据预配置的AuF的凭证(如证书)，校验token的签名。
示例性的，AEF根据签名者(可以携带在token的声明中，也可以携带在API调用请求消息#B)确定使用何种凭证校验Token的签名。例如，若签名者是AuF ID或CAPIF ID，AEF可以预配置签名者对应的凭证，即AEF可获得签名者是AuF ID或CAPIF ID对应的凭证，进而校验token的签名；又例如，若签名者是AuF或CAPIF，AEF可以预配置不同签名者类型对应的凭证，即AEF可获得AuF或CAPIF对应的凭证，进而校验token的签名；若签名者是以下任一项：授权码、隐式、客户端凭证、用户密码凭证，AEF可以预配置不同签名者类型对应的凭证，即授权码、隐式，或用户密码凭证可以使用AuF的凭证，客户端凭证可以使用CAPIF的凭证；若签名者是用户授权或网络功能授权，AEF预配置不同签名者类型对应的凭证，即用户授权可以使用AuF的凭证，网络功能授权可以使用CAPIF的凭证。
基于此，当AEF使用预配置的凭证成功地验证该token的签名时，说明该token未被篡改过。否则，验证失败，AEF可以拒绝API Invoker对目标API的调用请求。
应理解，当token的签名验证通过后，AEF将继续进行步骤二声明部分的验证，即对于第一令牌的内容信息进行验证。
步骤二：AEF校验token的声明。
示例性的，AEF可以判断API调用请求消息#B中的用户标识1是否与token中的用户标识1一致。
可选地，AEF判断API调用请求消息#B中的API Invoker ID是否与token中的API Invoker ID一致；或者，AEF判断API调用请求消息#B中的Service API ID是否与token中的Service API ID一致；或者，AEF根据token中的超时时间与当前的时间对比，判断token是否仍然有效，等等。
可选地，该token通常在有效期内可以被API Invoekr重复使用。
可选地，声明中还可以包括以下一项或者多项：token的生成时间、token的有效时长、token的有效的截止时间等。例如，token的有效时长为12h，token的生成时间为2:30，AEF接收到API调用请求消息#B的时间为12:30，则AEF在token的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求。再例如，token的有效截止时间为12:30，AEF接收到API调用请求消息#B的时间为12:00，则AEF在token的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求等。
进一步地，当上述步骤一和步骤二验证通过后，AEF可以接受API Invoker的API调用请求，即AEF执行下面步骤S470和S406。若上述判断不通过，则AEF可以拒绝API Invoker的API调用请求。
S470，AEF向API调用者发送API调用响应消息#B。
对应的，API调用者接收来自AEF的API调用响应消息#B。
其中，该API调用响应消息#B用于返回API Invoker ID调用目标API以操作用户数据的结果。例 如，授权API Invoker ID具有调用目标API以操作用户数据的权限。
示例性的，若某一服务器通过API调用请求消息#B向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AF ID设置为讨论服务器的ID，则AEF将返回API调用响应消息#B，该消息中包含该UE的外部标识，例如GPSI。
S406，可选地，AEF向UDM发送签约信息更新请求消息#A。
对应的，UDM接收来自AEF的签约信息更新请求消息#A。
其中，该签约信息更新请求消息#A用于更新UE的用户同意信息，该签约信息更新消息#A可以包括以下一项或多项：用户标识2，数据处理目的，API Invoker ID，超时时间，用户同意结果。
应理解，用户标识2根据用户标识1转化而来，可以为SUPI，数据处理目的是根据Server API ID转化而来，用户同意结果可以根据步骤S420的用户同意信息#A获得。
该实现方式中，通过AEF更新UDM上的UE签约信息，可以减少AuF请求RO授权的次数。
本申请所揭示的方法，通过引入AuF生成更细粒度的token(包括用户标识1)，使得在授权过程中考虑用户同意信息，粒度可以达到NF1授权NF2访问某个API并调用某个用户的数据。相比于现有技术中只限于NF之间进行授权，粒度仅为NF1授权NF2访问某个API，该实现方式在处理用户数据时需要用户的授权，保护用户的隐私信息，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
图5是本申请实施例提供的通信方法500的流程示例图。与上述方法400不同之处在于，该实现方式通过CCF向API Invoker提供需要进行用户授权的信息，并且将调用API的token与操作用户个人数据的token解耦。如图5所示，该方法包括如下多个步骤。
S501，API调用者向CCF发送注册请求消息#AA，或者发现请求消息#AA(即，第二请求消息的一例)。
对应的，CCF接收来自API调用者的注册请求消息#AA，或者发现请求消息#AA。
其中，该注册请求消息#AA，或者发现请求消息#AA包括用户标识1(即，目标用户的一例)和Server API ID(即，目标API的标识的一例)。该注册请求消息#AA，或者发现请求消息#AA的具体含义可参考上述步骤S211或S213中的消息的具体含义，该注册请求消息#AA用于将API调用者注册到CCF，该发现请求消息#AA用于API调用者发现目标API。
S502，CCF向API调用者发送注册响应消息#AA，或者发现响应消息#AA(即，第二API调用响应消息的一例)。
对应的，API调用者接收来自CCF的注册响应消息#AA，或者发现响应消息#AA。
其中，该注册响应消息#AA，或者发现响应消息#AA包括授权指示。该注册响应消息#AA，或者发现响应消息#AA的具体含义可参考上述步骤S212或S214中的消息的具体含义.
示例性的，该授权指示可以包括以下一项或者多项：
(1)明示的指示，即该授权指示用于指示API Invoker确定AuF的地址，并向AuF请求获取用户的授权。例如，通过在授权指示中携带比特“1”指示API Invoker对用户个人数据进行操作需要用户的授权；
(2)AuF地址(如IP地址或域名)。其中，AuF地址可以是提前预配置在AEF上的，例如AEF本地预配置的API列表中每个API对应一个AuF地址，则AEF可以根据Service API ID确定API Invoker需要寻找的AuF的地址；
(3)授权方式，用于指示授权的具体方法，例如OAuth 2.0的授权码模式、隐式模式等。
(4)原因值，用于指示请求操作目标用户的数据需要目标用户的授权。
可选地，该注册响应消息#AA，或者发现响应消息#AA还包括Service API ID，和/或用户标识1。其中，Service API ID用于指示需要进行授权的API。
S503，可选地，API调用者根据授权指示向CCF发送获取授权请求消息#AA(即，第一请求消息的一例)。
对应的，CCF接收来自API调用者的获取授权请求消息#AA。
其中，该获取授权请求消息#AA用于请求获取调用Service API的权限，该获取授权请求消息#AA包括API Invoker ID和Service API ID。
S504，可选地，CCF向API调用者发送获取授权响应消息#AA。
对应的，API调用者接收来自CCF的获取授权响应消息#AA。
其中，该获取授权响应消息#AA包括token1(即，第二令牌的一例)，token1用于指示API Invoker具有访问Service API的权限。
S505，API调用者根据授权指示确定请求AuF进行授权。
应理解，基于步骤S502中的授权指示，对于特定Service API ID，APIInvoker需要额外请求AuF进行用户的授权。因此，当API Invoker准备调用特定Service API ID，且该Service API ID具有对应的授权指示时，API Invoker应根据授权指示确定AuF的地址进行授权。
示例性的，API Invoker根据授权指示确定AuF的地址进行授权。例如，若授权指示包含(1)明示的指示，此时API Invoker可以根据预配置的AuF地址，向AuF请求获取用户的授权；又例如，若授权指示包含(2)AuF的地址，则API Invoker根据该AuF的地址，向AuF请求获取用户的授权。
可选地，API Invoker根据授权指示中的(3)授权方式可以确定使用何种响应类型，例如，若授权方式为OAuth 2.0的授权码模式，则响应类型应为code，若授权方式为OAuth2.0的隐式模式，则响应类型应为token等。
S506，API调用者向AuF发送授权请求消息#AA(即，授权请求消息的一例)。
对应的，AuF接收来自API调用者的授权请求消息#AA。
其中，该授权请求消息#AA用于请求获取用户的授权，该授权请求消息#AA包括用户标识1(即，目标用户的标识的一例)。
可选地，该授权请求消息#AA还包括Service API ID，和/或API Invoker ID。
可选地，该授权请求消息#AA还包括响应类型，和/或范围指示信息。其中，响应类型用于指示当前的授权方式，例如code指示授权码模式，token指示隐式。范围指示信息用于指示授权的范围，可以包括Service API ID和用户标识1。
示例性的，该授权请求消息#AA可以是OAuth2.0的Authorization Request消息。
S507，可选地，AuF判断当前API调用是否需要用户同意。
示例性的，AuF可以根据本地配置信息判断当前的API是否需要用户同意。例如，本地配置信息可以是一个API列表，该API列表中的所有API都是需要用户同意的API。
在一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AuF不具备用户标识1对应的UE上下文，或者用户标识1对应的UE上下文中未保存有UE的用户同意信息的情况下，AuF确定需要向RO客户端进行授权。
在另一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AuF从UDM未成功获取该UE的用户同意信息的情况下，AuF确定需要向RO客户端进行授权。
S508，AuF与RO客户端交互，以获取用户同意信息#AA。
其中，若当前的授权方式为OAuth2.0的授权码模式，该步骤的具体实现方式可参见上述图2的(c)中步骤S233-S235；或者，若当前的授权方式为OAuth2.0的隐式模式，也可以参见上述图2的(d)中步骤S243-S245。为了简洁，此处不再赘述。
S509，AuF确定授权响应消息#AA。
示例性的，基于步骤S508，若用户同意信息#AA指示用户同意授权API Invoker调用Service API以操作用户数据，则授权响应消息#AA包括具有完整性保护的token2(即，第一令牌的一例)，该token2包括用户标识1。反之，若用户同意信息#AA指示用户拒绝授权API Invoker调用Service API以操作用户数据，则授权响应消息#AA包括失败指示信息，失败指示信息用于指示用户未授权API Invoker调用Service API以操作用户数据。
S510，可选地，AEF向UDM发送签约信息更新请求消息#AA。
对应的，UDM接收来自AEF的签约信息更新请求消息#AA。
其中，该签约信息更新请求消息#AA用于更新UE的用户同意信息，该签约信息更新消息#AA可以包括以下一项或多项：用户标识2，数据处理目的，API Invoker ID，超时时间，用户同意结果。
应理解，用户标识2根据用户标识1转化而来，可以为SUPI，数据处理目的是根据Server API ID转化而来，用户同意结果可以根据步骤S508的用户同意信息#AA获得。
该实现方式中，通过AuF更新UDM上的UE签约信息，可以减少AuF请求RO授权的次数。
S511，AuF向API调用者发送授权响应消息#AA(即，授权响应消息的一例)。
对应的，API调用者接收来自AuF的授权响应消息#AA。
其中，该授权响应消息#AA包括具有完整性保护的token2，token2包括用户标识1。
S512，可选地，API调用者向AuF发送接入token请求消息#AA。
对应的，AuF接收来自API调用者的接入token请求消息#AA。
S513，可选地，AuF向API调用者发送接入token响应消息#AA。
对应的，API调用者接收来自AuF的接入token响应消息#AA。
其中，该接入token响应消息#AA包括具有完整性保护的token2，token2包括用户标识1。
需要说明的是，上述步骤S512和S513的具体实现方式可参见上述图2的(c)中步骤S237-S238。为了简洁，此处不再赘述。
S514，API调用者向AEF发送API调用请求消息#AA(即，第一API调用请求消息的一例)。
对应的，AEF接收来自API调用者的API调用请求消息#AA。
其中，该API调用请求消息#AA包括用户标识1(即，目标用户的一例)，以及具有完整性保护的token2。其中，token2包括用户标识1。
可选地，API调用请求消息#AA包括以下一项或者多项：API Invoker ID，Service API ID，token1。
可选地，该token2包括以下一项或者多项：超时时间，API Invoker ID，Service API ID，签名者。其中，签名者可以不放在token2的声明中，而放在API调用请求消息#AA上。
S515，AEF验证token2。
其中，AEF校验token2的具体实现方式可参考上述方法400中步骤S460。为了简洁，此处不再赘述。
可选地，AEF还根据API调用请求消息#AA校验token1，以确定CCF授权API Invoker访问Service API(即，目标API)。具体校验token1的实现方式可参考上述图2的(a)步骤S218。为了简洁，此处不再赘述。
需要说明的是，在上述两个token(包括token1和token2)都校验成功后，AEF将授权该API Invoker调用该Service API以操作用户的个人数据，即执行步骤S516。否则，则AEF将拒绝API Invoker的调用请求。
S516，AEF向API调用者发送API调用响应消息#AA。
对应的，API调用者接收来自AEF的API调用响应消息#AA。
其中，该API调用响应消息#AA用于返回API Invoker ID调用目标API以操作用户数据的结果。例如，授权API Invoker ID具有调用目标API以操作用户数据的权限。
示例性的，若某一服务器通过API调用请求消息#B向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AF ID设置为讨论服务器的ID，则AEF将返回API调用响应消息#B，该消息中包含该UE的外部标识，例如GPSI。
本申请所揭示的方法，结合CCF向API Invoker提供需要进行目标API授权的token1，以及通过AuF生成更细粒度的token2，使得在授权过程中考虑用户同意信息，达到AEF授权API Invoker访问某个API并调用某个用户的数据。该实现方式在处理用户数据时需要用户的授权，保护用户的隐私信息，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
图6是本申请实施例提供的通信方法600的流程示例图。与上述方法500不同之处在于，该实现方式中，CCF作为中间节点转发AuF与API Invoker之间的消息交互，可以在减少API Invoker与AuF交互信令的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。如图6所示，该方法包括如下多个步骤。
S601，API调用者向CCF发送注册请求消息#Aa，或者发现请求消息#Aa(即，第二请求消息的一例)。
对应的，CCF接收来自API调用者的注册请求消息#Aa，或者发现请求消息#Aa。
S602，CCF向API调用者发送注册响应消息#Aa，或者发现响应消息#Aa(即，第二API调用响应消息的一例)。
对应的，API调用者接收来自CCF的注册响应消息#Aa，或者发现响应消息#Aa。
其中，该注册响应消息#Aa，或者发现响应消息#Aa包括授权指示。
S603，API调用者根据授权指示确定请求AuF进行授权。
应理解，基于步骤S502中的授权指示，对于特定Service API ID，API Invoker需要额外请求AuF进行用户的授权。因此，当API Invoker准备调用特定Service API ID，且该Service API ID具有对应的授权指示时，API Invoker应根据授权指示确定AuF的地址进行授权。
其中，步骤S601-S603的具体实现方式可参考上述方法500中步骤S501-S502，以及步骤S505，为了简洁，此处不再赘述。
S604，API调用者向CCF发送授权请求消息#Aa(即，第二请求消息的一例)。
对应的，CCF接收来自API调用者的授权请求消息#Aa。
其中，该授权请求消息#Aa用于请求获取用户的授权，该授权请求消息#Aa包括Service API ID，以及用户标识1。
可选地，该授权请求消息#Aa还包括API Invoker ID。
可选地，该授权请求消息#Aa还包括响应类型，和/或范围指示信息。其中，响应类型用于指示当前的授权方式，例如code指示授权码模式，token指示隐式。范围指示信息用于指示授权的范围，可以包括Service API ID和用户标识1。
示例性的，该授权请求消息#Aa可以是OAuth2.0的Authorization Request消息。
S605，CCF向AuF发送授权请求消息#Aa。
对应的，AuF接收来自CCF的授权请求消息#Aa。
可选地，CCF可以提前预配置AuF的地址，例如API Service ID与AuF的映射关系，CCF可以根据Service API ID获得AuF的地址，进而根据AuF的地址，向AuF发送授权请求消息#Aa。
S606，AuF与RO客户端交互，以获取用户同意信息#Aa。
其中，若当前的授权方式为OAuth2.0的授权码模式，该步骤的具体实现方式可参见上述图2的(c)中步骤S233-S235；或者，若当前的授权方式为OAuth2.0的隐式模式，也可以参见上述图2的(d)中步骤S243-S245。为了简洁，此处不再赘述。
S607，AuF确定授权响应消息#Aa。
示例性的，基于步骤S606，若用户同意信息#Aa指示用户同意授权API Invoker调用Service API以操作用户数据，则授权响应消息#Aa包括具有完整性保护的token(即，第一令牌的一例)，该token包括用户标识1。反之，若用户同意信息#Aa指示用户拒绝授权API Invoker调用Service API以操作用户数据，则授权响应消息#Aa包括失败指示信息，失败指示信息用于指示用户未授权API Invoker调用Service API以操作用户数据。
S608，AuF向CCF发送授权响应消息#Aa。
对应的，CCF接收来自AuF的授权响应消息#Aa。
其中，该授权响应消息#Aa包括token#1。
S609，CCF向API调用者发送授权响应消息#Aa(即，授权响应消息的一例)。
对应的，API调用者接收来自CCF的授权响应消息#Aa。
其中，该授权响应消息#Aa包括具有完整性保护的token 2。
可选地，该token#2可以和token#1相同。
可选地，该token#2可以是由CCF生成的。CCF在接收到步骤S608的token#1后，确定生成token#2。
其中，token#2包括声明(claims)和签名，签名可以是CCF对token的数字签名。示例性的，声明中包括以下一项或者多项：超时时间，API Invoker ID，service API ID，用户标识1。
可选地，声明中还可以包括以下一项或者多项：token的生成时间、token的有效时长、token的有效的截止时间等。
可选地，声明中还可以包括其他参数，例如允许使用的资源、网络切片信息等，本申请对此不作具体限定。
S610，可选地，CCF向UDM发送签约信息更新请求消息#Aa。
对应的，UDM接收来自AEF的签约信息更新请求消息#Aa。
其中，该签约信息更新请求消息#Aa用于更新UE的用户同意信息，该签约信息更新消息#Aa可以包括以下一项或多项：用户标识2，数据处理目的，API Invoker ID，超时时间，用户同意结果。
应理解，用户标识2根据用户标识1转化而来，可以为SUPI，数据处理目的是根据Server API ID转化而来，用户同意结果可以根据步骤S606的用户同意信息#Aa获得。
该实现方式中，通过CCF更新UDM上的UE签约信息，可以减少AuF请求RO授权的次数。
S613，API调用者向AEF发送API调用请求消息#Aa(即，第一API调用请求消息的一例)。
对应的，AEF接收来自API调用者的API调用请求消息#Aa。
其中，API调用请求消息#Aa包括token#2和用户标识1。
S614，AEF验证token#2。
示例性的，若token#2为token#1，则AEF可参考步骤S460进行验证token#2。
若token#2为CCF生成，则AEF校验token#2的实现方式包括如下验证内容：
(1)AEF校验token#2的签名。AEF通过预配置的CCF的凭证(如证书)，校验token#2的签名。
(2)AEF校验token#2的声明部分.
示例性的，AEF可以判断API调用请求消息#Aa中的用户标识1是否与token中的用户标识1一致。
可选地，AEF判断API调用请求消息#Aa中的API Invoker ID是否与token中的API Invoker ID一致；或者，AEF判断API调用请求消息#Aa中的Service API ID是否与token中的Service API ID一致；或者，AEF根据token中的超时时间与当前的时间对比，判断token是否仍然有效，等等。
可选地，该token通常在有效期内可以被API Invoekr重复使用。
可选地，声明中还可以包括以下一项或者多项：token的生成时间、token的有效时长、token的有效的截止时间等。例如，token的有效时长为12h，token的生成时间为2:30，AEF接收到API调用请求消息#B的时间为12:30，则AEF在token的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求。再例如，token的有效截止时间为12:30，AEF接收到API调用请求消息#B的时间为12:00，则AEF在token的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求等。
S615，AEF向API调用者发送API调用响应消息#Aa。
对应的，API调用者接收来自AEF的API调用响应消息#Aa。
其中，该API调用响应消息#Aa用于返回API Invoker ID调用目标API以操作用户数据的结果。例如，授权API Invoker ID具有调用目标API以操作用户数据的权限。
示例性的，若某一服务器通过API调用请求消息#Aa向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AF ID设置为讨论服务器的ID，则AEF将返回API调用响应消息#Aa，该消息中包含该UE的外部标识，例如GPSI。
本申请所揭示的方法，基于图2的(a)中的token，并引入CCF作为中间节点转发API Invoker和AuF之间的消息，可以在减少API Invoker与AuF交互信令的基础上实现更细粒度的授权，使得在授权过程中考虑用户同意信息，达到AEF授权API Invoker访问某个API并调用某个用户的数据。同时，使用CCF代替AuF生成token的方式，可以减少AEF对于凭证的配置数量，而不需要配置AuF的凭证，同时也可以复用当前现有的token，不需要定义新的token，从而减少标准协议改动。该实现方式在处理用户数据时需要用户的授权，保护用户的隐私信息，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
图7是本申请实施例提供的通信方法700的流程示例图。与上述方法600不同之处在于，该实现方式仅在AEF与AuF上进行升级，可以在不影响API Invoker的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。如图7所示，该方法包括如下多个步骤。
S710，API调用者向AEF发送API调用请求消息#α。
对应的，AEF接收来自API调用者的API调用请求消息#α。
示例性的，该API调用请求消息#α用于请求调用Service API以操作用户的个人数据，该API调用请求消息#α包括API调用者的标识。
可选地，该API调用请求消息#α还包括用户标识1，和/或Service API ID。
可选地，该API调用请求消息#α本身携带Service API ID。例如，该API调用请求消息#A可以包括但不限于：定位Nnef_Location、获取Nnef_UEIdentifier_Get、订阅分析Nnwdaf_AnalyticsSubscription_Subscribe等消息。
S720，AEF判断当前API调用是否需要用户同意，并生成获取授权请求消息#α。
示例性的，AEF可以根据本地配置信息判断当前的API是否需要用户同意。例如，本地配置信息可以是一个API列表，该API列表中的所有API都是需要用户同意的API。
可选地，该API列表还可以与AuF地址对应，即每个API对应一个AuF地址，则AEF可以根据该API列表确定Service API对应的AuF地址。
在一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AEF不具备用户标识1对应的UE上下文，或者用户标识1对应的UE上下文中未保存有UE的用户同意信息的情况下，AEF确定需要向AuF进行用户授权。
在另一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AEF从UDM未成功获取该UE的用户同意信息的情况下，AEF确定需要向AuF进行用户授权。
可选地，该签约信息获取请求消息可以为Nudm_SDM_Get Request消息，该签约信息获取响应消息可以为Nudm_SDM_Get Response消息。
可选地，若AEF已经具备UE的用户同意信息，且用户同意信息指示同意该API Invoker调用该Service API以操作用户的个人数据，则AEF可以直接执行步骤S791。
S730，AEF向AuF发送获取授权请求消息#α。
对应的，AuF接收来自AEF的获取授权请求消息#α。
其中，该获取授权请求消息#α包括API Invoker ID，用户标识2，以及service API ID。其中，用户标识2是从用户标识1获得的，AEF可以通过用户标识1去其他网元获得用户标识2，以使得用户标识2可被AuF识别并确定RO的地址，即执行步骤S740-S760。
S740，可选地，AuF与RO客户端之间进行认证。
可选地，若AuF已有相关用户的认证信息，则该步骤可省略。
其中，具体的认证方式可参考现有标准中定义的认证方式，为了简洁，此处不再赘述。
S750，可选地，AuF向RO客户端发送用户同意请求消息#α。
对应的，RO客户端接收来自AuF的用户同意请求消息#α。
示例性的，基于上述步骤S740的认证成功后，AuF向RO发送用户同意请求消息#α，该用户同意请求消息#α可以包括Client ID和scope等内容。
S760，可选地，RO客户端向AuF发送用户同意响应消息#α。
对应的，AuF接收来自RO客户端的用户同意响应消息#α。
示例性的，在用户点击同意或不同意后，RO可以向AuF返回用户同意响应消息#α。
其中，上述步骤S750-S760的具体实现方式可参见上述图2的(c)中步骤S234-S235；或者，也可以参见上述图2的(d)中步骤S244-S245。为了简洁，此处不再赘述。
S770，AuF向AEF发送获取授权响应消息#α。
对应的，AEF接收来自AuF的获取授权响应消息#α。
其中，该获取授权响应消息#α包含授权结果，即用于指示用户是否同意API Invoker调用Service API以操作用户的个人数据。
其中，授权结果是AuF根据用户同意响应消息#a的内容获得的。例如，若用户点击同意，则授权结果为授权，若用户点击不同意，则授权结果为不授权。
S780，可选地，AEF向UDM发送签约信息更新请求消息#α。
对应的，UDM接收来自AEF的签约信息更新请求消息#α。
可选地，若授权结果用于指示用户授权，则AEF向UDM发送签约信息更新消息#α，该签约信息更新消息#α用于更新UE的用户同意信息。
其中，该签约信息更新消息#α可以包含以下一项或多项：用户标识2、数据处理目的、API Invoker ID、超时时间、用户同意结果。应理解，用户标识2是从用户标识1转化而来，可以为SUPI；数据处理目的由Server API ID转化而来；用户同意结果根据步骤S760获得。该实现方式中，通过AEF更新 UDM上的UE签约信息，可以减少AuF请求RO授权的次数。
S790，AEF根据授权结果确定是否授权。
示例性的，若步骤S770中的授权结果指示用户已授权，则AEF可以执行步骤S791。若授权结果指示用户不授权，则AEF可以拒绝API Invoker的API调用请求。
S791，AEF向API调用者发送API调用响应消息#α。
对应的，API调用者接收来自AEF的API调用响应消息#α。
其中，该API调用响应消息#α用于授权API Invoker ID具有调用目标API以操作用户数据的权限。例如，授权API Invoker ID具有调用目标API以操作用户数据的权限。
示例性的，若某一服务器通过API调用请求消息#Aa向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AF ID设置为讨论服务器的ID，则AEF将返回API调用响应消息#Aa，该消息中包含该UE的外部标识，例如GPSI。
本申请所揭示的方法，可以在不影响API Invoker的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据，使得在授权过程中考虑用户同意信息，达到AEF授权API Invoker访问某个API并调用某个用户的数据。该实现方式在处理用户数据时需要用户的授权，保护用户的隐私信息，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。
上文结合图1至图7，详细描述了本申请的通信方法侧实施例，下面将结合图8和图9，详细描述本申请的通信装置侧实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
图8是本申请实施例提供的通信装置的示意性框图。如图8所示，该设备1200可以包括收发单元1210和处理单元1220。收发单元1210可以与外部进行通信，处理单元1220用于进行数据处理。收发单元1210还可以称为通信接口或收发单元。
在一种可能的设计中，该设备1200可实现对应于上文方法实施例中的API调用者执行的步骤或者流程，其中，处理单元1220用于执行上文方法实施例中API调用者的处理相关的操作，收发单元1210用于执行上文方法实施例中API调用者的收发相关的操作。
示例性的，收发单元1210，用于向授权功能网元发送授权请求消息，授权请求消息包括API调用者的标识；
收发单元1210，还用于接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；
收发单元1210，还用于向API开放功能网元AEF发送第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。
在另一种可能的设计中，该设备1200可实现对应于上文方法实施例中的API开放功能网元执行的步骤或者流程，其中，收发单元1210用于执行上文方法实施例中API开放功能网元的收发相关的操作，处理单元1220用于执行上文方法实施例中API开放功能网元的处理相关的操作。
示例性的，收发单元1210，用于接收来自API调用者的第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括具有完整性保护的第一令牌和目标用户的标识，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；
处理单元1220，用于根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限；
处理单元1220，还用于根据确定结果，确定是否向API调用者提供访问目标用户的数据的权限。
在又一种可能的设计中，该设备1200可实现对应于上文方法实施例中的授权功能网元执行的步骤或者流程，其中，收发单元1210用于执行上文方法实施例中授权功能网元的收发相关的操作，处理单元1220用于执行上文方法实施例中授权功能网元的处理相关的操作。
示例性的，收发单元1210，用于接收来自应用软件编程接口API调用者的授权请求消息，授权请求消息包括API调用者的标识；
处理单元1220，用于在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网 元生成具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；
收发单元1210，还用于向API调用者发送授权响应消息，授权响应消息包括第一令牌。
在又一种可能的设计中，该设备1200可实现对应于上文方法实施例中的CCF执行的步骤或者流程，其中，收发单元1210用于执行上文方法实施例中CCF的收发相关的操作，处理单元1220用于执行上文方法实施例中CCF的处理相关的操作。
示例性的，收发单元1210，用于接收来自API调用者的第二请求消息，第二请求消息用于请求调用目标API以操作目标用户的数据，第二请求消息包括目标用户的标识和目标API的标识；收发单元1210，还用于向API调用者发送授权指示。
应理解，这里的设备1200以功能单元的形式体现。这里的术语“单元”可以指应用特有集成电路(application specific integrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。在一个可选例子中，本领域技术人员可以理解，设备1200可以具体为上述实施例中的发送端，可以用于执行上述方法实施例中与发送端对应的各个流程和/或步骤，或者，设备1200可以具体为上述实施例中的接收端，可以用于执行上述方法实施例中与接收端对应的各个流程和/或步骤，为避免重复，在此不再赘述。
上述各个方案的设备1200具有实现上述方法中发送端所执行的相应步骤的功能，或者，上述各个方案的设备1200具有实现上述方法中接收端所执行的相应步骤的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块；例如收发单元可以由收发机替代(例如，收发单元中的发送单元可以由发送机替代，收发单元中的接收单元可以由接收机替代)，其它单元，如处理单元等可以由处理器替代，分别执行各个方法实施例中的收发操作以及相关的处理操作。
此外，上述收发单元还可以是收发电路(例如可以包括接收电路和发送电路)，处理单元可以是处理电路。在本申请的实施例，图8中的装置可以是前述实施例中的接收端或发送端，也可以是芯片或者芯片系统，例如：片上系统(system on chip，SoC)。其中，收发单元可以是输入输出电路、通信接口。处理单元为该芯片上集成的处理器或者微处理器或者集成电路。在此不做限定。
图9示出了本申请实施例提供的通信装置2000。如图9所示，该设备2000包括处理器2010和收发器2020。其中，处理器2010和收发器2020通过内部连接通路互相通信，该处理器2010用于执行指令，以控制该收发器2020发送信号和/或接收信号。
可选地，该设备2000还可以包括存储器2030，该存储器2030与处理器2010、收发器2020通过内部连接通路互相通信。该存储器2030用于存储指令，该处理器2010可以执行该存储器2030中存储的指令。
在一种可能的实现方式中，设备2000用于实现上述方法实施例中的API调用者对应的各个流程和步骤。
示例性的，收发器2020，用于向授权功能网元发送授权请求消息，授权请求消息包括API调用者的标识；
收发器2020，还用于接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；
收发器2020，还用于向API开放功能网元AEF发送第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。
在另一种可能的实现方式中，设备2000用于实现上述方法实施例中的授权功能网元对应的各个流程和步骤。
示例性的，收发器2020，用于接收来自应用软件编程接口API调用者的授权请求消息，授权请求消息包括API调用者的标识；
处理器2010，用于在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元 生成具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；
收发器2020，还用于向API调用者发送授权响应消息，授权响应消息包括第一令牌。
在又一种可能的实现方式中，设备2000用于实现上述方法实施例中的AEF对应的各个流程和步骤。
示例性的，收发器2020，用于接收来自API调用者的第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括具有完整性保护的第一令牌和目标用户的标识，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；
处理器2010，用于根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限；
处理器2010，还用于根据确定结果，确定是否向API调用者提供访问目标用户的数据的权限。
在又一种可能的实现方式中，设备2000用于实现上述方法实施例中的CCF对应的各个流程和步骤。
示例性的，收发器2020，用于接收来自API调用者的第二请求消息，第二请求消息用于请求调用目标API以操作目标用户的数据，第二请求消息包括目标用户的标识和目标API的标识；
收发器2020，还用于向API调用者发送授权指示。
应理解，设备2000可以具体为上述实施例中的发送端或接收端，也可以是芯片或者芯片系统。对应的，该收发器2020可以是该芯片的收发电路，在此不做限定。具体地，该设备2000可以用于执行上述方法实施例中与发送端或接收端对应的各个步骤和/或流程。
可选地，该存储器2030可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。例如，存储器还可以存储设备类型的信息。该处理器2010可以用于执行存储器中存储的指令，并且当该处理器2010执行存储器中存储的指令时，该处理器2010用于执行上述与发送端或接收端对应的方法实施例的各个步骤和/或流程。
在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
应注意，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。本申请实施例中的处理器可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和 直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行上述所示实施例中的方法。
根据本申请实施例提供的方法，本申请还提供一种计算机可读介质，该计算机可读介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行上述所示实施例中的方法。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (51)

  1. 一种通信方法，其特征在于，包括：
    应用软件编程接口API调用者向授权功能网元发送授权请求消息，所述授权请求消息包括目标用户的标识；
    所述API调用者接收来自所述授权功能网元的授权响应消息，所述授权响应消息包括具有完整性保护的第一令牌，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；
    所述API调用者向API开放功能网元AEF发送第一API调用请求消息，所述第一API调用请求消息用于请求调用目标API以操作所述目标用户的数据，所述第一API调用请求消息包括所述目标用户的标识和所述第一令牌。
  2. 根据权利要求1所述的方法，其特征在于，在所述API调用者向授权功能网元发送授权请求消息之前，所述方法还包括：
    所述API调用者向所述AEF发送第二API调用请求消息，所述第二API调用请求消息用于请求调用所述目标API以操作所述目标用户的数据，所述第二API调用请求消息包括所述目标用户的标识；
    所述API调用者接收来自所述AEF的授权指示；其中，
    所述API调用者向授权功能网元发送授权请求消息，包括：
    所述API调用者根据所述授权指示，向所述授权功能网元发送所述授权请求消息。
  3. 根据权利要求2所述的方法，其特征在于，所述授权指示包括所述授权功能网元的地址；
    其中，所述API调用者接收来自所述AEF的授权指示，包括：
    所述API调用者接收来自所述AEF的第二API调用响应消息，所述第二API调用响应消息包括所述授权指示。
  4. 根据权利要求1所述的方法，其特征在于，在所述API调用者向授权功能网元发送授权请求消息之前，所述方法还包括：
    所述API调用者向通用API框架核心功能网元CCF发送第二请求消息，所述第二请求消息用于请求将所述API调用者注册到所述CCF，或者所述第二请求消息用于请求所述API调用者发现所述目标API；
    所述API调用者接收来自所述CCF的授权指示；
    其中，所述API调用者向授权功能网元发送授权请求消息，包括：
    所述API调用者根据所述授权指示，向所述授权功能网元发送所述授权请求消息。
  5. 根据权利要求4所述的方法，其特征在于，所述授权指示包括所述授权功能网元的地址；
    其中，所述API调用者接收来自所述CCF的授权指示，包括：
    所述API调用者接收来自所述CCF的第二API调用响应消息，所述第二API调用响应消息包括所述授权指示。
  6. 根据权利要求3或5所述的方法，其特征在于，所述第二API调用响应消息为重定向请求消息。
  7. 根据权利要求3或5所述的方法，其特征在于，所述授权指示还包括原因值，所述原因值用于指示请求操作所述目标用户的数据需要所述目标用户的授权。
  8. 根据权利要求2或4所述的方法，其特征在于，所述授权指示包括原因值，所述原因值用于指示请求操作所述目标用户的数据需要所述目标用户的授权；其中，
    所述API调用者根据所述授权指示，向所述授权功能网元发送所述授权请求消息，包括：
    所述API调用者根据所述原因值，确定所述授权功能网元的地址；
    所述API调用者根据所述授权功能网元的地址，向所述授权功能网元发送所述授权请求消息。
  9. 根据权利要求8所述的方法，其特征在于，所述API调用者根据所述原因值，确定所述授权功能网元的地址，包括：
    所述API调用者根据所述原因值，从预配置的地址列表中获取所述授权功能网元的地址。
  10. 根据权利要求2至9中任一项所述的方法，其特征在于，所述授权指示还包括授权类型，所述授权请求消息还包括响应类型；
    其中，在所述API调用者根据所述授权指示，向所述授权功能网元发送所述授权请求消息之前，所述方法还包括：
    所述API调用者根据所述授权类型确定所述响应类型。
  11. 根据权利要求1至10中任一项所述的方法，其特征在于，所述第一API调用请求消息还包括第二令牌，所述第二令牌用于指示所述API调用者具有调用所述目标API的权限，所述第二令牌包括所述API调用者的标识和所述目标API的标识；
    其中，在所述API调用者向AEF发送第一API调用请求消息之前，所述方法还包括：
    所述API调用者向通用API框架核心功能网元CCF发送第一请求消息，所述第一请求消息用于请求获取调用所述目标API的权限，所述第一请求消息包括所述API调用者的标识和所述目标API的标识；
    所述API调用者接收来自所述CCF的所述第二令牌。
  12. 根据权利要求1至11中任一项所述的方法，其特征在于，所述第一令牌包括还包括以下一项或者多项：
    超时时间；
    所述API调用者的标识；
    所述目标API的标识；
    签名者。
  13. 根据权利要求1至12中任一项所述的方法，其特征在于，所述授权请求消息还包括：
    所述目标API的标识；和/或，所述目标用户的标识。
  14. 一种通信方法，其特征在于，包括：
    应用软件编程接口API开放功能网元AEF接收来自API调用者的第一API调用请求消息，所述第一API调用请求消息用于请求调用目标API以操作目标用户的数据，所述第一API调用请求消息包括具有完整性保护的第一令牌和所述目标用户的标识，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；
    所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限；
    根据确定结果，所述AEF确定是否向所述API调用者提供访问所述目标用户的数据的权限。
  15. 根据权利要求14所述的方法，其特征在于，所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限，包括：
    所述AEF根据授权功能网元的凭证，对所述第一令牌的完整性保护进行验证，所述授权功能网元为生成所述第一令牌的网元；
    在所述第一令牌的完整性保护验证通过的情况下，所述AEF判断所述第一令牌中携带的所述目标用户的标识，是否与所述第一API调用请求消息中携带的所述目标用户的标识相同。
  16. 根据权利要求15所述的方法，其特征在于，所述第一令牌还包括签名者；
    其中，在所述AEF根据授权功能网元的凭证，对所述第一令牌进行完整性验证之前，所述方法还包括：
    所述AEF根据所述签名者，获取所述授权功能网元的凭证。
  17. 根据权利要求15或16所述的方法，其特征在于，所述第一令牌还包括所述API调用者的标识，所述第一API调用请求消息还包括所述API调用者的标识，所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限，还包括：
    所述AEF判断所述第一令牌中携带的所述API调用者的标识，是否与所述第一API调用请求消息中携带的所述API调用者的标识相同。
  18. 根据权利要求17所述的方法，其特征在于，所述第一令牌还包括所述目标API的标识，所述第一API调用请求消息还包括所述目标API的标识，所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限，还包括：
    所述AEF判断所述第一令牌中携带的所述目标API的标识，是否与所述第一API调用请求消息中携带的所述目标API的标识相同。
  19. 根据权利要求14至18中任一项所述的方法，其特征在于，所述第一API调用请求消息还包 括第二令牌；
    其中，在确定所述API调用者是否具有操作所述目标用户的数据的权限之前，所述方法还包括：
    所述AEF根据所述第二令牌，确定所述API调用者具有调用所述目标API的权限。
  20. 根据权利要求19所述的方法，其特征在于，所述第二令牌还包括所述目标API的标识，所述第一API调用请求消息还包括所述目标API的标识；
    其中，所述AEF根据所述第二令牌，确定所述API调用者具有调用所述目标API的权限，包括：
    所述AEF确定所述第二令牌中携带的所述目标API的标识，与所述第一API调用请求消息中携带的所述目标API的标识相同。
  21. 根据权利要求14至20任一项所述的方法，其特征在于，在AEF接收来自API调用者的第一API调用请求消息之前，所述方法还包括：
    所述AEF接收来自所述API调用者的第二API调用请求消息，所述第二API调用请求消息用于请求调用所述目标API以操作所述目标用户的数据，所述第二API调用请求消息包括所述目标用户的标识；
    所述AEF向所述API调用者发送授权指示，所述授权指示用于指示请求操作所述目标用户的数据需要所述目标用户的授权。
  22. 根据权利要求21所述的方法，其特征在于，所述授权指示包括所述授权功能网元的地址；
    其中，所述AEF向所述API调用者发送授权指示，包括：
    所述AEF向所述API调用者发送第二API调用响应消息，所述第二API调用响应消息包括所述授权指示。
  23. 根据权利要求22所述的方法，其特征在于，所述第二API调用响应消息为重定向请求消息。
  24. 根据权利要求21或22所述的方法，其特征在于，所述授权指示包括原因值，所述原因值用于指示请求操作所述目标用户的数据需要所述目标用户的授权。
  25. 根据权利要求8至24中任一项所述的方法，其特征在于，在所述AEF向所述API调用者发送授权指示之前，所述方法还包括：
    所述AEF确定请求操作所述目标用户的数据需要所述目标用户的授权。
  26. 根据权利要求25所述的方法，其特征在于，所述AEF确定请求操作所述目标用户的数据需要所述目标用户的授权，包括：
    所述AEF向统一数据管理功能网元UDM发送获取请求消息，所述获取请求消息用于请求获取所述目标用户的用户同意信息；
    所述AEF接收来自所述UDM的响应消息；
    所述AEF根据所述响应消息，确定请求操作所述目标用户的数据需要所述目标用户的授权。
  27. 根据权利要求26所述的方法，其特征在于，在所述AEF向所述UDM发送获取请求消息之前，所述方法还包括：
    所述AEF确定所述AEF没有保存有所述目标用户的用户同意信息，所述用户同意信息指示所述目标用户同意操作所述目标用户的数据。
  28. 根据权利要求14至27中任一项所述的方法，其特征在于，所述方法还包括：
    所述AEF向通用API框架核心功能网元CCF发送第三请求消息，所述第三请求消息用于请求获取所述API调用者调用所述目标API的访问策略，所述第三请求消息包括所述API调用者的标识和所述目标API的标识；
    其中，所述根据确定结果，所述AEF确定是否向所述API调用者提供访问所述目标用户的数据的权限，包括：
    在所述API调用者具有操作所述目标用户的数据的权限，且所述访问策略指示允许所述API调用者调用所述目标API的情况下，所述AEF向所述API调用者提供访问所述目标用户的数据的权限。
  29. 根据权利要求14至28中任一项所述的方法，其特征在于，所述方法还包括：
    在所述API调用者具有操作所述目标用户的数据的权限的情况下，所述AEF向统一数据管理功能UDM发送签约信息更新消息，所述签约信息更新消息用于更新所述目标用户的用户同意信息，所述用户同意信息用于指示所述目标用户同意操作所述目标用户的数据。
  30. 一种通信方法，其特征在于，包括：
    授权功能网元接收来自应用软件编程接口API调用者的授权请求消息，所述授权请求消息包括目标用户的标识；
    在确定所述目标用户同意所述API调用者操作所述目标用户的数据的情况下，所述授权功能网元生成具有完整性保护的第一令牌，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；
    所述授权功能网元向所述API调用者发送授权响应消息，所述授权响应消息包括所述第一令牌。
  31. 根据权利要求30所述的方法，其特征在于，所述授权请求消息还包括目标API的标识和所述目标用户的标识，所述授权功能网元生成具有完整性保护的第一令牌，包括：
    所述授权功能网元根据所述API调用者的标识、所述目标API的标识和所述目标用户的标识生成声明；
    所述授权功能网元根据所述声明生成签名；
    所述授权功能网元根据所述声明和所述签名生成所述具有完整性保护的第一令牌。
  32. 根据权利要求30或31所述的方法，其特征在于，所述第一令牌还包括以下一项或者多项：
    超时时间；
    所述API调用者的标识；
    所述目标API的标识；
    签名者。
  33. 一种通信方法，其特征在于，包括：
    通用应用软件编程接口API框架核心功能网元CCF接收来自API调用者的第二请求消息，所述第二请求消息用于请求用于将所述API调用者注册到所述CCF，或者所述第二请求消息用于请求所述API调用者发现目标API；
    所述CCF向所述API调用者发送授权指示。
  34. 根据权利要求33所述的方法，其特征在于，所述授权指示包括授权功能网元的地址；
    其中，所述CCF向所述API调用者发送授权指示，包括：
    所述CCF向所述API调用者第二响应消息，所述第二响应消息包括所述授权指示。
  35. 根据权利要求34所述的方法，其特征在于，所述第二响应消息为重定向请求消息。
  36. 根据权利要求34所述的方法，其特征在于，所述授权指示还包括原因值，所述原因值用于指示请求操作所述目标用户的数据需要所述目标用户的授权。
  37. 根据权利要求33至36中任一项所述的方法，其特征在于，所述方法还包括：
    所述CCF接收来自所述API调用者的授权请求消息，所述授权请求消息包括所述API调用者的标识、所述目标API的标识以及所述目标用户的标识；
    所述CCF向授权功能网元发送所述授权请求消息；
    所述CCF接收来自所述授权功能网元的授权响应消息，所述授权响应消息包括具有完整性保护的第一令牌，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；
    所述CCF向所述API调用者发送所述授权响应消息。
  38. 根据权利要求37所述的方法，其特征在于，在所述CCF向授权功能网元发送所述授权请求消息之前，所述方法还包括：
    所述CCF根据预配置的地址列表，确定所述授权功能网元的地址；
    所述CCF根据所述授权功能网元的地址，向所述授权功能网元发送所述授权请求消息。
  39. 根据权利要求33至38中任一项所述的方法，其特征在于，所述方法还包括：
    所述CCF接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求获取调用所述目标API的权限，所述第一请求消息包括所述API调用者的标识和所述目标API的标识；
    所述CCF向所述API调用者发送第二令牌，所述第二令牌用于指示所述API调用者具有调用所述目标API的权限，所述第二令牌包括所述API调用者的标识和所述目标API的标识。
  40. 根据权利要求33至39中任一项所述的方法，其特征在于，所述方法还包括：
    所述CCF接收来自AEF的第三请求消息，所述第三请求消息用于请求获取所述API调用者调用所述目标API的访问策略，所述访问策略用于指示是否允许所述API调用者调用所述目标API，所述第三请求消息包括所述API调用者的标识和所述目标API的标识；
    所述CCF向所述AEF发送所述访问策略。
  41. 一种通信方法，其特征在于，包括：
    授权功能网元接收来自应用软件编程接口API调用者的授权请求消息，所述授权请求消息包括目标用户的标识；
    在确定所述目标用户同意所述API调用者操作所述目标用户的数据的情况下，所述授权功能网元生成具有完整性保护的第一令牌，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；
    所述授权功能网元向所述API调用者发送授权响应消息，所述授权响应消息包括所述第一令牌；
    API开放功能网元AEF接收来自所述API调用者的所述第一API调用请求消息，所述第一API调用请求消息用于请求调用目标API以操作所述目标用户的数据，所述第一API调用请求消息包括所述第一令牌和所述目标用户的标识；
    所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限；
    所述AEF根据确定结果，确定是否向所述API调用者提供访问所述目标用户的数据的权限。
  42. 根据权利要求41所述的方法，其特征在于，在所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限之前，所述方法还包括：
    所述AEF根据第二令牌，确定所述API调用者具有调用所述目标API的权限，所述第二令牌包括所述API调用者的标识和所述目标API的标识，所述第二令牌用于指示所述API调用者具有调用所述目标API的权限。
  43. 根据权利要求42所述的方法，其特征在于，所述第一API调用请求消息还包括所述第二令牌，所述方法还包括：
    通用API框架核心功能网元CCF接收来自所述API调用者的所述第一请求消息，所述第一请求消息用于请求获取调用所述目标API的权限，所述第一请求消息包括所述API调用者的标识和所述目标API的标识；
    所述CCF向所述API调用者发送所述第二令牌，所述API调用者接收来自所述CCF的所述第二令牌。
  44. 根据权利要求41至43中任一项所述的方法，其特征在于，所述授权请求消息是根据授权指示发送的，所述方法还包括：
    通用API框架核心功能网元CCF接收来自所述API调用者的第二请求消息，所述第二请求消息用于请求将所述API调用者注册到所述CCF，或者所述第二请求消息用于请求所述API调用者发现所述目标API；
    所述CCF向所述API调用者发送所述授权指示，所述授权指示用于所述API调用者根据所述授权指示向所述授权功能网元发送所述授权请求消息。
  45. 一种通信装置，其特征在于，包括：处理器，所述处理器与存储器耦合；所述处理器，用于执行所述存储器中存储的计算机程序，以使得所述装置执行如权利要求1至13中任一项所述的方法，或以使得所述装置执行如权利要求14至29中任一项所述的方法，或以使得所述装置执行如权利要求30至32中任一项所述的方法，或以使得所述装置执行如权利要求33至40中任一项所述的方法。
  46. 一种计算机可读存储介质，其特征在于，包括：所述计算机可读存储介质上存储有计算机程序，当所述计算机程序运行时，使得所述计算机执行如权利要求1至13中任一项所述的方法，或使得所述计算机执行如权利要求14至29中任一项所述的方法，或使得所述计算机执行如权利要求30至32中任一项所述的方法，或使得所述计算机执行如权利要求33至40中任一项所述的方法。
  47. 一种通信系统，其特征在于，包括：授权功能网元和应用软件编程接口API开放功能网元AEF，其中，所述AEF用于执行如权利要求14至29中任一项所述的方法；所述授权功能网元用于执行如权利要求30至32中任一项所述的方法。
  48. 根据权利要求47所述的通信系统，其特征在于，所述通信系统还包括通用API框架核心功能 网元CCF,所述CCF用于执行如权利要求33至40中任一项所述的方法。
  49. 根据权利要求47或48所述的通信系统，其特征在于，所述通信系统还包括应用软件编程接口API调用者，所述API调用者用于执行如权利要求1至13中任一项所述的方法。
  50. 一种芯片，其特征在于，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的通信装置执行如权利要求1至13中任一项所述的方法，或者使得安装有所述芯片的通信装置执行如权利要求14至29中任一项所述的方法，或者使得安装有所述芯片的通信装置执行如权利要求30至32中任一项所述的方法，或者使得安装有所述芯片的通信装置执行如权利要求33至40中任一项所述的方法。
  51. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序代码，当所述计算机程序代码在计算机上运行时，使得所述计算机实现如权利要求1至13中任一项所述的方法，或者使得所述计算机实现如权利要求14至29中任一项所述的方法，或者使得所述计算机实现如权利要求30至32中任一项所述的方法，或者使得所述计算机实现如权利要求33至40中任一项所述的方法。
PCT/CN2023/104165 2022-08-12 2023-06-29 通信方法和通信装置 Ceased WO2024032226A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP23851453.3A EP4561136A4 (en) 2022-08-12 2023-06-29 COMMUNICATION METHOD AND COMMUNICATION APPARATUS
US19/051,003 US20250184731A1 (en) 2022-08-12 2025-02-11 Communication method and communication apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210972025.2A CN117641358A (zh) 2022-08-12 2022-08-12 通信方法和通信装置
CN202210972025.2 2022-08-12

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US19/051,003 Continuation US20250184731A1 (en) 2022-08-12 2025-02-11 Communication method and communication apparatus

Publications (1)

Publication Number Publication Date
WO2024032226A1 true WO2024032226A1 (zh) 2024-02-15

Family

ID=89850732

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/104165 Ceased WO2024032226A1 (zh) 2022-08-12 2023-06-29 通信方法和通信装置

Country Status (4)

Country Link
US (1) US20250184731A1 (zh)
EP (1) EP4561136A4 (zh)
CN (1) CN117641358A (zh)
WO (1) WO2024032226A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025251186A1 (zh) * 2024-06-04 2025-12-11 Oppo广东移动通信有限公司 通信方法和通信设备

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120982131A (zh) * 2024-03-18 2025-11-18 北京小米移动软件有限公司 通信方法、第一实体、第二实体、通信系统及存储介质
CN120111446A (zh) * 2024-07-02 2025-06-06 中兴通讯股份有限公司 通信方法、装置、存储介质及程序产品
CN121284563A (zh) * 2024-07-03 2026-01-06 华为技术有限公司 一种通信方法及装置
WO2026073452A1 (zh) * 2024-10-04 2026-04-09 北京小米移动软件有限公司 通信方法、api调用者、rof、ccf、通信系统及存储介质
WO2026078571A1 (en) * 2024-10-07 2026-04-16 Telefonaktiebolaget Lm Ericsson (Publ) Access token for invoking an application programming interface

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110309645A (zh) * 2019-04-16 2019-10-08 网宿科技股份有限公司 一种对api进行安全防护的方法、设备和系统
CN111373712A (zh) * 2017-11-16 2020-07-03 三星电子株式会社 用于认证应用程序接口(api)调用者的方法和系统
CN112352409A (zh) * 2018-04-06 2021-02-09 日本电气株式会社 下一代网络中的通用api框架所用的安全过程
WO2021176131A1 (en) * 2020-03-04 2021-09-10 Nokia Technologies Oy Enhanced authorization in communication networks

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111373712A (zh) * 2017-11-16 2020-07-03 三星电子株式会社 用于认证应用程序接口(api)调用者的方法和系统
CN112352409A (zh) * 2018-04-06 2021-02-09 日本电气株式会社 下一代网络中的通用api框架所用的安全过程
CN110309645A (zh) * 2019-04-16 2019-10-08 网宿科技股份有限公司 一种对api进行安全防护的方法、设备和系统
WO2021176131A1 (en) * 2020-03-04 2021-09-10 Nokia Technologies Oy Enhanced authorization in communication networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4561136A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025251186A1 (zh) * 2024-06-04 2025-12-11 Oppo广东移动通信有限公司 通信方法和通信设备

Also Published As

Publication number Publication date
EP4561136A4 (en) 2025-09-10
EP4561136A1 (en) 2025-05-28
CN117641358A (zh) 2024-03-01
US20250184731A1 (en) 2025-06-05

Similar Documents

Publication Publication Date Title
US20250350946A1 (en) Communication method, communication apparatus, and communication system
EP3955538B1 (en) Communication method and communication device
EP4561136A1 (en) Communication method and communication apparatus
WO2023011630A1 (zh) 授权验证的方法及装置
WO2022222745A1 (zh) 一种通信方法及装置
WO2021138822A1 (zh) 签约信息获取方法及装置
WO2024169565A1 (zh) 通信方法和通信装置
WO2024093923A1 (zh) 通信方法和通信装置
WO2024094047A1 (zh) 通信方法和通信装置
CN118945662A (zh) 装置、方法和计算机程序
WO2024078313A1 (zh) 认证授权的方法与通信装置
CN116471590A (zh) 终端接入方法、装置及鉴权服务功能网元
WO2025026454A1 (zh) 通信方法、第一功能、第二功能及存储介质
WO2024197846A1 (zh) 一种通信的方法、装置、设备、芯片和存储介质
WO2021079023A1 (en) Inter-mobile network communication security
US20250392582A1 (en) Communication method and communication apparatus
WO2025156496A1 (en) Method, device and system for ue identity privacy in communication networks
WO2025156497A1 (en) Method, device and system for ue identity privacy in communication networks
US20250358618A1 (en) Systems and methods for network-based ue service authorization
US20260075111A1 (en) Communication method and communication apparatus
KR20260059574A (ko) 서비스 api 호출 방법 및 장치
WO2025026183A1 (zh) 通信方法和通信装置
WO2025167832A1 (zh) 一种通信方法和通信装置
CN119449338A (zh) 服务api调用的方法和装置
WO2025167579A1 (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: 23851453

Country of ref document: EP

Kind code of ref document: A1

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112025002754

Country of ref document: BR

WWE Wipo information: entry into national phase

Ref document number: 2023851453

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2023851453

Country of ref document: EP

Effective date: 20250219

WWE Wipo information: entry into national phase

Ref document number: 202527020275

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 202527020275

Country of ref document: IN

WWP Wipo information: published in national office

Ref document number: 2023851453

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 112025002754

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20250211