SEPP Delegated Authorization for 5G Interoperability

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In 5G communications networks, incompatibilities arise when one public PLMN or network function supports OAuth 2.0 authorization while another does not, leading to service request denials and access token issues between consumer and producer NFs across different vendors or PLMNs.

Innovation Solution

The Security Edge Protection Proxy (SEPP) acts as an access token authorization client proxy to intercept service requests from consumer NFs not supporting OAuth 2.0, obtaining access tokens on their behalf and enabling access to producer NFs, and as an authorization server proxy to generate access tokens for NRFs that do not support OAuth 2.0, facilitating service access across incompatible networks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If OAuth 2.0 authorization is implemented in 5G networks, then security and standardized authorization control are improved, but interoperability between PLMNs and NFs with different authorization support is worsened

Engineering Contradiction:

Improveauthorization controlVSAvoidinteroperability

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The SEPP acts as an intermediary between consumer NFs and producer NFs with different OAuth 2.0 authorization capabilities. It implements authorization client proxy functionality to obtain access tokens on behalf of non-OAuth consumer NFs, and authorization server proxy functionality to generate tokens for non-OAuth NRFs, thereby enabling interoperability while maintaining OAuth 2.0 security standards

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If a consumer NF that does not support OAuth 2.0 sends service requests to an OAuth 2.0-requiring producer NF, then device compatibility is maintained, but service access is blocked

Engineering Contradiction:

Improveconsumer NF compatibilityVSAvoidservice access

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The SEPP implements an authorization client proxy that intercepts service requests from non-OAuth consumer NFs, obtains appropriate access tokens from OAuth 2.0 authorization servers, and attaches these tokens to the forwarded requests, enabling service access without modifying the consumer NF

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The SEPP performs preliminary authorization by obtaining access tokens before forwarding service requests from non-OAuth consumer NFs to OAuth-requiring producer NFs, ensuring that authorization is handled in advance rather than blocking the request

Inventive Principle:

Principle #10Preliminary action

3Ease of manufacture

If an NF from one vendor supports OAuth 2.0 while another vendor's NF does not, then vendor-specific implementation flexibility is maintained, but cross-vendor interoperability is worsened

Engineering Contradiction:

Improvevendor implementation flexibilityVSAvoidcross-vendor interoperability

Core Design Contradiction:

Ease of manufactureVSAdaptability or versatility

Solution Approach 1:

The SEPP implements multi-functionality by serving as both an authorization client proxy and an authorization server proxy. This universal approach allows it to handle various OAuth 2.0 authorization scenarios between different vendors' NFs, enabling cross-vendor interoperability while allowing each vendor to maintain their implementation choices

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS12192764B2Methods, systems, and computer readable media for delegated authorization at security edge protection proxy (SEPP)

Publication Date: 2025.01.07 ORACLE INT CORP

AI summary

A method for delegated authorization at a security edge protection proxy (SEPP) includes intercepting, from a consumer network function (NF) that does not support access token based authorization, a service based interface (SBI) service request for accessing a service provided by a producer NF that requires access token based authorization. The method further includes operating as an access token authorization client to obtain a first access token on behalf of the consumer NF. The method further includes using the first access token to enable the consumer NF to access the service provided by the first producer NF. The SEPP may also operate as an access token authorization server on behalf of an NRF that does not support access-token-based authorization.