OAuth 2.0 Authorization in 5G Core Networks: Architecture, Workflows, and Security Challenges

As a precursor to the LF Decentralized Trust Mentorship 2025 Project, “Blockchain-Based OAuth 2.0 Authorization in 5G Core Networks with Hyperledger Fabric,” this blog is the first in a series that explores the evolution of OAuth 2.0 authorization in 5G Core Networks, highlighting its current limitations and the potential of decentralized frameworks to enhance security. In this series, we will discuss how OAuth 2.0 operates in 5G, its risks, and how the integration of Hyperledger Fabric can overcome these challenges.

Introduction

As telecom networks evolve into cloud-native, service-based architectures, security becomes both more critical and more complex. Unlike the monolithic architecture of previous-generation core networks such as LTE and earlier, the 3GPP has adopted a disaggregated and cloud-native Service-Based Architecture (SBA) for the 5G Core (5GC). This shift has decomposed the core into multiple Network Functions (NFs), each responsible for a specific set of services. The microservice-based design of SBA not only supports dynamic scaling and modular deployment but also opens the door for third-party partners. These partners, often referred to as tenants or non-telco organizations, are able to offer a diverse range of services to end users.

Need for Authorization in the 5G Core?

In the 5GC, multiple NFs operate as independent services, interacting through well-defined APIs. Many of these NFs handle sensitive subscriber and network information, making access control and authorization mechanisms crucial for maintaining security and privacy. Moreover, as telecom operators open their ecosystems to non-telco tenants and partners, it becomes even more important to control access to specific NF services based on identity, context, and service scope.

To address these requirements, 3GPP has adopted the OAuth 2.0 framework for NF-to-NF authorization in the SBA. OAuth 2.0 enables fine-grained control over service access while aligning with modern cloud-native practices.

OAuth 2.0 in the 5G Core: Architecture and Workflow

3GPP defines the following OAuth 2.0 roles within the SBA:

1. Network Repository Function (NRF) – Acts as the Authorization Server
2. NF Service Consumer (NFc) – Acts as the OAuth 2.0 Client
3. NF Service Producer (NFp) – Acts as the Resource Server

In this model (Model B), NFc requests access to services provided by NFp. Using OAuth 2.0, NFc can obtain scoped access tokens from the NRF, which define what operations it may perform. The Client Credentials Grant is used for this purpose, where NFc authenticates to the NRF to receive a JSON Web Token (JWT)-based access token.

Authorization Workflow

Figure: NRF OAuth2.0 Authorization Call Flow

1. All NFs (both NFc and NFp) register their NF profiles with the NRF. This includes the services they offer and any additional required scopes

1. The NFc initiates an access token request to the NRF via the Nnrf_AccessToken_Get operation before requesting service from an NFp.
2. The request includes the NF Instance ID, expected service names, and optional additional scope (e.g., specific operations or slices).

1. NRF validates NF Instance ID, NF Type, and PLMN ID in the request against the public key certificate or NF profile.
2. NRF checks S-NSSAIs and slice authorization, ensuring that the consumer is allowed to access services of the target NF type or instance.
3. If authorization is successful, NRF issues a JWT-based access token.
4. The token includes claims like issuer, subject, audience, scope, and expiration.
5. If validation fails, NRF returns an OAuth 2.0 error response.

Note: Tokens are signed or MAC-protected using JSON Web Signature (JWS), depending on whether a public/private key pair or a symmetric key is shared between NRF and NFp.

1. Before inter-NF communication, they need to mutually authenticate each other using their TLS certificates, including verification of the subjectAltName for NF identity binding.
2. Once the NF Service Consumer receives the token, it requests service from the NF Service Producer including the access token in the message.
3. The NFp validates the token by verifying the signature using NRF’s public key or checking the MAC value using the shared secret to ensure that the NFc is authorized to access the requested service.
4. Then, It checks for token claims (subject, audience, scope, expiration, S-NSSAIs, NSI IDs, etc.)
5. If all checks succeed, the NFp processes the request. If not, it returns an OAuth 2.0 error.

1. Access tokens may be reused for subsequent requests until expiration.

