In the 5G service-based architecture, an AMF may discover the SBI endpoint of a UDM or SMF, but discovery alone does not grant permission to retrieve subscriber data or create a PDU session. Service-based communication makes interactions between network functions more flexible, while also exposing a broader set of core network APIs. If an NF service producer processes every reachable request without authorization checks, it cannot reliably determine whether the caller is legitimate, registered, or permitted to use the requested service.
5GC addresses this issue through an OAuth 2.0-based authorization model. An NF service consumer first requests an access token from the NRF, then presents that token when calling the target NF service producer. The producer executes the requested operation only after validating the token and its authorization claims. In this model, the NRF acts not only as a registry and discovery function, but also as the authorization server for protected SBI access.
Risks of Unprotected SBI Calls
5G standalone networks use the service-based architecture, in which network functions such as the AMF, SMF, UDM, and AUSF expose one or more services through HTTP/2-based service-based interfaces. A consumer can invoke those services through standardized HTTP APIs, reducing tight point-to-point dependencies and allowing service relationships to be created dynamically.
During UE registration, for example, the AMF may call the UDM's Nudm_SDM service to obtain subscription information. During PDU session establishment, the AMF may call the SMF's Nsmf_PDUSession service to create a session management context. Both procedures involve sensitive subscriber information or critical core network resources.
If the UDM returns subscription data solely because the request reaches the correct URI, it has no assurance that the caller is an authorized AMF. Similarly, an SMF that creates a session without validating the requester could accept calls from an untrusted or incorrectly configured network function. Endpoint reachability confirms only that communication is technically possible; it does not establish identity or authorization.
The risk becomes more significant in cloud-native deployments. NF instances may be created, scaled, upgraded, relocated, or removed as operational requirements change. A service consumer can also select different producer instances through NRF-based discovery. Static addresses and fixed peer configurations are therefore insufficient for controlling every individual service request.
5GC separates service discovery from service authorization. Discovery answers where a suitable service is available. Authorization determines whether the current consumer is allowed to use it. Before the business request is processed, the consumer must obtain a credential associated with the intended service, and the producer must validate that credential.
NRF as Authorization Server
OAuth 2.0 is a general authorization framework for controlled access between applications. It is not exclusive to mobile networks. Its standard model defines three primary roles: the client that requests access, the authorization server that issues a token, and the resource server that protects the requested resource or service.
In the 5GC SBI security model, these roles map directly to network function behavior:
| OAuth 2.0 Role | 5GC Entity | Primary Responsibility |
|---|---|---|
| Client | NF Service Consumer | Requests an access token and initiates the service call |
| Resource Server | NF Service Producer | Provides the SBI service and validates the presented token |
| Authorization Server | NRF | Evaluates the request and issues a scoped access token |
When an AMF needs to call a UDM service, the AMF acts as the NF service consumer, the UDM acts as the NF service producer, and the NRF provides the authorization function. The AMF obtains a token before calling Nudm_SDM. The UDM then checks whether the token is valid and whether its claims permit access to the requested service.
To support this process, the NRF exposes the Nnrf_AccessToken service. A token request can include information such as the consumer identity, requested service name, target NF type, consumer NF type, and client identifier. After evaluating the request, the NRF returns an access token together with related information such as token type and validity period.
The NRF does not execute the requested business operation. It defines the authorization context and issues the access credential. Subscriber data retrieval, session creation, and other service-specific operations remain the responsibility of the relevant NF service producer.
Token-Based Service Access Flow
The NF service access procedure defined for 5GC can be divided into two stages. The consumer first obtains an access token from the NRF. It then presents that token to the target producer when requesting the actual service. This separation prevents an unverified request from moving directly into business processing.
Requesting an Access Token
The NF service consumer should first have a valid identity and registration context available to the NRF. It then calls Nnrf_AccessToken and identifies the service it intends to access, the target NF type, and its own consumer information.
The NRF evaluates the request against the available registration data and authorization policy. If authorization is granted, it generates an access token and returns it to the consumer. At this point, no subscriber query, session creation, or other business operation has yet been performed. The consumer has only received permission to attempt the protected service call.
Calling the Protected Service
The consumer sends the business request to the NF service producer and includes the access token in the HTTP Authorization header. Before processing the request, the producer verifies the token's integrity, validity period, and authorization claims. The requested service is executed only when those checks succeed.
Consider PDU session establishment. The AMF first sends an HTTP/2 POST request to the NRF's Nnrf_AccessToken service, indicating that it needs access to the SMF's Nsmf_PDUSession service. After authorization, the NRF returns the token in an HTTP 200 OK response.
The AMF then sends the Nsmf_PDUSession request to the selected SMF and includes the token. The SMF validates the credential before creating the PDU session management context. If the request is accepted and the context is created successfully, the SMF can return an HTTP 201 Created response.
This sequence places authorization before business execution. Knowing the SMF address and API path is not sufficient. Without a valid token that covers the intended service, the requester should not be allowed to proceed with normal session creation.
Scope and Design Boundaries
NRF-based service discovery and NRF-based authorization are related but separate capabilities. Discovery identifies available producer instances and their supported services. Authorization decides whether a particular consumer may call one of those services. Completing discovery does not remove the need to obtain an appropriate token.
The access token is also not a substitute for business data. The NRF does not retrieve UDM subscription information or create an SMF session when it issues a token. It provides evidence that the consumer has been authorized within a defined scope. The producer remains responsible for processing the request and generating the response.
A secure implementation requires enforcement on the producer side. Requiring the consumer to request a token provides little protection if the producer does not validate token integrity, expiry, and claims before executing the service. The consumer, NRF, and producer must therefore follow compatible token-processing rules.
Authorization is also limited by scope and time. A token issued for one SBI service does not automatically grant unrestricted access to every interface exposed by other network functions. Expired tokens or tokens whose claims do not match the target service must not be treated as valid credentials.
The NRF therefore supports two distinct security-related functions in the 5G core. It maintains NF profiles and supports service discovery, helping consumers locate suitable producers. Through Nnrf_AccessToken, it also controls whether those consumers are authorized to invoke protected SBI services.
Frequently Asked Questions
Can an access token replace NF registration?
No. NF registration establishes the instance identity and its service profile. An access token provides authorization for a defined service-access context. Registration and token issuance serve different purposes.
Can one token be used with several NF instances?
That depends on the token's claims, target NF type, service scope, and applicable authorization policy. Each producer must verify that the token is valid for the current request rather than accepting it solely because it has not expired.
Do existing tokens immediately fail when the NRF is unavailable?
Behavior depends on the token format, validity period, producer-side verification method, and deployment policy. A temporary NRF outage does not automatically define the status of every previously issued token, but new token requests may be affected.
Does OAuth 2.0 encrypt SBI message content?
No. OAuth 2.0 primarily provides authorization and access control. SBI transport protection is handled through separate security mechanisms such as TLS. A valid access token should not be treated as a replacement for encrypted transport.
