Access Token Ownership Validation Through Wireless Proxy Nodes

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing OAuth 2.0 protocols in 5G Core networks lack a mechanism to validate access token ownership during indirect communication through proxy nodes, which is crucial for ensuring secure hop-by-hop communication.

Innovation Solution

Implement a trust model between the pNF, cNF, and proxy nodes using static or dynamically discovered SCPs, and employ mechanisms such as timestamping, hashing, and signature addition to ensure access token ownership validation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If direct communication between cNF and pNF is used for access token validation, then ownership validation can be performed by comparing cNF ID in certificate with authorized ID in access token, but this approach cannot be applied when communication goes through proxy nodes in hop-by-hop security scenarios

Engineering Contradiction:
Improveaccess token ownership validationVSAvoidcommunication path flexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces a Service Communication Proxy (SCP) as an intermediary node that facilitates indirect communication between cNF and pNF while maintaining security. The SCP receives service requests from cNF, forwards them to pNF, and enables hop-by-hop authentication. This mediator allows the system to maintain reliable token validation even when direct communication paths are not available, resolving the contradiction between validation reliability and communication path flexibility.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If static trust model with pre-configured SCPs is used, then trust relationships are established beforehand, but dynamic discovery of trusted SCPs using DNS or NRF is also needed for flexibility

Engineering Contradiction:
Improvetrust relationship stabilityVSAvoidtrust model configuration complexity
Core Design Contradiction:
ReliabilityVSEase of manufacture

Solution Approach 1:

The patent implements a dynamic trust model where SCPs can be discovered through multiple mechanisms including static pre-configuration, dynamic DNS-based discovery, and NRF-based service registration. This allows the system to adapt to different deployment scenarios - using static configuration for stable environments and dynamic discovery for flexible, evolving networks - thereby resolving the contradiction between trust stability and configuration complexity.

Inventive Principle:
Principle #15Dynamics

3Measurement precision

If access token includes cNF ID for ownership validation, then direct communication validation is enabled, but this mechanism fails when proxy nodes are involved in the communication path

Engineering Contradiction:
Improveownership validation accuracyVSAvoidcommunication architecture
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent extends the ownership validation mechanism from direct cNF-pNF communication to indirect communication through proxy nodes by adding a new dimension to the authentication process. The SCP performs intermediate authentication by validating the access token and establishing trust relationships, thereby maintaining validation accuracy while accommodating complex communication architectures with multiple hops.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS12463812B2Client authentication and access token ownership validation
Publication Date: 2025.11.04 MAVENIR NETWORKS INC
  • US12463812B2 patent drawing
  • US12463812B2 patent drawing
  • US12463812B2 patent drawing

AI summary

A method of performing authentication of a client for wireless communication includes: sending, by the client, a request to an authorization server via a proxy node, to obtain an access token, wherein the request to obtain the access token contains a client signature of the client; authenticating, by the authorization server, the client as a valid recipient of the access token; and authorizing, by the authorization server, the access token to the client after authenticating the client, wherein the authorization is based on at least the client signature contained in the request to obtain the access token.