This architecture supports secure, dynamic NF interaction without hard-coded credentials–enabling scalability, interoperability, and security in multi-vendor environments.

Security Limitations of OAuth 2.0 in 5GC

While OAuth 2.0 provides flexible and cloud-aligned authorization, applying it within the 5G Core exposes several security risks:

1. Fake NF Registration - Without rigorous registration policies, a rogue NF could register with the NRF and obtain valid access tokens by impersonating legitimate NFs.
2. Compromised NF Impersonation - A compromised NF may reuse credentials or manipulate its registration data to impersonate another NF and gain unauthorized access.
3. DNS spoofing/poisoning - Attackers could spoof DNS records to redirect traffic to malicious NRF instances or forge token issuer URLs, enabling fake token issuance.
4. NRF as a Single Point of Failure - The NRF manages token issuance, service discovery, and authorization. Its failure disrupts the entire NF authorization ecosystem.
5. Data Tampering & Centralized Trust - Storing sensitive profiles and authorization logic centrally in the NRF makes it a high-value target. A compromised NRF could authorize rogue NFs or tamper with tokens.

The limitations of OAuth 2.0 in the 5GC stem not only from protocol-level vulnerabilities but also from its over reliance on centralized trust. The NRF, while critical to service discovery and authorization, becomes a single point of failure both operationally and from a security perspective. Even with rigorous onboarding and certificate management, a compromised NRF or a forged registration can lead to unauthorized access across the network.

To mitigate these risks, a decentralized trust architecture is essential. One promising approach is to augment OAuth 2.0 with blockchain technology. This hybrid model distributes identity verification, token issuance, and policy enforcement across a consortium of trusted participants, removing centralized chokepoints, and enhancing both security and resilience.

Decentralized OAuth 2.0 with Hyperledger Fabric: A New Authorization Model

Among the available frameworks for building decentralized authorization infrastructure, Hyperledger Fabric stands out as an ideal candidate. Fabric is a permissioned, modular blockchain platform designed specifically for enterprise-grade, multi-party systems, aligning perfectly with the operational needs of telecom networks.

In this model, Fabric nodes can be operated by various trusted entities within or across telecom domains such as operators, vendors, and regulatory bodies. Instead of relying on a centralized NRF to issue and validate access tokens, Fabric smart contracts (chaincode) automate and decentralize key authorization functions:

1. Eliminating Single Point of Failure in NF Authentication - NF identity, public keys, and registration profiles are recorded on a distributed ledger, removing the dependency on a central NRF for authentication and discovery.
2. Immutable & Tamper-Proof NF Profiles for Enhanced Trust - Once an NF is registered, its profile becomes immutable and cryptographically anchored on the blockchain. This ensures verifiability and prevents unauthorized or manipulated re-registrations.
3. Real-Time, Distributed Access Token Verification - Instead of querying the NRF during service requests, NF Service Producers directly validate tokens using smart contracts deployed on the blockchain. This allows continuous and decentralized verification without latency or trust bottlenecks.
4. Blockchain-Managed Smart Contracts for Authorization Logic - Authorization decisions including token issuance, scope binding, and service eligibility are managed via chaincode on Hyperledger Fabric. These contracts encode policy logic and are agreed upon by all participating nodes, enabling auditable, deterministic, and decentralized authorization.
   
   

Figure: OAuth 2.0 authorization migration to blockchain. It reflects the hybrid architecture where the NRF remains present for discovery and legacy compatibility, while token issuance and validation are offloaded to a Hyperledger Fabric-based blockchain network.

This architecture preserves the flexibility and modularity of OAuth 2.0, while fundamentally redefining how trust is established, shifting from a single central authority to a decentralized federation governed by cryptographic consensus.

The integration of OAuth 2.0 with Hyperledger Fabric offers a secure, resilient, and scalable foundation for NF authorization in multi-vendor, multi-domain 5G environments. It eliminates bottlenecks, strengthens auditability, and prepares networks for secure federation, roaming, and cross-border service orchestration.

In the next blog, we’ll explore the full decentralized OAuth 2.0 workflow, from NF registration and token issuance to real-time validation using Hyperledger Fabric.