Methods, systems, and computer-readable media for generating and using single-use OAuth 2.0 access tokens to protect specific service-based architecture (SBA) interfaces.

Abstract

A method for obtaining and using a single-use OAuth2.0 access token to protect a particular Service Based Architecture (SBA) interface includes a Consumer Network Function (NF) generating an access token request. The method further includes inserting a hash of at least a portion of a Service Based Interface (SBI) request message in the access token request. The method further includes sending the access token request to an NF Repository Function (NRF). The method further includes receiving an access token response from the NRF, the access token response having an OAuth2.0 access token that includes the hash of at least a portion of the SBI request message. The method further includes using the OAuth2.0 access token that includes the hash of at least a portion of the SBI request message to access an SBI service.

Description

[Technical Field]

[0001] Claim of Priority The present application claims the benefit of priority from U.S. Patent Application No. 17 / 308,972, filed on May 5, 2021, the entire disclosure of which is incorporated herein by reference.

[0002] Technical Field The subject matter described herein relates to security in telecommunication networks. More specifically, the subject matter described herein relates to methods, systems and computer-readable media for generating and using single-use OAuth 2.0 access tokens to protect a specific SBA interface. [Background Art]

[0003] Background In a 5G telecommunication network, a network function that provides a service is referred to as a producer network function (NF) or an NF service producer. A network function that consumes a service is referred to as a consumer NF or an NF service consumer. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function consumes, produces, or both consumes and produces services. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0004] A given Producer NF may have many service endpoints, each service endpoint being a contact point for one or more NF instances hosted by the Producer NF. Service endpoints are identified by a combination of an Internet Protocol (IP) address and port number, or by a fully qualified domain name that is broken down into an IP address and port number on the network node hosting the Producer NF. An NF instance is an instance of the Producer NF that provides a service. A given Producer NF may contain two or more NF instances. It should also be noted that multiple NF instances can share the same service endpoint.

[0005] Producer NFs are registered with the Network Functionality Repository (NRF). The NRF maintains service profiles of available NF instances, identifying the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably herein. Consumer NFs can subscribe to receive information about producer NF instances registered with the NRF.

[0006] In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is a Service Communication Proxy (SCP). SCPs subscribe to NRFs and obtain reachability and service profile information about producer NF service instances. Consumer NFs, SCP Connected to SCP The load balances traffic between producer NF service instances that provide the requested service, or routes traffic directly to the destination producer NF instance.

[0007] In addition to SCPs, another example of an intermediate proxy node routing traffic between producers and consumer NFs is a Security Edge Protected Proxy (SEPP). A SEPP is a network node used to protect control plane traffic exchanged between different 5G public land mobile networks (PLMNs). This allows the SEPP to perform message filtering, policing, and topology concealment for all application programming interface (API) messages transmitted between PLMNs.

[0008] One issue in 5G communication networks concerns security for certain service-based architecture (SBA) interfaces. The current security procedure for accessing an SBA interface, as defined in 3GPP® TS 33.501, is called service access permission. Messages used to access an SBA interface are called service-based interface (SBI) messages, and services provided on the interface are called SBI services. According to the service access permission procedure, a consumer NF attempting to access an SBI service provided by a producer NF must obtain an OAuth 2.0 access token from the NRF. To obtain an OAuth 2.0 access token from the NRF, the consumer NF sends an access token request to the NRF. The NRF authenticates the request, generates an access token, and returns the access token to the consumer NF. When the consumer NF attempts to access the service, it sends an SBI service request message to the producer NF. The SBI service request message contains the access token obtained from the NRF. Producer NF verifies the integrity of the claims in the access token, and if the claims are valid, Producer NF provides access to the requested service.

[0009] One problem with this architecture is that access tokens can be stolen and used by hackers to obtain services from producer NF without permission and / or to carry out denial-of-service attacks. Although access tokens have an expiration date, they can be reused, so a hacker who obtains an access token can maliciously use it to access SBI services before it expires.

[0010] Considering these and other challenges, there is a need to protect methods, improved methods, systems, and specific SBA interfaces. [Overview of the project]

[0011] overview A method for obtaining and using a single-use OAuth 2.0 access token to secure a specific service-based architecture (SBA) interface includes: a Consumer Network function (NF) generating an access token request; the method further includes inserting a hash of at least a portion of a service-based interface (SBI) request message into the access token request; the method further includes sending the access token request to an NF repository function (NRF); the method further includes receiving an access token response from the NRF, the access token response including a hash of at least a portion of the SBI request message; and the method further includes using the OAuth 2.0 access token containing the hash of at least a portion of the SBI request message to access an SBI service.

[0012] According to another aspect of the subject matter described herein, including a hash of at least a portion of an SBI request in an access token request includes adding a hash of at least a portion of an SBI request as a vendor-specific information element (IE) in a custom hypertext transfer protocol (HTTP) header or in the JavaScript® object notation (JSON) body of the access token request.

[0013] According to another aspect of the subject matter described herein, receiving an access token response having an OAuth2.0 access token that includes a hash of at least a portion of an SBI request includes receiving the access token response along with a hash of at least a portion of an SBI request as a claim of the OAuth2.0 access token.

[0014] According to another aspect of the subject matter described herein, using an OAuth2.0 access token containing a hash of at least a portion of an SBI request message to access an SBI service includes sending an SBI request message to a producer NF along with an OAuth2.0 access token containing a hash of at least a portion of an SBI request message.

[0015] According to another aspect of the subject matter described herein, sending an SBI request message to a producer NF along with an OAuth2.0 access token containing a hash of at least a portion of the SBI request message includes sending the SBI request message to a producer NF via a proxy NF.

[0016] According to another aspect of the subject matter described herein, a method for obtaining and using a single-use OAuth 2.0 access token to secure a particular service-based architecture (SBA) includes, in a proxy NF, receiving an SBI request message, generating a hash of at least a portion of the SBI request message, comparing the hash of at least a portion of the SBI request message generated by the proxy NF with the hash of at least a portion of the SBI request message contained in the OAuth 2.0 access token, and authenticating or rejecting the SBI request message based on the result of the comparison.

[0017] According to another aspect of the subject matter described herein, A proxy NF includes either a service communication proxy (SCP) or a security edge protection proxy (SEPP). nothing.

