What is the difference between OAuth and OpenID Connect?

OAuth 2.0 handles authorization, meaning what a caller is allowed to access, while OpenID Connect is an identity layer built on top of OAuth that handles authentication, meaning who the user is. Use OIDC when you need to log someone in and plain OAuth when you only need delegated access to an API.

Can I use OAuth for login?

Not safely on its own, because an OAuth access token is a bearer credential for an API rather than a signed statement about who the user is. OpenID Connect adds an ID token, which is a signed assertion with an audience claim naming the client it was issued for, and that is the piece that makes a login decision sound.

What changed in OAuth 2.1?

It retires the implicit flow, the resource owner password credentials grant and plain PKCE, mandates PKCE for all clients rather than only public ones, and requires exact redirect URI matching. The practical effect is that authorization code plus PKCE becomes the single flow for every client type.

Why is the OAuth implicit flow deprecated?

Because it returned the access token directly in the URL fragment, which put it in browser history and risked leaking it through Referer headers, and it offered no way to bind the token to the client that requested it and no refresh token. The authorization code flow with PKCE achieves the same goal for browser-based apps without any of those exposures.

Is PKCE required if my app has a client secret?

Under OAuth 2.1, yes. OAuth 2.0 recommended PKCE only for public clients that cannot keep a secret, but 2.1 removes the distinction and requires it everywhere, because the authorization code interception it defends against is not limited to clients without secrets.

Is OAuth 2.1 a finished standard?

Not formally. As of March 2026 it remains an IETF Internet Draft at draft-ietf-oauth-v2-1-15 rather than a published RFC. That has not stopped adoption, since its recommendations are consolidations of existing security best-practice guidance and major identity providers already treat the retired grants as deprecated.

OAuth Is Not a Login System. And as of 2.1 There Is Only One Flow.

Two facts would prevent most of the OAuth bugs I have seen, and neither is subtle once stated.

The first is that OAuth is not a login system. It is an authorization framework. It answers “what may this caller access,” not “who is this person.” The thing that answers the second question is OpenID Connect, which sits on top of OAuth as an identity layer.^[1] Using raw OAuth to log users in is not a misconfiguration, it is a category error, and it has its own family of vulnerabilities.

The second is that the flow chart is gone. Everyone remembers agonising over which grant type applied to their client. As of OAuth 2.1 there is one answer: authorization code plus PKCE, for confidential servers, single-page apps and mobile apps alike, with no exceptions.^[2]

1 flow

Authorization code + PKCE, all client types

3 retired

Implicit, password grant, plain PKCE

All clients

Now require PKCE, not just public ones

Draft 15

OAuth 2.1 status as of March 2026

Why an Access Token Is Not Proof of Identity

This is the part worth understanding properly, because “use OIDC instead” is advice people follow without knowing what it buys.

An OAuth access token is a bearer credential. It means: whoever holds this may call that API. It is deliberately opaque to the client, it carries no reliable statement about the user, and critically it is not bound to the application that received it. Nothing in the token itself tells your backend which client it was issued for.

So if your login logic is “the user handed me a token, the token worked when I called the provider, therefore this is that user,” you have accepted a credential that could have been obtained by a different application entirely, for a different purpose, and replayed at you. Working is not the same as belonging.

“An access token proves that a call is permitted. It does not name the caller, and it does not say which app it was minted for.”

OpenID Connect fixes this with an ID token: a signed assertion about the user that includes an audience claim naming the client it was issued for.^[1] That is what makes a login decision sound. You verify the signature, you check the audience is you, you check the issuer and expiry, and only then do you believe the identity. That set of checks is the entire difference, and it is why the distinction is not pedantry.

Plain English

Rough translation. OAuth is a valet key: it opens the car, and says nothing about who is driving. OIDC is the driving licence: signed by an authority, naming a specific person, and issued to be shown to someone in particular. You would not accept a valet key as identification.

What OAuth 2.1 Actually Removes

OAuth 2.1 is mostly a consolidation. It gathers up years of separate security best-practice guidance and makes it the spec, which means the changes should not surprise anyone who has been paying attention. Three things go away.^[2]

