Default Signed-In State Generation Across Multiple Identity Providers

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current systems fail to efficiently manage user identity across multiple identity providers, leading to inefficient processing and poor user experience when navigating between different web workloads, as they lack the ability to determine the correct user identity and require multiple redirects for authentication.

Innovation Solution

A method is introduced to generate a default signed-in state that allows an already signed-in user to access an authenticated experience without re-signing in, by retrieving and evaluating identity provider data from multiple IDPs to select the appropriate user account and generate a default signed-in state, which can be used to redirect the user with a single authentication, even across different IDPs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a service redirects to a single identity provider for authentication, then the authentication process is simple, but the service cannot handle users from multiple identity providers

Engineering Contradiction:
Improveauthentication processVSAvoidmulti-identity provider support
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The service implements a universal authentication mechanism that can handle multiple identity providers through a common interface. The system maintains a registry of multiple IDPs and can redirect users to the appropriate provider based on their identity, enabling the service to work with various IDPs (e.g., corporate, personal, social) through a unified authentication flow.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The service acts as an intermediary between multiple identity providers and the application. It receives authentication requests, determines which IDP the user belongs to, redirects to the appropriate IDP, and then retrieves authentication tokens. This mediator approach allows the service to manage multiple IDPs without requiring each to integrate directly with the application.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If the service requests authentication from multiple identity providers, then it can support multiple IDPs, but the processing time and computational effort increase

Engineering Contradiction:
Improvemulti-identity provider supportVSAvoidauthentication time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The service performs preliminary actions by maintaining a registry of supported identity providers and pre-determining authentication flows for each IDP type. When a user attempts to authenticate, the service quickly identifies the appropriate IDP from the registry and initiates the corresponding pre-configured authentication sequence, avoiding the need to explore multiple IDPs in real-time.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The authentication process is made dynamic by adapting the redirect target based on the user's identity. The service evaluates which IDP the user belongs to and dynamically redirects them to the appropriate provider, rather than attempting authentication with all possible IDPs. This dynamic approach reduces authentication time while maintaining multi-IDP support.

Inventive Principle:
Principle #15Dynamics

3Adaptability or versatility

If the service does not determine the correct user identity, then it can work with any IDP, but multiple redirects are required for authentication

Engineering Contradiction:
ImproveIDP compatibilityVSAvoiduser experience
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The service implements a feedback mechanism where it receives information from the user agent (browser) about which IDP the user is associated with. This feedback allows the service to determine the correct identity provider and redirect the user accordingly, eliminating the need for multiple redirect attempts and improving the overall authentication experience.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3679503B1Default to signed-in state
Publication Date: 2024.02.14 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP3679503B1 patent drawingFigure 1
  • EP3679503B1 patent drawingFigure 2
  • EP3679503B1 patent drawingFigure 3

AI summary

Non-limiting examples of the present disclosure describe generation of a default signed-in state for subsequent authenticated access to a service. Identity provider data for a service is retrieved from any number of identity providers (e.g. a first identity provider and second identity provider). The first and second identity data is evaluated for generation of a default signed-in state to the service. An evaluation determines that at least one of the first identity data and the second identity data comprises data indicating that a user account is signed-in to the service. Data representing the default signed-in state is generated based on a result of the evaluation. The data representing the default signed-in state comprises a selection of one of the first or second identity data that corresponds with the user account that is signed-in to the service. A representation of the service in the default signed-in state may be surfaced.