[0018] According to another aspect of the subject matter described herein, a method for obtaining and using a single-use OAuth 2.0 access token to protect a particular service-based architecture (SBA) interface includes, in a producer NF, receiving an SBI request message, generating a hash of at least a portion of the SBI request message, comparing the hash of at least a portion of the SBI request message generated by the producer NF with the hash of at least a portion of the SBI request message contained in the OAuth 2.0 access token, and authenticating or rejecting the SBI request message based on the result of the comparison.

[0019] According to another aspect of the subject matter described herein, a system is provided for obtaining and using a single-use OAuth 2.0 access token to secure a particular service-based architecture (SBA) interface. The system includes a consumer network function (NF) comprising at least one processor. The system further includes a single-use OAuth 2.0 access token requester implemented by at least one processor for generating an access token request, including a hash of at least a portion of a service-based interface (SBI) request message in the access token request, sending the access token request to an NF repository function (NRF), and receiving an access token response from the NRF, the access token response having an OAuth 2.0 access token including a hash of at least a portion of an SBI request message. The system further includes a secure SBI request message generator implemented by at least one processor for using an OAuth 2.0 access token including a hash of at least a portion of an SBI request message to access an SBI service.

[0020] According to another aspect of the subject matter described herein, a single-use OAuth 2.0 access token requester is configured to add a hash of at least a portion of the SBI request as a vendor-specific information element (IE) in a custom hypertext transfer protocol (HTTP) header or in the JavaScript object notation (JSON) body of the access token request.

[0021] According to another aspect of the subject matter described herein, a single-use OAuth2.0 access token requester is configured to receive an access token response along with a hash of at least a portion of the SBI request as a claim for the OAuth2.0 access token.

[0022] According to another aspect of the subject-matter described in the present specification, the secure SBI request message generator is configured to use an OAuth2.0 access comprising at least a hash of an SBI request message to access a service by transmitting the SBI request message together with an OAuth2.0 access token comprising at least a hash of the SBI request message to a producer NF.

[0023] According to another aspect of the subject-matter described in the present specification, a system for obtaining and using single-use OAuth2.0 access tokens to secure a specific service-based architecture (SBA) interface comprises a proxy NF, and an SBI request message generator is configured to transmit an SBI request message together with an OAuth2.0 access token comprising at least a hash of the SBI request message to a producer NF via the proxy NF.

[0024] According to another aspect of the subject-matter described in the present specification, the proxy NF is configured to receive an SBI request message, generate at least a hash of the SBI request message, compare the at least a hash of the SBI request message generated by the proxy NF with the at least a hash of the SBI request message comprised in the OAuth2.0 access token, and authenticate or reject the SBI request message based on a result of the comparison.

[0025] According to another aspect of the subject-matter described in the present specification, the proxy NF comprises one of a Service Communication Proxy (SCP) or a Security Edge Protection Proxy (SEPP).

[0026] According to another aspect of the subject matter described in this specification, in order to obtain and use single-use OAuth 2.0 access tokens to protect a specific service-based architecture (SBA) interface, comprising a producer NF, the SBI request message generator is configured to use an OAuth 2.0 access token comprising a hash of at least a portion of an SBI request message to access an SBI service by transmitting the SBI request message to the producer NF, and the producer NF is configured to receive the SBI request message, generate a hash of at least a portion of the SBI request message, compare the hash of at least a portion of the SBI request message generated by the producer NF with the hash of at least a portion of the SBI request message comprised in the OAuth 2.0 access token, and authenticate or reject the SBI request message based on a result of the comparison.

[0027] According to another aspect of the subject matter described in this specification, there is provided a system for generating and distributing single-use OAuth 2.0 access tokens to protect a specific service-based architecture (SBA) interface. The system comprises a Network Function (NF) repository function including at least one processor. The system further comprises an access token request handler implemented by at least one processor, for receiving an access token request message comprising a hash of at least a portion of a Service-Based Interface (SBI) request message from a requester, generating an access token response message comprising an OAuth 2.0 access token, including a hash of at least a portion of the SBI request message in the OAuth 2.0 access token, and transmitting the access token response message to the requester.

[0028] According to another aspect of the subject matter described herein, a system is provided for using a single-use OAuth 2.0 access token to protect a particular service-based architecture (SBA) interface. The system includes a network function (NF) comprising at least one processor. The system further includes a service-based interface (SBI) request message validator implemented by at least one processor for receiving an SBI message containing an OAuth 2.0 access token having a service-based interface (SBI) request message hash, generating a hash of at least a portion of the SBI request message, comparing the hash of at least a portion of the SBI request message generated by the proxy NF with the SBI request message hash contained in the OAuth 2.0 access token, and authenticating or rejecting the SBI request message based on the result of the comparison.

[0029] According to another aspect of the subject matter described herein, NF includes proxy NF. According to another aspect of the subject matter described herein, NF includes producer NF.

[0030] The subject matter described herein can be executed in software in combination with hardware and / or firmware. For example, the subject matter described herein can be executed in software executed by a processor. In one exemplary embodiment, the subject matter described herein can be executed using a non-temporary computer-readable medium that stores computer-executable instructions that control the computer to execute steps when executed by the computer's processor. Exemplary computer-readable media suitable for executing the subject matter described herein include non-temporary computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. In addition, the computer-readable medium for executing the subject matter described herein may be located on a single device or computing platform, or may be distributed across multiple devices or computing platforms.

[0031] Herein, exemplary embodiments of the subject matter described herein will be explained with reference to the accompanying drawings. [Brief explanation of the drawing]

