Identity Token Forwarding with Manifest-Based Route Validation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In microservice architectures, the arbitrary forwarding of tokens introduces security challenges, such as unauthorized access and impersonation, due to the need for multiple tokens in each communication leg and the complexity of token exchanges.
Innovation Solution
Implementing a manifest of allowed communication routes within identity tokens, using a field like the audience (aud) in OIDC tokens, to restrict token forwarding and authenticate callers based on these routes, combined with client certificates like X.509 for verification.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If arbitrary token forwarding is allowed in microservice architectures, then communication flexibility is improved, but security is worsened due to unauthorized access and impersonation risks
Solution Approach 1:
The patent segments the token validation process by introducing a manifest that divides communication paths into authorized segments. Each service must verify that the token's intended audience matches the service's identity in the manifest, creating discrete validation points that prevent arbitrary token forwarding while maintaining flexibility for authorized communication paths.
Solution Approach 2:
The manifest acts as an intermediary between tokens and services, mediating the validation process. Instead of direct trust between token and service, the manifest serves as a intermediary layer that verifies whether the token's audience field corresponds to an authorized service identity, thereby controlling token forwarding without compromising flexibility.
2Measurement precision
If multiple tokens are used for each communication leg in a chain of service calls, then authentication accuracy is improved, but device complexity is worsened due to token exchange overhead
Solution Approach 1:
The patent merges multiple authentication concerns into a single token structure. Instead of requiring separate tokens for different authentication dimensions (service identity, user identity, authorization), the manifest-based approach consolidates these into one token that is validated against the manifest, reducing the number of tokens needed while maintaining authentication accuracy.
Solution Approach 2:
The manifest is prepared in advance, defining all authorized communication paths and service identities before runtime. This preliminary action allows services to perform simple lookups during token validation rather than complex real-time authentication negotiations, reducing runtime complexity while maintaining security.
Data Source
AI summary
Methods, systems, and computer-readable storage media for receiving, from a first component and by a second component in a cloud platform, a call, a token, and a first client certificate, determining, by the second component, a first client identifier associated with the first component, and determining, by the second component, that the first client identifier is included in a manifest of the token, the manifest defining at least a portion of a communication path between components within the cloud platform, and in response: executing functionality responsive to the call.