Description
JSON Web Token (JWT) is a standardized token format that encodes claims as a JSON object, which is then digitally signed or encrypted to ensure security. In 3GPP networks, JWT serves as a means to convey identity, permissions, and other attributes between entities, such as between user equipment and network functions or between different core network elements. A JWT is composed of three parts: a header, a payload, and a signature (or an encryption envelope if using JWE). The header typically specifies the token type (JWT) and the cryptographic algorithm used for signing or encryption (e.g., HS256 for HMAC SHA-256). The payload contains the claims, which are statements about an entity (e.g., user identity, subscription data, expiration time) and are categorized as registered, public, or private claims. The signature is generated by signing the encoded header and payload with a secret or private key, resulting in a compact string that can be easily transmitted in HTTP headers or URLs.
Within 3GPP architecture, JWT is integral to authentication and authorization mechanisms, particularly in 5G service-based interfaces. For instance, in the 5G Authentication and Key Agreement (5G AKA) framework, JWTs can be used as access tokens to grant permissions to network functions based on OAuth 2.0 principles. The token is issued by an authorization server (such as the Network Exposure Function or a dedicated OAuth server) after successful authentication, and it includes claims like issuer, subject, audience, and expiration. When a network function receives a JWT, it validates the signature using the issuer's public key, checks the claims for validity (e.g., ensuring it is not expired and is intended for the correct audience), and then uses the contained information to make authorization decisions. This process enables stateless authentication, as the token itself carries all necessary data, reducing the need for server-side session storage and improving scalability.
JWT's role extends to various 3GPP specifications, including those for security, network exposure, and edge computing. It is used in scenarios like secure service access for third-party applications, where a JWT might encapsulate user consent or API quotas, and in roaming agreements, where tokens facilitate trust between operators. The token can be signed with JWS for integrity or encrypted with JWE for confidentiality, depending on the sensitivity of the claims. This flexibility allows JWT to adapt to different security requirements, from public claims that can be read by anyone to private claims that must be protected. By adopting JWT, 3GPP aligns with web standards (IETF RFC 7519), ensuring interoperability with existing identity systems and simplifying integration with cloud-native applications. This makes JWT a cornerstone for enabling secure, efficient, and scalable communications in modern telecommunications networks, supporting features like network slicing, IoT device authentication, and dynamic policy enforcement.
Purpose & Motivation
JWT was introduced in 3GPP to address the limitations of traditional session-based authentication and binary token formats in increasingly distributed and API-driven network environments. Prior to its adoption, 3GPP systems often used proprietary or complex mechanisms for token exchange, such as SAML assertions or custom binary protocols, which were heavyweight, difficult to parse in web contexts, and required stateful servers to manage sessions. These approaches posed challenges for scalability and interoperability, especially as networks evolved to support microservices architectures and external API integrations. JWT solves these problems by providing a lightweight, JSON-based token that is self-contained, carrying all necessary information in its payload, and easily transmitted over HTTP, making it ideal for stateless authentication in service-based cores.
The motivation for JWT in 3GPP stems from the need for efficient and secure identity management in 5G and beyond, where diverse services and devices require seamless authentication across domains. With the rise of network exposure and edge computing, there was a demand for a standardized token format that could be used by third-party applications and network functions alike, without relying on centralized session stores. JWT meets this demand by enabling claims-based identity, where tokens can be issued once and verified by multiple parties, reducing latency and simplifying security workflows. By incorporating JWT into specifications like 33.122 and 33.938, 3GPP leveraged its widespread adoption in the web ecosystem to enhance security for roaming, API access, and user authentication, addressing issues like token replay and expiration while supporting the dynamic, scalable nature of modern telecommunications networks.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (9 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-14, normative work from Rel-15.
In Release 15, the JWT function was newly introduced specifically for the Common API Framework (CAPIF) to enable secure API invoker onboarding and northbound API authorization. It defined the use of OAuth 2.0 access tokens encoded as JSON Web Tokens (JWT) for authentication on interfaces like CAPIF-1e and CAPIF-2e, including procedures for token request, validation, and a specific profile for Resource Owner Network Authorization (RNAA) requiring claims like the resource owner ID (GPSI). This provided a standardized, token-based security method for authorizing API invocations between network functions.
In Release 18, the JWT function was enhanced with a specific profile for access tokens used in RNAA (Restricted Network Access Authentication), including the mandatory inclusion of a resource owner ID (GPSI) and an API invoker ID within the token claims. It also introduced a formal revocation procedure for RNAA-related tokens, allowing the CAPIF core function to notify API exposing functions of revoked tokens, which must then be checked before honoring API invocations. Furthermore, corrections and clarifications were made regarding authorization and token request procedures.
In Release 19, the JWT function was enhanced to support Recording Network API Authorization (RNAA) by mandating that access tokens include a specific `resOwnerId` claim containing the resource owner's GPSI. This allows the API Exposing Function to authorize API invocations for a specific user's resources directly via the token, eliminating the need for separate UE authentication. Additionally, procedures were defined for token revocation specific to RNAA scenarios.
Explore further
Broader topics and technologies where JWT plays a role.
Defining Specifications
3GPP specifications that define or reference JWT, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 33.122 vj20 | Security Architecture for CAPIF | Rel-19 |
| TS 33.180 vk00 | Security of Mission Critical (MC) Service | Rel-20 |
| TS 33.880 vf10 | Security Study for Enhanced Mission Critical Services | Rel-15 |
| TR 33.938 vj10 | 3GPP Cryptographic Inventory for 5G | Rel-19 |