[0032] [Figure 1] This is a network diagram illustrating an exemplary 5G system network architecture. [Figure 2] This message flowchart illustrates the example messages exchanged to obtain an access token from the NRF. [Figure 3] This message flowchart shows example messages exchanged when using an access token to access SBI services. [Figure 4] This diagram, created using the debugger available at https: / / jwt.io, shows an exemplary format for an OAuth 2.0 access token. [Figure 5]This message flowchart illustrates how a hacker could use a stolen OAuth 2.0 access token to access a service. [Figure 6] This message flowchart illustrates the example messages exchanged to use a single-use OAuth 2.0 access token to secure SBI services performed by Producer NF during access token validation. [Figure 7] This message flowchart illustrates the example messages exchanged to use a single-use OAuth 2.0 access token to secure an SBI service running on a proxy NF where access token validation is performed. [Figure 8] This diagram, created using the debugger available at https: / / jwt.io, shows an exemplary structure for a single-use OAuth 2.0 access token. [Figure 9] This block diagram illustrates an exemplary process for generating a hash of a portion of an SBI request message to be included in a single-use OAuth 2.0 access token. [Figure 10] This is a block diagram of a consumer NF for obtaining and using a single-use OAuth 2.0 access token to access SBI services. [Figure 11] This flowchart shows an exemplary process performed by a Consumer NF to obtain and use a single-use OAuth 2.0 access token to access a service. [Figure 12] This is a block diagram of an NRF for generating and distributing single-use OAuth 2.0 access tokens to protect a specific SBA interface. [Figure 13] This flowchart illustrates an exemplary process performed by an NRF to generate and distribute single-use OAuth 2.0 access tokens to protect a specific SBA interface. [Figure 14]This is a block diagram of a producer or proxy NF for using a single-use OAuth 2.0 access token to protect a specific SBA interface. [Figure 15] This flowchart illustrates an exemplary process performed by a producer or proxy NF to use a single-use OAuth 2.0 access token to protect a specific SBA interface. [Modes for carrying out the invention]

[0033] Detailed explanation Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. The architecture in Figure 1 includes an NRF100 and an SCP101, which may be located in the same Home Public Land Mobile Network (HPLMN). As described above, the NRF100 may maintain profiles of available producer NF service instances and their supported services, and may enable consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instance registrations. The SCP101 may also support service discovery and selection of producer NF instances. The SCP101 may perform load balancing of connections between consumer NFs and producer NFs.

[0034] NRF100 is a repository for NF or service profiles of producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the producer NF instance's NF or service profile from NRF100. An NF or service profile is a JavaScript object notation (JSON) data structure as defined in 3GPP TS 29.510. An NF or service profile definition includes at least one of the following: a fully qualified domain name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address.

[0035] In Figure 1, any of the network functions may be a consumer NF, a producer NF, or both, depending on whether they request, provide, or both provide services. In the examples shown, the NFs include a policy control function (PCF) 102 that performs policy-related operations in the network and a function that manages user data. unification Definition management (UDM) function Includes 104 and an application function (AF) 106 that provides application services.

[0036] The NF shown in Figure 1 further includes a Session Management Function (SMF) 108 that manages sessions between the Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in a 4G network. The Authentication Server Function (AUSF) 112 performs authentication services for user devices (UEs), such as user devices (UEs) 114, that request access to the network.

[0037] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices that request access to specific network capabilities and characteristics associated with a network slice. The Network Exposure Function (NEF) 118 provides an application programming interface (API) for application functions that request information about Internet of Things (IoT) devices and other UEs attached to the network. The NEF 118 performs a function similar to that of the Service Capability Exposure Function (SCEF) in a 4G network.

[0038] The Wireless Access Network (RAN) 120 connects the User Equipment (UE) 114 to the network via a wireless link. The Wireless Access Network 120 may be accessed using a g-NodeB (gNB) (not shown in Figure 1) or other wireless access point. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. One example of such a proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 may also support performance measurement functions, which may be used by the UE 114 to obtain network performance measurements. Figure 1 also shows the Data Network (DN) 124, through which the UE accesses data network services such as Internet services.

[0039] SEPP126 filters traffic coming from another PLMN and performs topology concealment for traffic leaving the home PLMN. SEPP126 may communicate with SEPP in the external PLMN that manages security for the external PLMN. Therefore, traffic between NFs in different PLMNs may traverse two SEPP functions, namely one SEPP function for the home PLMN and the other SEPP function for the external PLMN.

[0040] As mentioned above, one security issue in 5G and subsequent generation networks is that 3GPP TS 33.501 proposes the use of the OAuth2.0 framework for authorization, allowing OAuth2.0 access tokens issued by the NRF to be used multiple times before they expire. Because access tokens can be used multiple times, they can be exploited by hackers if stolen. 3GPP TS 33.501 provides no mitigation against stolen OAuth2.0 access token attacks. Subject matter described herein includes OAuth2.0 access tokens that are designated as "single-use" by carrying an SBI message hash field, authenticated by a proxy (SCP or SEPP) or producer NF in a selected SBA interface to protect against stolen OAuth2.0 access token attacks.

[0041] Section 13.4 of 3GPP TS 33.501 defines the service access token authorization procedure. Figure 2 is a message flowchart showing exemplary messages exchanged to obtain an access token from the NRF. Referring to Figure 2, in step 1 of the message flowchart, the NF service consumer 200 sends an Nnrf_AccessToken_Get request message to the OAuth2.0 authorization server, which in the context of 3GPP TS 33.501 is NRF100. The Nnrf_AccessToken_Get request message includes the expected service name, producer NF type, consumer NF type, client ID, and other parameters. In step 2 of the message flowchart, NRF100 authorizes the client and generates an OAuth2.0 access token. In line 3 of the message flowchart, NRF100 sends the access token to the NF service consumer 200 in the Nnrf_AccessToken_Get response. The access token includes an expiration date. However, the access token can still be stolen and reused before its expiration date.

[0042] Figure 3 is a message flowchart illustrating the use of an access token obtained in Figure 1 to access a service provided by Producer NF. Referring to Figure 3, in step 1, NF service consumer 200 sends an NF service request to NF service producer 300. The NF service request includes an access token obtained from NRF using the steps shown in Figure 2. In step 2 of the message flowchart, NF service producer 300 verifies the integrity and claims in the access token, and if successful, executes or provides the requested service. In step 3 of the message flowchart, NF service producer 300 sends an NF service response to NF service producer 200. Thus, Figure 3 shows that as long as the access token has valid claims, an NF service consumer or a hacker with a stolen access token can access the service provided by the NF service producer. It should be noted that the access token in Figure 3 can be used with multiple different SBI request messages and is not specific to an SBI request message or message type.

[0043] Figure 4 shows an example of an OAuth 2.0 access token in its encoded and decoded forms. More specifically, the left pane in Figure 4 shows the encoded form of the OAuth 2.0 access token, while the right pane shows the decoded form. The encoded token is used in the HTTP header when a consumer NRF makes a service access request. The OAuth 2.0 access token is signed with the NRF's private key and can be verified using the NRF's public key.

