Access Token Identity Provider Claim for Multi-Provider Authentication

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing access management systems for multiple authentication providers do not allow users to utilize multiple identity providers while accessing services from a single service provider, limiting flexibility and security in digital asset protection.

Innovation Solution

Incorporating an additional claim in the access token to specify the identity provider for verification, allowing service providers to validate tokens using the corresponding identity provider's JWT key set and ensuring data access permissions are associated with the correct identity provider.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a single authentication provider is used for access management, then security and simplicity are maintained, but flexibility and adaptability for multiple identity providers are limited

Engineering Contradiction:

Improveability to use multiple identity providersVSAvoidauthentication system complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The authentication system is segmented into independent identity provider components, each capable of issuing tokens with identity provider claims. This allows multiple identity providers to be integrated without creating a monolithic complex system, as each provider operates independently with standardized token formats.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The access token is designed with universal structure that can accommodate multiple identity providers through the inclusion of an identity provider claim. This multi-functional token design allows the same authentication mechanism to work across different identity providers without requiring separate systems for each provider.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Measurement precision

If access tokens do not include identity provider information, then token structure remains simple, but verification accuracy and ability to associate permissions with correct identity provider are compromised

Engineering Contradiction:

Improvetoken verification accuracyVSAvoidtoken structure complexity

Core Design Contradiction:

Measurement precisionVSDevice complexity

Solution Approach 1:

The identity provider claim is embedded in the access token during the token issuance phase, before verification occurs. This preliminary inclusion of identity provider information ensures that verification can accurately identify the issuing provider without requiring complex post-verification processes or additional lookup mechanisms.

Inventive Principle:

Principle #10Preliminary action

3Reliability

If multiple identity providers are supported without additional claims, then token validation is simpler, but security and ability to ensure authorized access are compromised

Engineering Contradiction:

Improveauthorized access assuranceVSAvoidtoken validation complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The access token includes feedback information in the form of an identity provider claim that explicitly identifies which identity provider issued the token. This feedback mechanism enables the resource server to verify the token against the correct identity provider's public key, ensuring reliable authorized access determination without requiring complex validation logic.

Inventive Principle:

Principle #23Feedback

Data Source

PatentUS12155669B2Method for using openID connect to manage access to data with rights granted by multiple authentication providers

Publication Date: 2024.11.26 SONITOR TECH AS

AI summary

An approach to allow cloud-based positioning systems to use their own identity provider. An extra field is included in a token that is used to look up the identity provider for token verification for each user. Each access claim of the access token is checked for invalidity. If no invalid claims are found, accepting the authorization request. If an invalid claim is found, rejecting the authorization request.