When the core became a web application — and had to be secured like one
“The 5G core speaks HTTP. That sentence is the best and the most dangerous thing about it.”
— EVERY CLOUD-NATIVE TELECOM ARCHITECT
The 5G core abandoned rigid point-to-point telecom interfaces for a web-style Service-Based Architecture: network functions are services that discover each other and call REST APIs over HTTP/2. This buys agility and cloud-native deployment — and inherits the entire threat model of web applications. This chapter covers the three pillars that secure the SBA: mutual TLS for authentication, OAuth 2.0 for authorization, and the NRF as the trust hub.
🎯 Learning objectives
Explain the SBA security stack: IP → TLS → HTTP/2 → OAuth → JSON.
Describe mutual TLS between NFs and the certificate trust chain.
Compare direct and indirect communication (models A–D) and the SCP’s role.
📘 Standards reference box — Chapter 10
Specification
Title
Release / version verified
TS 33.501
5G security — SBA security (clause 13)
Rel-18, v18.11.0 (2026-04)
TS 29.500 / 29.510
SBI general / NRF services
Rel-18/19 edition
TS 33.310
PKI / certificate enrollment
Rel-18 edition
RFC 6749 / 8725
OAuth 2.0 / JWT best practices
current
Checked June 2026 — verify against the latest 3GPP version.
10.1 The SBA Security Stack
Every inter-NF call is a layered object. From the bottom: IP transport, then TLS (mutual) for confidentiality and peer authentication, then HTTP/2 carrying RESTful requests, then an OAuth 2.0 access token authorizing the specific operation, then the JSON payload. Each layer answers a different question.
FIGURE 10.1The SBA Security Stack — Five Layers, Five Questions
Purpose: the mental model for the whole chapter. Note the two security layers are distinct: TLS proves who, OAuth proves allowed — conflating them is the root of real NRF misconfigurations (Chapter 25).
10.2 Mutual TLS Between Network Functions
In the SBA, both ends of every connection present certificates: the client NF and the server NF authenticate each other with mutual TLS (mTLS). This means a rogue process cannot impersonate an NF without a valid operator-issued certificate, and traffic is encrypted in transit. The certificates chain to an operator PKI (TS 33.310).
FIGURE 10.2mTLS — Both Ends Prove Themselves
Purpose: the authentication pillar. Unlike web one-way TLS (only the server proves itself), SBA mTLS requires both — so an NF can trust who is calling it before it even reads the request.
FIGURE 10.3The NF Certificate Trust Chain
Purpose: where NF identity comes from. The certificate’s subject encodes the NF type and instance — so mTLS doesn’t just say “a valid NF,” it says “this specific NF.”
10.3 NF Registration with the NRF
The NRF (Network Repository Function) is the SBA’s directory. Every NF, on startup, registers its profile — type, instance ID, services offered, addresses, supported slices — via Nnrf_NFManagement. The NRF authenticates the registration (mTLS) and stores the profile. This is also where rogue-NF registration must be prevented.
FIGURE 10.4NF Registration (Nnrf_NFManagement)
Purpose: how the SBA learns what exists. The NRF must authenticate registrations — an unauthenticated registration endpoint would let an attacker advertise a rogue UDM (Chapter 11/25).
FIGURE 10.5NF Discovery — With an Authorization Decision
Purpose: discovery is a security decision, not just a lookup. Restricting who can discover what limits an attacker’s map of the core even before authorization.
10.4 OAuth 2.0 — Authorizing the Operation
mTLS proves who is calling; OAuth 2.0 proves they’re allowed. The NRF acts as the authorization server: a consumer NF requests an access token (client-credentials grant) scoped to a service and a target; the producer validates the token before serving. This is what stops a compromised-but-authenticated NF from doing anything it likes.
FIGURE 10.6OAuth 2.0 Client-Credentials Grant in the 5G Core
Purpose: the authorization pillar. The token is signed by the NRF and checked by the producer — so authorization is verifiable end-to-end, not assumed from network position.
FIGURE 10.7Anatomy of an Access Token
Purpose: the claims that matter for security. Scope and audience are the difference between “authenticated NF” and “NF allowed to do exactly this, here, until expiry.”
FIGURE 10.8Producer-Side Token Validation
Purpose: what the producer must actually check. Skipping any of these — especially audience — turns OAuth into theater; the token must be validated, not merely present.
10.5 Direct and Indirect Communication
3GPP defines four communication models. A/B are direct (NF-to-NF); C/D route through the SCP (Service Communication Proxy). The security question is always: where is the token obtained, and who can be impersonated?
FIGURE 10.9Communication Models A–D
Purpose: the four models and their trust implications. The further right you go, the more the SCP concentrates — discovery, routing, and (Model D) token acquisition — which is convenient and risky in equal measure.
FIGURE 10.10The SCP in the Token Flow (Model D)
Purpose: why Model D needs extra care. A broker that fetches tokens for many consumers is a concentration of authority — protect and monitor it like the NRF itself.
10.6 Certificate Lifecycle and the SBA PKI
FIGURE 10.11Certificate Lifecycle in the Core
Purpose: the operational reality of SBA security. The cryptography is easy; the lifecycle — enroll, rotate, revoke across hundreds of instances — is where operators succeed or fail (Chapter 29).
FIGURE 10.12Why OAuth Matters — Blast Radius of a Compromised NF
Purpose: the case for OAuth in one image. Without per-operation authorization, one compromised NF owns the core; with scope/audience, it can only do what it was already allowed to do.
FIGURE 10.13An Operator’s SBA PKI Architecture
Purpose: what a real SBA PKI looks like. The root stays offline; an automated service handles the volume — because manual PKI at CNF scale is itself a security risk.
FIGURE 10.14SBI Threat Map — Where Attacks Land on the Stack
Purpose: the consolidated threat view, mapped to the stack of Figure 10.1. Every layer needs its own control; an attacker only needs the weakest one.
10.7 The Practical Operator View
Mandate mTLS on every SBI link — including “internal” ones. “Internal is safe” is the #1 SBA failure (Chapter 1 example).
Enforce OAuth token validation at producers — verify signature, scope, audience, expiry. Present-but-unvalidated tokens are worthless.
Automate the PKI: enrollment (CMPv2), rotation before expiry, revocation. Treat cert expiry as an availability risk and un-rotation as a security risk.
Harden the NRF as the crown jewel — it authenticates registrations and issues tokens (Chapter 11).
If using an SCP (Model C/D), protect and audit it like the NRF; understand who it can impersonate.
Common misconfiguration risks
Plaintext HTTP/2 between NFs in the “trusted” data center.
Mutual TLS — both ends authenticate by certificate
NRF
Network Repository Function — directory + OAuth authorization server
access token / scope / audience
OAuth authorization grant / allowed services / valid target
SCP
Service Communication Proxy — indirect-communication fabric (models C/D)
CMPv2
Certificate Management Protocol for automated enrollment (TS 33.310)
Real network example. A penetration test of a 5G core found that while mTLS was correctly enforced everywhere, one vendor’s producer NF accepted any syntactically valid token without checking the audience claim. The testers obtained a legitimate token issued for a different producer (scope was correct, audience was not) and replayed it successfully — reading subscription data they had no business accessing. The cryptography was flawless; the validation logic was incomplete. Fix: enable strict audience checking (a configuration flag the vendor shipped off by default) and add a producer-side test to the acceptance suite. OAuth only authorizes if the producer actually validates every claim.
Confirm mTLS on every SBI link, including intra-site; no plaintext HTTP/2.
Verify producers validate token signature, scope, AND audience, AND expiry.
Check token lifetimes are short and audience-bound.
Confirm certificate enrollment/rotation is automated (CMPv2) and revocation works.
Verify NRF registration is authenticated; test rogue-registration rejection.
If SCP present, confirm it is hardened, authorized, and audited like the NRF.
★ Chapter Summary
The SBA is a web-style core: IP → TLS → HTTP/2 → OAuth → JSON, inheriting web threats and web defenses.
mTLS authenticates both NFs (who); OAuth 2.0 tokens authorize the operation (allowed) — separate layers, both required.
The NRF is directory + authorization server: it authenticates registrations, answers discovery, and issues signed access tokens.
Tokens carry scope (which services) and audience (which producer) — the claims that contain a compromised NF’s blast radius.
Communication models A–D shift trust toward the SCP; Model D makes it a token broker that must be hardened like the NRF.
The hard part is the PKI lifecycle — automate enrollment, rotation, revocation, or security and availability both suffer.
? Review Questions
Map each SBA stack layer to the security question it answers.
Why is mTLS (not one-way TLS) required between NFs, and what does the certificate subject tell a producer?
An NF presents a valid certificate and a syntactically valid token. List every check the producer must still perform before serving.
Explain how scope and audience together limit a compromised NF — and what goes wrong if audience is unchecked.
Compare communication models B and D from a security standpoint. What new risk does D introduce?
Why is the NRF the SBA’s crown jewel? Name two distinct powers it holds.
Why is automated certificate lifecycle a security requirement, not just an operations convenience?
Diagnose: mTLS is enforced everywhere, but a token issued for UDM-A works at UDM-B. What is misconfigured and how do you fix it?
🧪 Mini lab — inspect SBA security in flight
With Open5GS (which uses SBI between NFs): (1) Capture inter-NF traffic and confirm whether TLS is in use; if running plaintext for the lab, observe the HTTP/2 requests and the Authorization: Bearer headers. (2) Decode an access token (it’s a JWT) and read its scope and audience claims — relate them to the call being made. (3) Find an NF discovery exchange to the NRF and a registration. (4) As a thought test, identify which single check, if skipped at the producer, would let a token for one NF be replayed at another (answer: audience). You have now seen the three SBA pillars — mTLS, OAuth, NRF — as real packets.