[0044] Table 1 below shows the attributes, called claims, that are included in an OAuth 2.0 access token. The complete claims data structure for an OAuth 2.0 access token is defined in Table 6.3.5.2.4-1 of 3GPP TS 29.510.

[0045] [Table 1]

[0046] Table 1 shows that an OAuth 2.0 access token includes various claims that identify the issuing NRF, producer NF, expiration date, consumer PLMN, producer network slice identifier, and producer NF set identifier. However, there are no claims in the defined format for OAuth 2.0 access tokens that would prevent a hacker from stealing the access token and using it to gain unauthorized access to services provided by the producer NF.

[0047] The following is an example of an access token claim that can be carried in an encoded text format in an OAuth2.0 access token for AMF: “iss”:“6faf1bbc-6e4a-4454-a507-a14ef8e1bc5c”, “sub”:“6faf1bbc-6e4a-4454-a507-a14ef8e1dc5d”, “aud”:[ “6faf1bbc-6e4a-4454-a507-b14ef8e1bc4c” ], “scope”:“namf-mt”, “exp”:1586169019 } In the example shown, the access token claim includes the issuer NF instance ID, consumer NF instance ID, producer NF details, token scope, and expiration date. However, as shown above, a hacker could copy the OAuth 2.0 access token claim and use the access token to access services provided by the producer NF and / or to launch a denial-of-service attack on the producer NF.

[0048] As mentioned above, 3GPP TS 33.501 proposes using OAuth2.0 access tokens for authorization for SBI communications. A hacker with access to a stolen OAuth2.0 access token can use the stolen token to invoke SBI messages on the network. The existing expiration field in OAuth2.0 access tokens does not protect against stolen token attacks. The expiration field makes attacks more difficult or limits the period during which attacks can be carried out. Reducing the expiration date does not guarantee that it cannot be exploited. Mitigation against stolen OAuth2.0 access token attacks is necessary. It should also be noted that not all SBI APIs are equal from a security and performance standpoint. Some APIs need to be highly secure (e.g., NFUpdate and NFDeregister APIs), while for other APIs, network operators may choose performance over security. There is always a trade-off between security and performance.

[0049] Figure 5 is a message flowchart illustrating both legal and illegal uses of an OAuth 2.0 access token to access services provided by Producer NF. Referring to Figure 5, in step 1, Consumer NF200 sends an access token request to NRF100. NRF100 receives the request, authenticates Consumer NF, generates an OAuth 2.0 access token, and digitally signs the OAuth 2.0 access token in step 2. In step 3, NRF100 sends the digitally signed access token to Consumer NF200 in an access token response message.

[0050] In step 4 of the message flowchart, consumer NF200 sends an SBI request message to producer NF300 via proxy 101. In step 5, proxy 101 forwards the SBI request, including the access token, to producer NF300. In step 6, producer NF300 authenticates that the access token is signed by the NRF and grants access to the requested service. In step 7, producer NF300 sends an SBI response to consumer NF200 via proxy 101. In step 8, proxy 101 sends the SBI response to consumer NF200.

[0051] In step 9 of the message flowchart, hacker 500 sends an SBI request to producer NF300 via proxy 101. The SBI request contains the stolen access token. In step 10, proxy 101 routes the SBI request containing the stolen access token to producer NF300. In step 11, producer NF300 authenticates that the access token is signed by NRF. However, no further authentication is performed. The message should be rejected as originating from the hacker, but it is not rejected. Producer NF300 provides access to the requested service. In step 12, producer NF300 sends an SBI response to hacker 500 via proxy 101. In step 13, proxy 101 forwards the SBI response to hacker 500. Thus, Figure 5 illustrates a case where the stolen access token is used by a hacker to gain unauthorized access to a service provided by producer NF.

[0052] The scenario shown in Figure 5 can be avoided by creating an OAuth2.0 access token that can only be used once, and therefore, even if the OAuth2.0 access token is stolen, it cannot be misused. To ensure that the OAuth2.0 access token can only be used once, the subject matter described herein involves adding an SBI message (HTTP header + body) hash to the OAuth2.0 access token. Adding an SBI message hash to the OAuth2.0 access token makes the OAuth2.0 access token specific to the SBI message, thereby preventing the OAuth2.0 access token from being used with an SBI message that has different parameters than those used to create the hash. As a result, whenever a consumer NF wishes to access an interface that uses single-use OAuth2.0 access token authentication, the consumer NF may be required to obtain a new OAuth2.0 access token, which degrades performance on the protected interface. However, the trade-off for the performance degradation is higher security.

[0053] Care must be taken when creating an SBI message hash. Any header or body attribute that is allowed to be modified by a proxy is excluded when creating the hash. For example, the authorization header is not part of the SBI message hash because it can be updated by SCP for reciprocal routing. Adding the SBI message hash to an OAuth2.0 access token ensures that the OAuth2.0 access token can only be used once with a given SBI message whose parameters are used to create the hash.

[0054] Single-use OAuth 2.0 access token authentication can be performed at the proxy (SCP / SEPP) or at the producer NF, depending on the operator policy. Single-use OAuth 2.0 access token authentication can be selectively enabled or disabled based on the SBI. For example, an operator may choose to enable single-use OAuth 2.0 access token authentication for APIs requiring high security, and not for other APIs.

[0055] According to the Single Use OAuth 2.0 Access Token Authentication Mechanism described herein, the Consumer NF creates an SBI request hash and sends the hash in the access token request message to the NRF. In one example, the SBI request hash is sent in a custom HTTP header of the access token request message. In an alternative example, the SBI request hash may be included in the JavaScript object notation (JSON) body of the access token request as a vendor-specific information element (IE). The NRF adds the SBI request hash received from the Consumer NF as the 3gppsbireqhash field (claim) to the access token and sends the access token to the Consumer NF. The Consumer NF sends the SBI request with the access token to the Producer NF via a proxy or directly to the Producer NF without a proxy. The Producer NF or proxy authenticates that the access token has been signed by the NRF. The Producer NF or proxy authenticates that the SBI request hash matches the 3gppsbireqhash field of the access token. If a hacker attempts to send an SBI request containing a stolen access token to Producer NF, Producer NF or the proxy will reject the request from the hacker because the SBI request hash does not match the 3gppsbireqhash field of the access token.

