OpenID vs OAuth: authentication vs authorisation

OAuth and OpenID Connect are often mentioned together, which is why people think they are alternatives. They are not. OAuth 2.0 handles authorisation: what an app is allowed to do. OpenID Connect handles authentication: who the user is. OpenID Connect is a thin layer on top of OAuth 2.0.

The short analogy

A hotel gives you a keycard at reception. The card opens your room and the spa for three nights. That is OAuth: access to specific things, for a limited time, without proving anything about you each time you tap it.

At check-in the receptionist also looked at your passport and wrote your name on the booking. That is OpenID Connect: someone with authority established who you are and handed the result to the system.

If a bar accepted the keycard as proof that you are the guest named on it, anybody who picked it up could claim to be you. That is exactly the mistake developers make when they treat an OAuth access token as a login.

Side-by-side comparison

	OAuth 2.0	OpenID Connect	OpenID 2.0 (retired)
Main question	What may the app access?	Who signed in?	Who signed in?
Result	Access token (opaque or JWT)	ID token (JWT) plus access token	Signed assertion passed as URL parameters
Built on	Own framework (RFC 6749)	OAuth 2.0	Own protocol, no OAuth
Typical use	API access, open banking, app integrations	Sign-in, single sign-on	Early 2000s web logins
Describes the user?	No	Yes: standard claims such as sub, email	Yes, via extensions
Status	Published standard, OAuth 2.1 in draft	Active, maintained by the OpenID Foundation	Superseded since 2014

How the two work together in one request

A “Sign in with …” button that also wants calendar access sends a single request with several scopes:

scope=openid email calendar.read

openid switches on OpenID Connect and makes the provider return an ID token. email asks for a standard identity claim. calendar.read is an ordinary OAuth permission. The app then receives two things:

1. An ID token to learn who logged in.
2. An access token to call the calendar API.

Step by step:

1. The user clicks “Sign in” in the app.
2. The app redirects to the provider with the scopes above.
3. The provider authenticates the user and asks for consent.
4. The app gets a code, exchanges it, and receives both tokens.
5. The app validates the ID token to create a login session, and uses the access token only for API calls.

The mechanics are described in OAuth 2.0 explained and OpenID Connect explained.

Everyday examples

• Only OAuth: a photo-printing service gets permission to read one album. It does not need to know who you are.
• OpenID Connect: a news site lets you comment after you sign in with a social account, and only reads your name and email.
• Both: a project tool that signs you in with your company account and then reads your calendar to schedule meetings.

Security aspects

• Never accept an access token as proof of login. An attacker can obtain an access token for one app and replay it at another. An ID token carries an aud claim naming the intended app and a nonce, which blocks that.
• Validate the ID token, not just receive it. Check signature, issuer, audience, expiry and nonce.
• Keep tokens in their lane. Send access tokens to APIs only; keep ID tokens inside your own app and session logic.
• Ask for the least. Request only the scopes you need. Broad scopes make consent phishing easier and cost trust.
• Authentication is not identity verification. Even a correct OpenID Connect login only says that someone controls an account. See identity vs authentication for the difference.

Common misconceptions

• “OAuth is for login.” It was designed for delegated access. Login became a side effect of how people used it, and OpenID Connect formalised it safely.
• “OpenID Connect replaces OAuth.” It does not. It needs OAuth underneath and adds identity on top.
• “An ID token can call APIs.” It cannot and should not. The ID token is for the app that requested it, the access token is for the API.
• “Both prove who I am legally.” Neither does. They show control of an account, not a verified legal identity.

Status and versions

OAuth 2.0 is RFC 6749, updated in practice by the security guidance in RFC 9700; OAuth 2.1 was still an Internet-Draft in October 2026. OpenID Connect Core 1.0 dates from 2014 and is published at openid.net/specs. OpenID 2.0 is no longer developed; the move away from it is covered in From OpenID to OpenID Connect and the protocol itself in OpenID 2.0.

Where the EU wallet fits

The EU Digital Identity Wallet goes one step further than both. It is not about logging in to an account or granting API access, but about carrying verified attributes, such as a name or an age confirmation, and showing only what is needed. The protocols for that, OpenID4VCI and OpenID4VP, reuse OAuth and OpenID Connect ideas such as authorisation codes, signed JWTs and redirect-based flows, which is why the foundations in this article are worth knowing before reading about the wallet.