Two-Level Security Token Validation for Client-Specific Revocation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing security token validation systems lack efficient mechanisms for ensuring token validity and revocation, particularly in scenarios where tokens are stolen or breached, leading to potential unauthorized access.

Innovation Solution

A two-level validation system is implemented, where security tokens are validated using both a public key of an authentication server and a client-specific identifier, allowing for precise and efficient revocation of tokens by regenerating client-specific identifiers, thereby enhancing security and performance.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional security token validation is used, then authentication can be performed, but tokens cannot be efficiently revoked leading to potential unauthorized access

Engineering Contradiction:
Improvetoken validation reliabilityVSAvoidvalidation system complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The validation system is segmented into two independent levels: (1) cryptographic signature validation using the authentication server's public key, and (2) client identifier validation by checking against revoked identifiers. This segmentation allows tokens to be revoked by invalidating client identifiers without affecting the cryptographic validation mechanism, enabling efficient revocation while maintaining system reliability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A validation system component acts as an intermediary between the authentication server and application servers. This intermediary maintains a collection of revoked client identifiers and performs the second level of validation, mediating between token presentation and access decision. This intermediary enables efficient revocation checks without requiring direct communication between application servers and the authentication server for each validation.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of operation

If tokens are validated using only public key cryptography, then validation is simple, but stolen tokens cannot be revoked

Engineering Contradiction:
Improvevalidation simplicityVSAvoidtoken revocation capability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The validation process is divided into two distinct steps: first, cryptographic signature verification using the authentication server's public key (maintaining simplicity), and second, client identifier validation by checking against a collection of revoked identifiers (enabling revocation). This segmentation allows both simplicity and revocation capability to coexist.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Client identifiers are pre-associated with specific clients and stored in a revocable manner. When a token is issued, the associated client identifier is recorded. Before validation, the system prepares a collection of revoked client identifiers. During validation, this pre-prepared collection is checked against the token's client identifier, enabling efficient revocation without complicating the validation process.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If client identifiers are validated against stored values, then precise token revocation is enabled, but validation time increases

Engineering Contradiction:
Improveprecise token revocationVSAvoidvalidation time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The validation system performs a focused check only on the client identifier against the collection of revoked identifiers, rather than re-validating the entire token or communicating with the authentication server. This partial validation approach provides precise revocation capability while minimizing validation time by performing only the necessary additional check.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The validation system maintains its own local collection of revoked client identifiers and performs self-contained validation without requiring external communication. The system serves its own revocation needs by maintaining and checking against its internal collection, eliminating network latency and dependency on the authentication server for each validation request.

Inventive Principle:
Principle #25Self-service

4Reliability

If a two-level validation system is implemented, then token security is enhanced, but system complexity increases

Engineering Contradiction:
Improvesecurity enhancementVSAvoidsystem structure complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The two-level validation system is segmented into distinct, well-defined components: the authentication server that issues tokens, the validation system that maintains revoked identifier collections, and the validation logic that performs sequential checks. Each component has a specific responsibility, making the overall system manageable despite its enhanced security capabilities.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The validation system acts as an intermediary component that bridges the authentication server and application servers. It maintains the collection of revoked client identifiers and performs the second level of validation, mediating between token issuance and token verification. This intermediary structure organizes the complexity into a manageable architecture with clear separation of concerns.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP4002758B1Security token validation
Publication Date: 2025.11.05 SAP SE
  • EP4002758B1 patent drawingFigure 1
  • EP4002758B1 patent drawingFigure 2
  • EP4002758B1 patent drawingFigure 3

AI summary

The present disclosure relates to computer-implemented methods, software, and systems for validating and revoking security tokens. A request for a resource is received at an application server and from a client. The request is associated with a security token for authenticating the client by the application server. A public key of an authentication server is acquired at the application server for authenticating requests at the application server. A signature of the security token is validated at the application server. By validating the signature of the security token, it is determined whether the security token is validly issued by the authentication server. In response to the received request, the application server determines at an identifier that is associated with the client and validates the security token based on the identifier to determine whether to serve the received request and provide the resource.