Developer Guides

OAuth 2.0 Explained: OpenID Connect vs OAuth

A detailed explanation of OAuth 2.0 and OpenID Connect, including differences, use cases, and recommendations for secure implementations.

5 min read

OAuth 2.0 and OpenID Connect (OIDC) have become foundational standards for modern web and mobile application security. While OAuth is primarily a framework for "authorization," OIDC builds on top by introducing "identity" to the equation. In this guide, we’ll break down the concepts, compare the two, and offer practical advice for secure implementations.

Understanding OAuth 2.0

OAuth 2.0 is a widely-used standard that allows third-party applications to access a user’s data or perform actions on their behalf without requiring the user to share their credentials. This process is called delegated authorization.

Here are key components to understand:

  1. Resource Owner (User): The individual granting permission.
  2. Client (Application): The app seeking to access or act on behalf of the user.
  3. Authorization Server: Handles authentication and permission grants.
  4. Resource Server: Provides the data or performs the requested actions.

At its core, OAuth 2.0 creates access tokens that act as temporary keys to access resources, ensuring credentials don’t need to be shared directly between services.

Key Components of OAuth Flows

Breaking down the roles involved:

  • Resource Owner: You, the user who decides which data or actions a third-party app may access.
  • Client: The application requesting access (e.g., a calendar app integrating with your email contacts).
  • Authorization Server: Responsible for authenticating you and issuing tokens.
  • Resource Server: Delivers the data or actions requested by the client.

These components operate together in a coordinated flow to ensure secure information exchange.

OAuth 2.0 Authorization Code Flow

The Authorization Code Flow is the most secure and widely recommended method for using OAuth. It works as follows:

steps

  1. The client application redirects the user to the authorization server with a request containing parameters like client ID, redirect URI, and requested scopes.
  2. The authorization server authenticates the user and requests consent to grant access.
  3. When consent is granted, the server redirects the user back to the client with an authorization code in the query.
  4. The client securely exchanges the authorization code with the authorization server using its client credentials (e.g., client secret) to retrieve an access token.
  5. The client uses the access token to access the resource server on behalf of the user.

This flow is considered secure because sensitive tokens are handled via backend server communication, not exposed in browsers or URLs.

Introduction to OpenID Connect

While OAuth focuses on authorization, OpenID Connect (OIDC) addresses authentication – verifying user identity alongside granting permissions.

OIDC extends OAuth by adding:

  • ID Tokens: JWTs (JSON Web Tokens) that contain information about the user.
  • Identity Claims: Specific details about the user, such as name, email, or unique user ID.
  • SSO Support: Streamlined Single Sign-On (SSO) across multiple applications.

For example, when logging into a service like Google, the "Sign in with Google" button uses OIDC under the hood.

OpenID Connect Flow

The OIDC flow builds on the OAuth flow and introduces a few key differences:

steps

  1. The client application requests an additional scope ("openid") in the OAuth request to indicate an authentication flow.
  2. Once the user is authenticated and grants consent, the authorization server issues both an access token and an ID token to the client.
  3. The ID token, a structured JWT, includes claims about the user and the session (e.g., user ID, login time, and token expiry time).
  4. Optionally, the client may use the access token to fetch additional identity data from a standardized userinfo endpoint.

This integration of identity capabilities is what sets OIDC apart from plain OAuth.

Recommendations for Secure Implementations

When implementing OAuth 2.0 and OpenID Connect, follow these best practices to ensure robust security:

Token Safety

Access tokens and ID tokens should be short-lived, and refresh tokens should only be used in trusted environments. Revoke tokens promptly if a compromise is suspected.

FAQ

What is the primary difference between OAuth and OpenID Connect?

OAuth is designed for authorization, meaning it allows one application to access data or perform actions on behalf of a user. OpenID Connect builds on OAuth by adding authentication, allowing applications to verify a user's identity.

Why is the Implicit flow discouraged?

The Implicit flow exposes access tokens directly in browser URLs, making them vulnerable to interception. It is no longer recommended, especially with the availability of secure alternatives like Authorization Code flow with PKCE.

When should I use OpenID Connect?

Use OpenID Connect when your application requires authentication to verify user identity or to enable Single Sign-On (SSO).

What are scopes in OAuth?

Scopes define the specific permissions the client application is requesting from the user. For example, a scope might specify access to an email address or the ability to write files to cloud storage.


Official reference: OAuth 2.0.