[0056] Figure 6 illustrates a case where a single-use OAuth 2.0 access token is generated and used by a producer NF to authenticate SBI requests from a legitimate consumer NF and reject SBI requests from an attacker. Referring to Figure 6, in step 1, consumer NF200 sends an access token request to NRF100. The access token request includes a hash of at least a portion of the SBI request message that consumer NF200 intends to send to producer NF. The hash may be generated using parameters of the SBI request that have not been modified by an intermediate node, so that the hash can be verified by producer NF. In step 2 of the message flowchart, NRF100 receives the access token request and places an OAuth 2.0 access token in its NF profile database corresponding to the producer NF identified in the access token request. NRF100 adds a hash of a portion of the SBI request message as a claim to the access token. This is a step that is not performed in conventional OAuth 2.0 access token generation. In step 3, NRF100 digitally signs an access token containing a hash of a portion of the SBI request message. In step 4 of the message flowchart, NRF100 sends an access token response to consumer NF200. The access token response contains a digitally signed access token that includes the hash of the SBI request message as a claim.

[0057] In step 5 of the message flowchart, consumer NF200 sends an SBI request to producer NF300 via proxy 101. The SBI request includes an access token. In step 6, proxy 101 forwards the SBI request to producer NF300. In step 7, producer NF300 verifies that the access token is signed by the NRF. In step 8, producer NF300 authenticates the SBI request hash in the access token. Authenticating the SBI request hash in the access token may include calculating a hash of a portion of the SBI request message and comparing the calculated hash with the hash included as a claim in the access token. In this example, it is assumed that the calculated hash matches the hash included as a claim in the access token. Therefore, in step 9, producer NF300 sends an SBI response message to consumer NF200 via proxy 101. In step 10, proxy 101 forwards the SBI response message to consumer NF200.

[0058] In step 11, hacker 500 launches an attack against producer NF300 using the stolen access token. In step 12, proxy 101 forwards the SBI request from hacker 500 to producer NF300. In step 13, producer NF300 authenticates that the access token is signed by NRF. Since the stolen access token was signed by NRF, authentication in step 13 passes. In step 14, producer NF300 attempts to authenticate the SBI request hash in the access token. However, since the SBI request parameters used to generate the hash are different from those in the SBI request message generated by hacker 500, the hash calculated by producer NF300 does not match the hash stored as a claim in the access token. Therefore, in step 15, authentication fails, and hacker 500 is prevented from accessing the services provided by producer NF300.

[0059] In Figure 6, a single-use access token is used by the producer NF to authenticate legitimate SBI service requests from the consumer NF and reject illegal SBI service requests from hackers. In an alternative embodiment, authentication may be performed at a proxy NF such as an SCP or SEPP. Figure 7 shows a case where access token authentication is performed by proxy 101. Referring to Figure 7, in step 1, the consumer NF 200 sends an access token request to the NRF 100. The access token request includes a hash of at least a portion of the SBI request message that the consumer NF 200 intends to send to the producer NF. The hash may be generated using parameters of the SBI request that have not been modified by an intermediate node, so that the hash can be verified by the producer NF. In step 2 of the message flowchart, the NRF 100 receives the access token request and places an OAuth 2.0 access token in its NF profile database corresponding to the producer NF identified in the access token request. The NRF 100 adds a hash of a portion of the SBI request message to the access token as a claim. As mentioned above, this is a step that is not performed in conventional OAuth 2.0 access token generation. In step 3, NRF300 digitally signs the access token, which includes a hash of a portion of the SBI request message. In step 4 of the message flowchart, NRF100 sends the access token response to consumer NF200. The access token response includes a digitally signed access token, which includes the hash of the SBI request message as a claim.

[0060] In step 5 of the message flowchart, consumer NF200 sends an SBI request to producer NF300 via proxy 101. The SBI request includes an access token. In step 6, proxy 101 authenticates the SBI request hash in the access token. Authenticating the SBI request hash in the access token involves calculating a hash of a portion of the SBI request message and comparing the calculated hash with the hash included as a claim in the access token. In this example, it is assumed that the calculated hash matches the hash included as a claim in the access token. Therefore, in step 7, proxy 101 forwards the SBI request to producer NF300. In step 8, producer NF300 verifies that the access token is signed by the NRF. In step 9, producer NF300 sends an SBI response message to consumer NF200 via proxy 101. In step 10, proxy 101 forwards the SBI response message to consumer NF200.

[0061] In step 11, hacker 500 initiates an attack against producer NF300 using the stolen access token by sending an SBI request to proxy 101 along with the stolen access token. In step 12, proxy 101 attempts to authenticate the SBI request hash in the access token. However, since the SBI request parameters used to generate the hash are different from those in the SBI request message generated by hacker 500, the hash calculated by proxy 101 does not match the hash stored as a claim in the access token. Therefore, in step 13, authentication fails, and hacker 500 is prevented from accessing the services provided by producer NF300.

[0062] The following is an example of an OAuth 2.0 access token for AMF, including a hash of part of the SBI request message. { “iss”:“6faf1bbc-6e4a-4454-a507-a14ef8e1bc5c”, “sub”:“6faf1bbc-6e4a-4454-a507-a14ef8e1dc5d”, “aud”:[ “6faf1bbc-6e4a-4454-a507-b14ef8e1bc4c” ], “scope”:“namf-mt”, “3gppsbireqhash”:“SBI Request Hash”, “exp”:1586169019 } In this example, the OAuth2.0 access token includes the same claims or parameters as described above. In addition, the OAuth2.0 access token includes the SBI request hash, which is a hash of a portion of the SBI request message used by the access token to authenticate.

[0063] Figure 8 shows a single-use OAuth 2.0 access token in its encoded and decoded form. The example shown in Figure 8 is similar to the example shown in Figure 4. However, as shown in Figure 8, a new SBI request hash field is added as part of the access token, which makes the access token valid only for the request message parameters used to generate the hash. If a hacker uses the access token with a request message that has different parameters than those used to generate the hash, the message will be rejected because the hash of the request message parameters will not match the hash stored in the access token claims.