The implicit flow. It returned the access token directly in the URL fragment, which put credentials in browser history and risked leaking them through Referer headers. It could not bind a token to the client that asked for it, and it had no refresh token.^[3] It existed because browsers once could not do better. They can now.

The password grant.Resource owner password credentials meant your application collected the user's actual password for another service and forwarded it. This trains users to type their credentials into third-party forms, which is the exact behaviour every phishing defence tries to break.

Plain PKCE. The plain code challenge method was a placeholder for clients that could not compute a SHA-256 hash. In 2026 that client does not exist, and S256 is the only method left.^[2]

Redirect URI matching also becomes strict: exact string comparison, no wildcards or prefix matching.^[2] Loose matching is how attackers redirect a legitimate authorization code to a host they control, and it has been behind a long series of real account-takeover findings.

PKCE for Everyone, Including Confidential Clients

The change most likely to trip up an existing integration: under OAuth 2.0, PKCE was recommended for public clients, meaning apps that cannot keep a secret, like a mobile app or an SPA. If you had a server with a client secret, you could reasonably skip it.

OAuth 2.1 removes that distinction and requires PKCE for all clients.^[2] The reasoning is that the attack PKCE prevents, interception of the authorization code between the redirect and the token exchange, does not care whether you hold a client secret. The code is in a URL either way.

Heads up

PKCE is simpler than the acronym suggests. Before redirecting, the client generates a random secret, hashes it with SHA-256, and sends the hash. When it later exchanges the code for a token, it sends the original secret. The server hashes it and compares. An attacker who steals only the code cannot complete the exchange, because they never saw the value behind the hash. That is the whole mechanism.

The Draft Question

Worth being accurate about, because people use it as an excuse to postpone. As of March 2026, OAuth 2.1 is still an IETF Internet Draft, at draft-ietf-oauth-v2-1-15, not a published RFC.^[2]

That is not a reason to wait. Nothing in it is novel; it is a rollup of guidance that already existed in separate documents, and the major identity providers already treat the retired grants as deprecated.^[2] If you are building now, build to 2.1 and you will not have to revisit it. If you are running implicit flow in production, the draft status of the document that removes it is not the interesting fact about your situation.

How This Connects to the Rest of Your Auth

Getting the flow right decides how a token is obtained. It says nothing about how you carry a session afterwards, which is a separate decision with its own trade-offs, and the one where revocation dominates: JWTs versus sessions.

It also matters more than usual right now because agent tooling has standardised on it. The Model Context Protocol's authorization story builds directly on this, which is worth knowing before wiring one up in production, and the failure modes are in the MCP security problem.

And none of it addresses what a caller may do once authenticated, which is where most real breaches live. Broken authorization outranks every cryptographic issue on the OWASP API list, and for non-human callers the model is in agent governance and RBAC.

Takeaway

OAuth authorises, OIDC authenticates, and the difference is the ID token's signature and audience claim, which is what lets you believe an identity rather than merely observe that a credential worked. Under OAuth 2.1 the flow decision is settled: authorization code plus PKCE with S256, for every client type, exact redirect URI matching, and no implicit or password grant. Build to that now regardless of the draft's formal status.

Sources and further reading

OAuth 2.1 was still an IETF draft at the time of writing; check the current draft before implementing against a specific section.

1.PrimaryOkta, "OAuth 2.0 and OpenID Connect overview". Source for the authorization-versus-authentication split and the role of the ID token as a signed identity assertion.
2.ReportingDescope, "OAuth 2.1 vs 2.0: key differences, security changes, and MCP impact". Source for the retired grants, PKCE becoming mandatory for all clients, strict redirect URI matching, and the draft-15 status as of March 2026.
3.Reporting"How to handle OAuth2 implicit flow (deprecated)". Source for the specific reasons implicit was removed: tokens in URLs and history, Referer leakage, no client binding, no refresh token.
4.PrimaryIETF, "The OAuth 2.1 Authorization Framework" (Internet Draft). The draft itself. Authoritative on what the spec requires, and the place to confirm the current revision.