OpenID Connect: An Overview

The digital world thrives on seamless and secure authentication. With data breaches becoming more common, security protocols like OpenID Connect have never been more critical.

‍

OpenID Connect is an identity layer that sits on top of the OAuth 2.0 protocol. In layman's terms, it is a simple way for developers to integrate user authentication into their applications. Unlike many older systems that necessitate users to create a new account for every service they use, OpenID Connect allows users to employ existing credentials from a trusted provider.

OpenID Connect is how the “Google login boxes” that are so common on the web now are powered.

Example OpenID Connect powered login box with Google and GitHub options example:
‍

OpenID Connect (OIDC) uses standard protocols to authenticate users, retrieve user profile information, and handle logout requests. It enables clients to verify the identity of the user based on the authentication performed by an authorization server and obtain basic profile information about the user.

Benefits of Implementing OpenID Connect in Modern Applications

• Users Love It: Being able to log in with credentials that already exist is a great convenience to users and many strongly prefer it. This preference can be so strong with users that we often see Userfront customers automatically increase engagement when adding the option to plain username and password login options.
• It Keeps Users Secure: It is very common for users to reuse passwords when they are forced to maintain many login credentials. OpenID connect can keep users more secure by giving them one central place to change credentials in the event their credentials are compromised.
• It’s Efficient: OpenID Connect allows users to authenticate across multiple websites using a single set of credentials. This streamlines the user experience and reduces password fatigue.
• It Supports JSON Web Tokens (JWT): JWTs are compact and URL-safe, offering an easy and secure method for systems to share user information.
• Versatility: OpenID Connect supports multiple flows, catering to various types of clients including web-based applications, native apps, and JavaScript clients. This makes it a flexible solution for different use cases.
• It Helps Protect User Privacy: OpenID Connect provides the user control over what personal information is shared with the application, promoting user privacy.

How Does OpenID Connect Work?