[0064] As shown above, the SBI request hash may be generated by selecting HTTP header and HTTP body attributes of the SBI request that are not permitted to be modified by the proxy, depending on the operator policy. The selected HTTP headers are converted into a JavaScript Object Notation (JSON) array string. Attributes that are not permitted to be modified by the proxy are selected from the JSON body payload. The JSON header string is concatenated with the JSON body string. The hash is created for the combined strings using the same hashing algorithm used for OAuth 2.0 access tokens (or an alternative hashing algorithm selected by the network operator). A simple example of a hash may consider only the :method and :path headers of the SBI request, excluding the full body of the SBI request. This exemplary hash is simple and, moreover, powerful in evading security attacks.

[0065] Figure 9 illustrates an exemplary process for selecting parameters and generating a hash of an SBI request message. In Figure 9, the hash can include HTTP headers and HTTP body parameters of the SBI request message. From the HTTP headers, headers that are not permitted to be modified by the proxy are selected and concatenated as a JSON string. A similar process is performed for the HTTP body parameters. The HTTP headers and body parameters are concatenated into a final string. A hash of the final string is then generated and included as a claim in the OAuth 2.0 access token.

[0066] The single-use OAuth 2.0 access token feature can be enabled based on the SBA interface. For some SBA interfaces, operators may prioritize security over performance. Conversely, for other SBA interfaces, operators may prioritize performance over security. There is always a trade-off between security and performance. Configuration for single-use OAuth 2.0 access token authentication is required at each of the consumer NF, NRF, and producer / proxy NF. The consumer NF must be configured to generate and add an SBI message hash to the OAuth 2.0 access token request sent to the NRF, and to add the single-use OAuth 2.0 access token received from the NRF to the SBI request message sent to the producer NF. The NRF must be configured to extract the SBI message hash from the access token request, insert the SBI message hash as a claim into the access token, and send the modified access token to the consumer NF. The producer NF or proxy must be configured to authenticate the SBI request using the SBI message hash. The producer NF or proxy uses parameters in the SBI request message to authenticate the SBI message hash in the OAuth 2.0 access token. Table 2 below shows an exemplary SBA interface in which single-use OAuth 2.0 access token authentication can be selectively enabled or disabled.

[0067] [Table 2]

[0068] As illustrated in the examples in Table 2, single-use OAuth 2.0 access token authentication is enabled for DELETE, PUT, and PATCH operations on identified resources. However, single-use OAuth 2.0 access token authentication is disabled for unidentified resource and service operations. Single-use OAuth 2.0 access token authentication can be selectively enabled or disabled based on any combination of HTTP method, resource URI, or any other appropriate parameters in the SBI request message.

[0069] Figure 10 is a block diagram of a consumer NF200 for obtaining and using a single-use OAuth2.0 access token to access an SBI service. Referring to Figure 10, the consumer NF200 includes at least one processor 1000 and memory 1002. The consumer NF200 further includes a single-use OAuth2.0 access token requester 1004 for generating an access token request, including a hash of at least a portion of the service-based interface (SBI) request message in the access token request, sending the access token request to the NF repository function (NRF), and receiving an access token response from the NRF. The access token response has an OAuth2.0 access token that includes a hash of at least a portion of the SBI request message. For example, the single-use OAuth2.0 access token requester 1004 may be configured to request a single-use OAuth2.0 access token for a particular type of SBI request message where higher security is desired. One example of such a configuration is shown in Table 2 above. The single-use access token requester 1004 may also be configured with respect to SBI request message parameters to be used when calculating the hash to be included in the access token request message, and the hash algorithm to be used. As described above, in one example, the message parameters may be selected from those that cannot be modified by the proxy. Any suitable hash algorithm, such as Secure Hash Algorithm (SHA)-256, may be used to generate the hash.

[0070] The consumer NF200 further includes a secure SBI request message generator 1006 for using an OAuth2.0 access token that has a hash of at least a portion of the SBI request message to access an SBI service. For example, the secure SBI request message generator 1006 may formulate an SBI request message, include a single-use OAuth2.0 access token in the SBI request message, and forward the SBI request message to a producer NF that provides the requested service.

[0071] Figure 11 is a flowchart illustrating an exemplary process performed by a Consumer NF to obtain and use a single-use OAuth 2.0 access token to access a service. Referring to Figure 11, in step 1100, the process includes the Consumer NF generating an access token request. For example, Consumer NF 200 may generate an access token request in the format specified in 3GPP TS 33.501 and IETF RFC 6749.

[0072] In step 1102, the process includes including a hash of at least some of the SBI request message in the access token request. For example, Consumer NF may include in the access token request message a hash of selected SBI request message parameters of the SBI request, which Consumer NF200 is configured to use a single-use OAuth 2.0 access token for when making a request.

[0073] In step 1104, the process includes sending an access token request to the NRF. For example, consumer NF200 may send an access token request to NRF100.

[0074] In step 1106, the process includes receiving an access token response from the NRF, the access token response including a hash of at least a portion of the SBI request message. For example, consumer NF200 may receive an access token response from NRF100, the access token response including a hash as an OAuth2.0 access token claim that consumer NF200 sent to NRF100 in the access token request.

[0075] In step 1108, the process includes using an OAuth2.0 access token that contains hashes of at least some of the SBI request message in order to access the SBI service. For example, consumer NF200 may formulate and send an SBI request message to producer NF in order to access a service provided by producer NF. In the SBI request message, consumer NF200 may include an OAuth2.0 access token that contains hashes of selected parameters of the SBI request message.

[0076] Figure 12 is a block diagram of an NRF for generating and distributing single-use OAuth 2.0 access tokens to protect a specific SBA interface. Referring to Figure 12, the NRF 100 includes at least one processor 1200 and memory 1202. The NRF 100 further includes an NF profile database 1204 for storing NF profiles of producer NFs registered with the NRF 100. The NRF 100 includes an NF profile database manager 1206 for storing NF profiles in the database 1204 in response to NFRegister requests, updating NF profiles in the database 1204 in response to NFUpdate requests, and deleting NF profiles from the database 1204 in response to NFDeregister requests. The NF profile database manager 1206 may use the NF profiles stored in the database 1204 to respond to NF discovery requests from consumer NFs.

