Token Transformation Filter for Microservice Authorization

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multi-vendor cloud applications, existing technologies face challenges in enforcing zero-trust policies for authorization tokens without introducing single points of failure or incurring high performance costs, particularly in environments with fast inter-service communication and distributed microservices.

Innovation Solution

The technology enables granular sharing of authorization tokens among microservices in a microservice chain by transforming and securing them in real-time using OAuth 2.0 standards, allowing only necessary information to be accessed by each service, thereby preventing information leaks and reducing dependency on central authorization servers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If authorization tokens are passed around among microservices, then inter-service communication is enabled, but information leaking and security risks increase

Engineering Contradiction:
Improveinter-service communication speedVSAvoidinformation leaking
Core Design Contradiction:
ProductivityVSObject-affected harmful factors

Solution Approach 1:

The patent segments the authorization token into multiple encrypted portions, each containing specific authorization claims. Each microservice receives only the token portion it needs, rather than the complete token. This segmentation prevents information leaking by ensuring that no single service can access unauthorized information contained in other portions of the token.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies local quality by encrypting different portions of the authorization token with different encryption keys specific to each microservice. Each service has its own decryption key that allows it to access only its designated token portion. This localized encryption approach enables each service to have the appropriate security properties for its specific needs while maintaining overall system security.

Inventive Principle:
Principle #3Local quality

2Reliability

If zero-trust policies are enforced for authorization tokens, then security is improved, but system complexity and performance overhead increase

Engineering Contradiction:
Improvezero-trust securityVSAvoidauthorization management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies preliminary action by pre-encrypting different portions of the authorization token with different keys before the token is issued to microservices. The encryption structure is established in advance, with each service's decryption key and corresponding token portion predetermined. This preliminary setup enables zero-trust security enforcement without requiring complex real-time authorization checks, thereby reducing operational complexity while maintaining high security standards.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If centralized authorization servers are used for token validation, then authorization control is improved, but latency and single point of failure risks increase

Engineering Contradiction:
Improveauthorization controlVSAvoidtoken validation latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts the authorization validation function from the centralized authorization server and embeds it directly within each microservice. Each service possesses the necessary decryption keys and validation logic locally, enabling it to independently verify its authorized portions of the token without contacting the central server. This extraction eliminates the single point of failure and reduces validation latency while maintaining authorization control through distributed validation capabilities.

Inventive Principle:
Principle #2Taking out (Extraction)

4Adaptability or versatility

If distributed microservices architecture is implemented, then scalability and resilience are improved, but communication complexity and security management difficulty increase

Engineering Contradiction:
Improvesystem scalabilityVSAvoidsecurity management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements self-service by enabling each microservice to independently manage and validate its own authorization token portions using locally stored decryption keys. Each service autonomously decrypts and validates its authorized claims without requiring centralized security management intervention. This self-service approach simplifies security management in distributed architectures by distributing the security management burden to individual services, thereby reducing overall system complexity while maintaining scalability and resilience.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS11917064B2Token transformation filter for the service mesh
Publication Date: 2024.02.27 PING IDENTITY INT INC
  • US11917064B2 patent drawing
  • US11917064B2 patent drawing
  • US11917064B2 patent drawing

AI summary

The disclosed technology teaches granular sharing of parts of an authorization token among individual microservices in a microservice chain, including packaging in an encrypted token base information used by the chain, overall, and respective individual portions of information for respective microservices in the chain. Also disclosed is receiving the token, with a service request message, at an entry point to the chain, decrypting the base information and verifying authorization for initiation of the service chain with an authorization service. Further disclosed is routing the service request and the encrypted token among the microservices in the chain, and at each respective microservice, applying a local transform to a respective individual portion of information and making the individual portion of information available for processing at the respective microservice, and the respective microservice consuming its own individual portion of information without having access to additional individual portions of information directed to other microservices.