OpenID Connect operates through a series of exchanges between three parties - the user, the relying party (the app requiring authentication), and the OpenID provider (the entity that verifies the user's identity).

1. Authentication Request: The relying party initiates an authentication request by directing the user's browser to the OpenID provider.
2. Authentication: The OpenID provider authenticates the user. This process can vary depending on the provider, but it typically involves requesting the user's credentials and validating them.
3. Authorization Code: Once the user is authenticated, the OpenID provider redirects the user's browser back to the relying party with an authorization code.
4. Token Request: The relying party then exchanges this authorization code for an ID token and an access token.
5. Token Verification: The ID token, which is a JWT (JSON Web Token), contains claims about the authentication of the end-user. The relying party verifies this token to ensure that it's valid and to retrieve the user's information.

A Step-by-Step Guide on Obtaining an ID Token for a User from an OpenID Provider (OP)

In this step-by-step explanation, we'll walk you through obtaining an ID token for a user from an OpenID Provider (OP) using the Authorization Code Flow, which is widely employed by traditional web applications. The Authorization Code Flow is particularly suitable for web applications as it enables secure user authentication and ID token retrieval via server-side communication.

Step 1: Redirect the user to the OpenID Provider's authorization endpoint

The application (Relying Party, or RP) needs to construct an authorization URL and redirect the user to the OpenID Provider's (OP) authorization endpoint. The URL must include the following query parameters:

• client_id: The unique identifier assigned to the application by the OP during registration.
• response_type: Set to "code" for the Authorization Code Flow.
• scope: A space-separated list of scopes requested, e.g., "openid email profile".
• redirect_uri: The URL to which the OP will redirect the user after authentication. It must match one of the registered redirect URIs.
• state: An optional but recommended random value to protect against cross-site request forgery (CSRF) attacks. The OP will return this value unmodified.

Example URL:

https://example-op.com/authorize?client_id=12345&response_type=code&scope=openid+email+profile&redirect_uri=https://userfront.com/callback&state=abcde12345

Step 2: User authenticates with the OpenID Provider

The user is redirected to the OP's authentication page, where they enter their credentials and confirm the requested permissions (if needed). Upon successful authentication, the OP redirects the user back to the registered redirect_uri.

Step 3: Application receives the authorization code

The OP appends the authorization code and the state parameter to the redirect_uri. The application must verify that the state value matches the one initially sent to protect against CSRF attacks.

Example redirect:

https://userfront.com/callback?code=AUTH_CODE&state=abcde12345

Step 4: Exchange the authorization code for an ID token

The application makes a POST request to the OP's token endpoint to exchange the authorization code for an ID token and an access token. The request must include:

• grant_type: Set to "authorization_code".
• code: The authorization code received in Step 3.
• redirect_uri: The same redirect URI used during the initial request.
• client_id: The application's client ID.
• client_secret: The application's client secret (if applicable).

Example POST request:

POST https://example-op.com/tokenHeaders:Content-Type: application/x-www-form-urlencoded Body:grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https://userfront.com/callback&client_id=12345&client_secret=CLIENT_SECRET

Step 5: Receive and validate the ID token

The OP responds with a JSON object containing the id_token, access_token, and token_type. The ID token is a JSON Web Token (JWT) that encodes the user's authentication information. The application must validate the ID token by verifying the token's signature, issuer, audience (the client_id), and expiration time.

After successful validation, the application can extract the user's information from the ID token, establish a session, and grant the user access to its resources.

Now you have a better understanding of how OpenID Connect's Authorization Code Flow works to securely authenticate users and obtain ID tokens. This is just one of the many flows supported by OpenID Connect, each designed to address specific use cases and security requirements.

Alternate Approach: Auth and Identity Provider

The steps outlined above can be greatly reduced in complexity by going with an Identity Provider, like Userfront, that abstracts out all this complexity.

OpenID Connect vs. OpenID 2.0

OpenID Connect and OpenID 2.0 might sound similar, but they aren't the same. The evolution from OpenID 2.0 to OpenID Connect was driven by the need for a more robust and versatile protocol that could handle the increasing complexity and demands of modern web services.

OpenID 2.0, launched in 2006, was a significant improvement over previous systems. It provided decentralized authentication, which meant users could log in to multiple websites using a single identity. However, OpenID 2.0 was found to be difficult to implement and lacked certain features, such as mobile application support and the ability to handle logouts.

OpenID Connect, on the other hand, was designed to address these shortcomings. Launched in 2014, it layered identity verification over OAuth 2.0, an existing authorization protocol. It supported JSON (JavaScript Object Notation), which simplified data transmission and was easier to implement. OpenID Connect added features like mobile app support, logout functionality, and the ability to share user profile data, offering a comprehensive solution for modern web services.

OpenID Connect vs. SAML vs. OAuth

While OpenID Connect, SAML (Security Assertion Markup Language), and OAuth all play roles in managing access and identity, they are fundamentally different.

SAML is an XML-based standard used for exchanging authentication and authorization data between parties. It's used for single sign-on (SSO) applications, where users can log in once and gain access to multiple applications. SAML is most often used in enterprise settings, such as when businesses need to authenticate their employees across various internal applications.

OAuth is an open-standard authorization protocol or framework that describes how unrelated servers and services can safely allow authenticated access to their assets. It is not an authentication protocol but rather a method that allows you to authorize one website (the consumer) to access your data from another website (the provider). OAuth provides the authorization layer – not the authentication.

OpenID Connect, as explained earlier, is an identity layer on top of OAuth 2.0, adding the user authentication piece that OAuth lacks.

While there are instances where these protocols overlap, they each serve distinct purposes, and understanding these differences is essential when deciding which protocol is best for your application.

Wrapping Up

OpenID Connect offers a reliable and versatile solution for user authentication in the modern digital world. Its evolution from OpenID 2.0 has addressed many challenges of the past, and its compatibility with other protocols such as OAuth makes it a flexible and powerful tool in a developer's toolkit.

‍