[0077] The NRF100 may also include an access token request handler 1208 for receiving an access token request message, generating a corresponding access token response message, and providing the access response message to the consumer NF. In one example, the access token request handler 1208 may generate a single-use OAuth2.0 access token and distribute it to the consumer NF. To perform this generation and distribution, the access token request handler 1208 may extract hashes of at least a portion of the service-based interface (SBI) request message from the access token request message, generate an access token response message containing the OAuth2.0 access token, and send the access token response to the requester, including the hashes of at least a portion of the SBI request message in the OAuth2.0 access token. The access token request handler 1208 may be implemented using computer-executable instructions materialized in memory 1202 and executed by processor 1200.

[0078] Figure 13 is a flowchart illustrating an exemplary process performed by an NRF to generate and distribute single-use OAuth 2.0 access tokens to protect a specific SBA interface. Referring to Figure 13, in step 1300, the process includes receiving an access token request message from a requester that contains a hash of at least a portion of a service-based interface (SBI) request message. For example, NRF 100 may receive an access token request from a consumer NF, the access token request containing a hash of an SBI request message that the consumer NF is configured to protect using a single-use OAuth 2.0 access token.

[0079] In step 1302, the process includes generating an access token response message containing an OAuth2.0 access token. For example, NRF100 may generate an access token response, and the access token response may include an OAuth2.0 access token that can be used to access the service identified in the access token request message.

[0080] In step 1304, the process includes including or inserting hashes of at least a portion of the SBI request message into the OAuth2.0 access token. For example, NRF100 may extract hashes of at least a portion of the SBI request message from the access token request message and insert at least a portion of the hashes of the SBI request message as claims into the OAuth2.0 access token.

[0081] In step 1306, the process includes sending an access token response message to the requester. For example, NRF100 may send an OAuth2.0 access token to the requesting consumer NF.

[0082] Figure 14 is a block diagram of a producer or proxy NF for using a single-use OAuth2.0 access token to protect a specific SBA interface. Referring to Figure 14, the producer or proxy NF 300 or 101 includes at least one processor 1400 and memory 1402. The producer or proxy NF 300 or 101 further includes a service-based interface (SBI) request message validator 1404. The SBI request message validator 1404 may authenticate an SBI request message by extracting a hash of a portion of the message from the OAuth2.0 access token received with the SBI request message, calculating a hash of the corresponding portion of the message, comparing the calculated hash with the hash extracted from the message, and authenticating or rejecting the message based on whether the calculated hash matches the hash extracted from the single-use OAuth2.0 access token. For this purpose, a specific SBI message on which the SBI request message validator 1404 performs single-use OAuth2.0 access token authentication may be configured by the network operator along with SBI message parameters and a hash algorithm used to generate the hash. Any suitable hash algorithm may be used. In one example, a secure hash algorithm such as Secure Hash Algorithm (SHA)-256 may be used to generate the hash. If the computed hash matches the hash extracted from the single-use OAuth 2.0 access token, the SBI request message validator 1404 authenticates the SBI request and provides access to the requested service. If the computed hash does not match the hash extracted from the single-use OAuth 2.0 access token, the SBI request message validator 1404 rejects the SBI request and prevents the requester from accessing the service.The SBI request message validator 1404 may be implemented using computer executable instructions that are materialized in memory 1402 and executed by processor 140.

[0083] Figure 15 is a flowchart illustrating an exemplary process performed by a producer or proxy NF to secure a specific SBA interface using a single-use OAuth 2.0 access token. Referring to Figure 15, in step 1500, the process includes receiving an SBI request message containing a single-use OAuth 2.0 access token. For example, a producer or proxy NF 300 or 101 may receive an SBI request to access a service, the SBI request containing a single-use OAuth 2.0 access token, formatted as described herein and including a hash of at least a portion of the SBI request message.

[0084] In step 1502, the process includes generating hashes of at least a portion of the SBI request message. For example, a producer or proxy NF300 or 101 may generate hashes of predetermined parameters of the SBI request message, the parameters and hash algorithm used being determined by the network operator.

[0085] In step 1504, the process includes comparing the hashes of at least a portion of the SBI request message generated by the producer or proxy NF with the hashes of at least a portion of the SBI request message contained in the OAuth2.0 access token. For example, the producer or proxy NF300 or 101 may compare the calculated hashes with the hashes contained in the OAuth2.0 access token received in the SBI request message.

[0086] In step 1506, the process includes authenticating or rejecting the SBI request message based on the result of the comparison. For example, the producer or proxy NF300 or 101 may authenticate the request and grant access to the service if the calculated hash matches the hash in the OAuth2.0 access token. The producer or proxy NF300 or 101 may reject the SBI request and deny access to the service if the calculated hash does not match the hash in the OAuth2.0 access token.

[0087] The following are exemplary advantages of the subject matter described herein: Single-use OAuth 2.0 access token authentication can prevent security attacks that attempt to use stolen OAuth 2.0 access tokens. This is important because such security attacks can result in a complete network failure. The solution can be enabled on selected 5G SBA interfaces, providing the benefits of both improved security and performance. When implemented in SCP or SEPP, single-use OAuth 2.0 access token authentication offers the advantage of centralized configuration for configuring features in all or even a subset of producer NFs. Single-use OAuth 2.0 access token authentication is extensible to both intra-PLMN and inter-PLMN messages. Single-use OAuth 2.0 access token authentication can be performed in SCP, SEPP, and / or Producer NF. Examples of NFs with single-use OAuth 2.0 access token authentication include SCP, NRF, NSSF, PCF, and Binding Support Function (BSF). unification This includes a data repository (UDR), NEF, SEPP, or any other NF shown in Figure 1.

[0088] Each of the following references is incorporated herein by reference in its entirety. reference object 1.3rd Generation Partnership Project;Technical Specification Group Services and System architecture for the 5G System(5GS);Stage2(Release 17)3GPP TS 23.501 V17.0.0(2021-03) 2.3rd Generation Partnership Project;Technical Specification Group Core Network and Terminals;5G System;Network Function Repository Services;Stage 3(Rrelease 17)3GPP TS 29.510 V17.0.0(2020-12) 3.Hardt, “The OAuth2.0 Authorization Framework,” IETF RFC 6749 (October 2012) It is understood that various details of the subject matter described herein may be modified without departing from the scope of the subject matter described herein. Furthermore, since the subject matter described herein is defined by the claims set forth below, the foregoing description is for illustrative purposes only and not for limiting purposes.

