Due to the fragmented nature of identity systems and duplication of similar sets of principles across the web, users are forced to generate virtual identities for every different website, leading to churn and business loss. One of the key standards that was established to address this problem was OAuth 2.0, which provides a specific set of secure and easily configurable steps to seamlessly and securely transfer one’s virtual identity and use the established identity to authenticate.
Typical identity provider
Any identity provider that supports OAuth 2.0 usually provides extensive samples and documentation on how to integrate with their Authorization Code Profile, which is the most commonly used grant type for securely integrating the provider’s identity. The Relying Party follows the typical OAuth 2.0 authorization code grant protocol to obtain a user’s identity information, such as first name, last name and email address.
Typical OAuth 2.0 Flow
Need for a strategy
Because of well laid-out documentation, integration with the OAuth system of an identity provider is straightforward, from registering an OAuth app to implementing the authorization code grant and code to access token exchange. However, the complexity arises when the User Identity determined by the identity provider already exists within the relying parties’ account system, such as when a user who is not authenticated yet on the relying party clicks on “Sign in with Identity Provider,” authenticates with the IDP, and shares their primary identifier as xyz@email.com. If this primary identifier already belongs to an existing account, it formulates an interesting problem to solve.
Account identity resolution
To address user scenarios such as above, the following account identity resolution strategy ensures that a user’s account in the relying party is provisioned and secured via established authentication mechanisms. These identity providers can be added as factors for authentication in this multi-factor authentication journey.
The following flowchart provides a step-by-step flow on the functioning of the account resolution process and how the user is seamlessly either authenticated or provisioned with the help of an identity provider as its authentication factor.
Using the identity provider as an authenticator
Unlike other applications that utilize the identity provider as their User Identity system, the relying party can instead integrate the identity provider as an “Authentication Method,” where their function as identity provider is translated into one of the factors that the user’s account can use to access their account. This enables the relying party to enforce contextual authentication and higher degrees of security controls when required. At any point of its lifecycle, the user account would be provisioned and have capabilities enabled via multiple identity providers. Authentication methods associated with the account can then be managed by the user and contextually authenticated by the relying party itself without any dependencies on the Identity provider if required.
Architectural flow
A representative application architecture of such an integration with an identity provider is depicted below. The various systems interact with each other to identify the account under the relying party user account system or allow the user to create an account with the identity provider as one of its authenticators.
Securing a user's privacy
One of the key goals while integrating with other identity providers is to protect a user’s privacy and ensure that no information is being shared either directly or implicitly with the identity provider other than the essential OAuth 2.0 specification parameters.
To achieve high levels of privacy, the key integration points with the identity provider should be proxied or obfuscated to prevent any implicit inferences from being identified. For example, when a user is being redirected to the identity provider, the session information or its identifiers should be obfuscated, even within the state parameter, either using encryption or randomly generated proxy references. When the identity provider redirects back to the relying party, the callback URL acts as a proxy which in turn redirects to the original page and prevents any information from being shared with the identity provider implicitly.
Relying Party and minimal permissions
The relying party, in order to ensure privacy, should request only basic information (such as first_name, last_name and/or email) and minimally required permissions from the identity provider during the OAuth 2.0 integration. This information should be used primarily for identity resolution or user account creation based upon the resolution results. The relying party should not request any other information and nor request access to act on behalf of the user if the intent is to use the identity provider as an Authenticator.
Risk and activity analysis
The relying party should have enhanced anomaly detection and risk analytics that factors in identity provider-based authentications as a new plane of investigation. Similar to any regular login attempts, success or failure attempts to use identity provider authentications should be diligently investigated for risk and appropriate actions should be taken for mitigation in case of any red flags. In such scenarios, identity resolution systems should be immediately notified to ensure that the suspected identity provider linkages are deactivated or completely disabled based on the analysis results to protect the user’s account from malicious activities.
OpenID Connect integration
The above detailed steps and strategy can be used to perform identity resolution with other identity provider schemes such as Open ID Connect as well. The integration points to transfer the identity information from the identity provider to the relying party might vary depending on the grant profile being utilized. However, using the strategy of the provider as an authenticator, resolution strategy flow, and other patterns for privacy, contextual authentication is easily adaptable for other schemes of identity providers.
Next steps
This is just one of the steps toward a more open, multi-factor contextual authentication that allows users to continue using their relying party in a more secure and trusted manner. With the improved usage of commonly used identity providers for authentication, relying parties are one step closer to eradicating passwords from the world of secure authentication. This can be further extended to help users secure their account with specific identity providers as an authentication and authorization factor at various checkpoints and to enable other relevant identity providers based on their geographical significance to achieve multi-factor authentication.