OAuth vs OpenID: Understanding the Key Differences

Developers often mix up OIDC and OAuth and it’s easy to see why.

OIDC is built on top of OAuth 2.0 so there’s a significant overlap in their features. They both use tokens albeit for different reasons — OIDC uses ID tokens to store user data and OAuth uses access tokens to grant access.

Also, OIDC uses authentication flows based on OAuth — when a user logs into an app using OIDC, the app receives an ID token and often an access token (an OAuth component) which further blurs the lines between these two protocols.

In this article, we’ll clarify the differences between OAuth and OIDC, discuss their pros and cons, and provide examples of when you'd want to use one, the other, or both.

OAuth vs OpenID Connect: What are they + Which is right for you?

OAuth is an authorization framework that was built to allow one app to access another app on behalf of a user.

OAuth by itself does not provide a standard way to authenticate users. It only tackles delegated authorization. However, some companies still used it for authentication which was one of the reasons why OpenID Connect (OIDC) was created.

OIDC evolved from the broader concept of OpenID. OpenID, in its earlier versions, focused on allowing users to use a single identity (their ID) to log in to multiple apps. OIDC extends this concept by not only enabling single sign-on but also leveraging OAuth 2.0 to allow authenticated access to user data.

Use OAuth if: You only need to authorize access to resources without verifying the user's identity.

Use OIDC if: You need to both authorize access and authenticate the user's identity.

What is OAuth?

OAuth (Open Authorization) is an authorization framework that allows users to grant apps permission to act on their behalf without exposing their credentials — e.g. permission to pull their data from another app or modify it.

Before OAuth, accessing a user's data typically meant asking for their username and password. And, as you can imagine this was extremely risky — apps would store passwords in plain text and users had no way of revoking access other than changing their password — which they rarely do.

OAuth addressed these security flaws through access tokens. Instead of usernames and passwords, apps now request these tokens for temporary access to user data which is much safer, and most importantly, users can revoke access, if they want to.

OAuth is commonly used in apps that need to access resources owned by the user in another service. For example, an app accessing a user’s issues in Jira.

Pros of OAuth

• Improved security: You don't need to store and manage sensitive user passwords.
• Multiple flows for different kinds of apps: OAuth has multiple authorization flows (called grants) that are specialized for different types of apps (web, mobile, desktop server-side apps, devices, etc).
• Fine-grained access control: Users can be very specific about what an app can do. For example, allowing an app to view but not edit their data.

Cons of OAuth

• Steep learning curve: Setting up OAuth can be notoriously difficult even for experienced developers. There’s a lot you need to know — what each grant type does, which grant type you should use for your app, how to refresh tokens, how to keep them secure, and a lot more. Luckily, there are excellent resources out there from OAuth providers and open-source libraries alike that significantly flatten the learning curve.

• Lack of interoperability between providers: While OAuth provides a general framework, each provider may have unique quirks in their implementation. So while integrating with one provider might not be that difficult, connecting to 5 can get complicated really fast.
  ‍
• Security: If an access token or refresh token is stolen, an attacker could access protected data. To limit the risk, consider encrypting the token before storing it.

What is OIDC?

OpenID Connect (OIDC) is an authentication protocol based on the OAuth 2.0 framework. It combines two fundamental identity concepts — resource sharing and authentication.

ID tokens are what primarily differentiates OIDC from OAuth. Those ID tokens are JSON Web Tokens (JWTs) that, at the bare minimum, tell you who the person is (their username or email address) and how and when they were authenticated.

In case the data in the ID token is not enough, OIDC also provides a standard way to retrieve additional user information, using the UserInfo endpoint.

OIDC is commonly used for SSO, allowing users to authenticate once and access multiple apps without re-entering and logging in again.

Pros of OIDC

• Enables SSO: OIDC is one of the protocols used to implement SSO. Each time a user needs to log in, you redirect them to their provider’s site, where they get authenticated and then redirected back to your app with a token containing their identity.
• Reduces sign-up friction: Users can sign up for your app using existing accounts they already have, like their Google or GitHub account.
• Offloads authentication: It eliminates the need for your app to build an authentication system, significantly reducing the time you’d need to invest into building a system that can securely authenticate your users.

Cons of OIDC

• Dependence on third-party providers: Relying on external identity providers means your app's authentication is tied to their uptime and policies. Any changes or outages on their end can directly impact your users.
• Multiple accounts for the same user: Users might end up with multiple accounts within your app if they use different IDPs for each login. You could avoid this by linking multiple identities from different IDPs to a single user account, but there isn’t a standard way to do this and you can introduce security vulnerabilities if this isn’t done properly.

A practical way to reduce these risks is to build out a flow that requires the user to prove who they are (e.g. send them an email) before linking accounts. Or, only allow proactive account linking (where the user initiates it) vs. reactive (where you try to link accounts at the time of login).

What are OAuth and OIDC used together for?

When we talk about using OAuth and OIDC together, we're essentially referring to the use of OpenID Connect (OIDC) — OIDC uses OAuth.

OIDC is widely used for Single Sign-On (SSO) authentication, where a user logs in once and gets authenticated across multiple applications or services. OAuth's role in this process is to allow access to resources once the user is authenticated.

FAQ

What is the difference between OAuth and OIDC?

The main difference between OAuth and OIDC is that OAuth controls access to a protected resource, API, or service, while OIDC is a standard for authenticating users built on top of OAuth.

What is the difference between ID tokens and access tokens?

ID tokens contain user profile information (like the user's email or username) while access tokens act like a key, granting an app permission to access resources (like profile data) on behalf of the user.

Does OIDC use JWTs?

Yes, OIDC uses JWTs. The ID tokens are JWTs that contain the user’s identity details like email addresses, their name or role.

Is OIDC used in SSO?

Yes, OIDC is one of the protocols that enables SSO. Users can authenticate with an identity provider that supports OIDC and log in to multiple sites.

Next steps

Unless all your customers are using the same provider (highly unlikely), you’ll need to integrate with one or more identity providers (IdPs) like Google, and Facebook, or enterprise IdPs like Okta or Microsoft Entra.

Instead of juggling custom integrations, security best practices, updates, policies, and pricing for each of them, which can be a time sink, consider using WorkOS and connect to dozens of OAuth and OIDC providers with a single API-based integration.

• Get started fast: With SDKs in every popular language, and Slack-based support, you can integrate multiple providers in minutes rather than weeks.
• Support every protocol: With OAuth 2.0 integrations of popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any customer out of the box.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 SSO users to your app.

Explore unified SSO by WorkOS.