Claims

1. A method for obtaining and using a single-use OAuth 2.0 access token to protect a specific service-based architecture (SBA) interface, wherein the method is: The Consumer Network Function (NF) generates an access token request, The access token request includes the step of including a hash of at least a portion of the service-based interface (SBI) request message, The steps include sending the aforementioned access token request to the NF repository function (NRF), The method includes the step of receiving an access token response from the NRF, wherein the access token response has an OAuth2.0 access token which includes the hash of at least a portion of the SBI request message, and the method is A method comprising the step of using the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, in order to access the SBI service.

2. The method according to claim 1, wherein the step of including the hash of at least a portion of the SBI request message in the access token request includes the step of adding the hash of at least a portion of the SBI request message as a vendor-specific information element (IE) in a custom hypertext transfer protocol (HTTP) header or in the JavaScript object notation (JSON) body of the access token request.

3. The method according to claim 1, wherein the step of receiving the access token response having the OAuth2.0 access token which includes the hash of at least a portion of the SBI request message is further the step of receiving the access token response having the hash of at least a portion of the SBI request message as a claim of the OAuth2.0 access token.

4. The method according to claim 1, wherein the step of using the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, to access the SBI service includes sending the SBI request message having the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, to a producer NF.

5. The method according to claim 4, wherein the step of sending the SBI request message having the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, to the producer NF includes the step of sending the SBI request message to the producer NF via a proxy NF.

6. The method according to claim 5, wherein the proxy NF includes the steps of: receiving the SBI request message; generating a hash of at least a portion of the SBI request message; comparing the hash of at least a portion of the SBI request message generated by the proxy NF with the hash of at least a portion of the SBI request message contained in the OAuth2.0 access token; and authenticating or rejecting the SBI request message based on the result of the comparison step.

7. The method according to claim 5, wherein the proxy NF includes one of a service communication proxy (SCP) and a security edge protection proxy (SEPP).

8. The method according to claim 4, wherein the producer NF includes the steps of: receiving the SBI request message; generating a hash of at least a portion of the SBI request message; comparing the hash of at least a portion of the SBI request message generated by the producer NF with the hash of at least a portion of the SBI request message contained in the OAuth2.0 access token; and authenticating or rejecting the SBI request message based on the result of the comparison step.

9. A system for obtaining and using a single-use OAuth 2.0 access token to protect a specific service-based architecture (SBA) interface, wherein the system is Consumer networking (NF) functionality including at least one processor, A single-use OAuth 2.0 access token requester implemented by at least one processor includes generating an access token request, including a hash of at least a portion of a service-based interface (SBI) request message in the access token request, sending the access token request to an NF repository function (NRF), and receiving an access token response from the NRF, wherein the access token response has an OAuth 2.0 access token including the hash of at least a portion of the SBI request message. The aforementioned system, A system further comprising a secure SBI request message generator implemented by at least one processor for using the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, to access the SBI service.

10. The system according to claim 9, wherein the single-use OAuth 2.0 access token requester is configured to add at least a portion of the hash of the SBI request message as a vendor-specific information element (IE) in a custom hypertext transfer protocol (HTTP) header or in the JavaScript object notation (JSON) body of the access token request.

11. The system according to claim 9, wherein the single-use OAuth2.0 access token requester is configured to receive the access token response having the hash of at least a portion of the SBI request message as a claim of the OAuth2.0 access token.

12. The system according to any one of claims 9 to 11, wherein the secure SBI request message generator is configured to use the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, to access the service by sending the SBI request message having the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, to the producer NF.

13. The system according to claim 12, comprising a proxy NF, wherein the secure SBI request message generator is configured to send the SBI request message having the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, to the producer NF via the proxy NF.

14. The system according to claim 13, wherein the proxy NF is configured to receive the SBI request message, generate a hash of at least a portion of the SBI request message, compare the hash of at least a portion of the SBI request message generated by the proxy NF with the hash of at least a portion of the SBI request message contained in the OAuth2.0 access token, and authenticate or reject the SBI request message based on the result of the comparison.

15. The system according to claim 13, wherein the proxy NF includes one of a service communication proxy (SCP) or a security edge protection proxy (SEPP).

16. The system according to any one of claims 9 to 11, comprising a producer NF, wherein the secure SBI request message generator is configured to use the OAuth2.0 access token, which includes the hash of at least a portion of the SBI request message, in order to access the SBI service by sending the SBI request message to the producer NF, the producer NF is configured to receive the SBI request message, generate the hash of at least a portion of the SBI request message, compare the hash of at least a portion of the SBI request message generated by the producer NF with the hash of at least a portion of the SBI request message contained in the OAuth2.0 access token, and authenticate or reject the SBI request message based on the result of the comparison.

17. A system for generating and distributing single-use OAuth 2.0 access tokens to protect a specific service-based architecture (SBA) interface, wherein the system is A network function (NF) repository function (NRF) including at least one processor, A system comprising: an access token request handler implemented by at least one processor for receiving an access token request message from a requester, which includes a hash of at least a portion of a service-based interface (SBI) request message; generating an access token response message which includes an OAuth 2.0 access token; and sending the access token response message to the requester, which includes the hash of at least a portion of the SBI request message in the OAuth 2.0 access token.

18. A system for using a single-use OAuth 2.0 access token to protect a specific service-based architecture (SBA) interface, wherein the system is Network functionality (NF) including at least one processor, A system comprising a service-based interface (SBI) request message validator implemented by at least one processor for receiving an SBI request message containing an OAuth2.0 access token having an SBI request message hash, generating a hash of at least a portion of the SBI request message, comparing the hash of at least a portion of the SBI request message generated by the NF with the SBI request message hash contained in the OAuth2.0 access token, and authenticating or rejecting the SBI request message based on the result of the comparison.

19. The system according to claim 18, wherein the NF includes a proxy NF that includes the SBI request message validator.

20. The system according to claim 18, wherein the NF includes a producer NF that includes the SBI request message validator.

21. A program for causing a computer to perform the method described in any one of claims 1 to 8.

Images