Comparing OpenID Connect with OAuth 2.0

OpenID Connect (OIDC) and OAuth 2.0 are two popular protocols you can use for authorization and authentication on the web. Both protocols allow users to securely access resources, but they work in different ways and have different use cases. In this tutorial, we’ll compare OIDC and OAuth 2.0 to help you understand the key differences between the two protocols and when to use each one.

What is OAuth 2.0?

OAuth 2.0 is an authorization framework that enables users to grant third-party applications access to their resources without sharing their passwords. It allows users to authorize applications to access their resources on their behalf, without revealing their passwords or other sensitive information.

OAuth 2.0 works by issuing an access token to a user when they grant access to their resources. The access token is a code that represents the user’s authorization to access the resources.

OAuth 2.0 defines four roles:

  1. Resource owner: The user who owns the resource and can authorize access to it.
  2. Client: The application that wants to access the user’s resource.
  3. Authorization server: The server that authenticates the user and issues access tokens to the client.
  4. Resource server: The server that hosts the user’s resource and verifies the access token before allowing access to the resource.

Then, here’s in a nutshell how the OAuth 2.0 flow works:

  1. The user (resource owner) grants the client application access to their resource.
  2. The client application sends a request to the authorization server, asking for an access token.
  3. The authorization server authenticates the user and sends an access token to the client.
  4. The client sends the access token to the resource server and requests access to the user’s resource.
  5. The resource server verifies the access token and, if it is valid, grants access to the user’s resource.

Finally, OAuth 2.0 defines several grant types, which determine how the client obtains the access token. Some common grant types include:

  • Authorization code: The client obtains the access token by redirecting the user to the authorization server, where the user grants permission. This is the most secure grant type, as it does not expose the user’s credentials to the client.
  • Implicit: The client obtains the access token by redirecting the user to the authorization server, where the user grants permission. The access token is returned in the URL fragment, which is not sent to the server. This grant type is less secure than the authorization code grant type, as the access token is sent in the URL and can be intercepted.
  • Resource owner password credentials: The client obtains the access token by sending the user’s username and password to the authorization server. This grant type is less secure than the others, as it exposes the user’s credentials to the client.

Use cases for OAuth 2.0

There are several use cases for OAuth 2.0. For example:

  • Social login: OAuth 2.0 is a common option to allow users to log in to a web application or service using their existing account with a third-party service, such as Google or Facebook. This is known as social login and is a convenient way for users to log in without having to create a new account.

  • Accessing resources on behalf of a user: OAuth 2.0 allows an application to access resources on behalf of a user. For example, an application might use OAuth 2.0 to access a user’s Google Calendar to schedule appointments on their behalf.

  • API integration: OAuth 2.0 also allows applications to access APIs and other resources provided by third-party services. For example, developers could incorporate data or functionality from other services into their own applications.

Finally, to see in practice OAuth, check this example: Keycloak OAUTH2 example with a REST Application

What is OpenID Connect?

OpenID Connect (OIDC) is an open standard that defines a protocol for authentication and authorization. It is built on top of the OAuth 2.0 framework and adds an additional layer of functionality to it. OpenID Connect is designed to provide a simple and secure way for users to authenticate themselves and access resources on the web.

OIDC uses the concept of identity providers (IdPs) to authenticate users. An IdP is a third-party service that holds the user’s credentials and verifies them when a user tries to log in to a web application or service. When a user logs in to an application using OpenID Connect, the application redirects the user to the IdP’s login page. The user enters their credentials and the IdP verifies them. If the credentials are valid, the IdP sends an access token to the application, which allows the user to access the resources they are authorized to access.

Finally, OpenID Connect also introduces the concept of claims, which are pieces of information about the user that are contained in the access token. Claims can include information such as the user’s name, email address, and other identifying information. The application can use this information to personalize the user’s experience and provide them with access to specific resources based on their claims.

Lean more about: Secure WildFly applications with OpenID Connect

Use cases for OpenID Connect

There are several common use cases for OpenID Connect. For example:

  • Single sign-on (SSO): OpenID Connect leverages Single Sign-On (SSO), which allows users to log in to multiple applications and services using a single set of credentials. This is particularly useful for organizations that have multiple applications and services that users need to access.
  • Federated identity: OpenID Connect can be used to implement federated identity, which allows users to use a single set of credentials to access resources across different domains. This is useful for organizations that have multiple domains or that want to allow users to access resources from other domains.
  • Identity verification: OpenID Connect can be used to verify the identity of users, using claims contained in the access token. This is useful for applications that need to ensure that users are who they say they are.

Comparing OAuth 2.0 and OpenID Connect (OIDC)

OAuth 2.0 and OpenID Connect (OIDC) are both authentication protocols that allow a user to grant a third-party application access to their identity information. The following table summarizes the key differences between them:

FeatureOpenID ConnectOAuth 2.0
PurposeAuthentication and authorizationAuthorization only
Protocol flowHybrid (combination of authorization code and implicit flows)Authorization code, implicit, resource owner password credentials, client credentials, or refresh token
TokensID token (contains user information) and access tokenAccess token
User authenticationRequiredNot required
Client authenticationRequiredOptional
ScopeDefined by OpenID Connect specificationDefined by authorization server

Finally, in terms of flow, the following diagram shows the differences between OAuth Authorization flow and OpenID Connect Authentication/Authorization flow:

openid connect vs OAuth 2.0


OpenID Connect and OAuth 2.0 are important authentication and authorization protocols to secure Web applications and services. OpenID Connect works for authentication and authorization, and is particularly useful for implementing single sign-on and federated identity. OAuth 2.0 works for authorization and is commonly used for social login, accessing resources on behalf of a user, and API integration. Understanding the use cases for these protocols is essential for developers working with web applications and services.