What is OAuth 2?

Authorization, not authentication

The single most common mistake about OAuth 2 is treating it as a login protocol. It is not. OAuth 2 is an authorization framework — it answers "is this application allowed to act on this user's behalf, and with what permissions?" It says nothing, by itself, about who the user is. OpenID Connect (OIDC), published by the OpenID Foundation in 2014, is the layer built on top of OAuth 2 that adds authentication — a standardized way to identify the user and convey identity claims via a JWT called an ID token. When you use "Sign in with Google" on a third-party site, the protocol underneath is OIDC, not raw OAuth 2.

Roles in the protocol

Four roles. The resource owner is the user who has data they might let another app access. The resource server is the API where that data lives — Google, Stripe, your own backend. The client is the application requesting access. The authorization server is the service that issues tokens after the user consents. Often the resource server and the authorization server are run by the same vendor (Google's API and Google's OAuth endpoints), but they are distinct concepts in the spec.

Grant types in 2026

The Authorization Code grant — now with mandatory PKCE — is the canonical flow for any client where a user is present, whether that client is a web app, a single-page app, or a mobile app. Client Credentials is for machine-to-machine flows where no user is involved — your service calling another service with its own credentials. Device Code is for inputs without keyboards (smart TVs, CLIs, IoT devices) where the user authorizes on a separate browser. Refresh Token lets long-lived clients renew access without prompting the user again. The Implicit grant and the Resource Owner Password Credentials grant were both common in older docs and have been formally deprecated in OAuth 2.1; if you see them in a tutorial, find a newer tutorial.

Where it goes wrong

OAuth 2 is a framework, not a closed protocol — which means the spec leaves many decisions to implementers, and small mistakes become real vulnerabilities. Redirect URI checking that allows substring matches instead of exact matches lets an attacker redirect tokens to a domain they control. Bearer tokens transported over HTTP instead of HTTPS get intercepted. Wide-scope tokens that an app does not actually need become useful loot for an attacker. State parameters omitted from the flow open the door to CSRF on the callback. None of these are theoretical; our pen-test team finds them on real production systems regularly.

At QUANT LAB

We use OAuth 2 (and OIDC on top) in essentially every SaaS platform and integration we build — federated login for users, machine-to-machine tokens for service calls, and OAuth-based integrations into any vendor that supports it. Implementations typically use a managed provider (Clerk, Auth0, WorkOS) or a battle-tested library (NextAuth/Auth.js, Ory) rather than rolling raw flows.

For higher-assurance contexts — finance, healthcare, admin consoles — we layer FIDO2 and passkeys on top of the OAuth flow at the authorization server, so the password is never the limiting factor. Read our piece on Stripe webhook security for a real-world OAuth-adjacent integration pattern, or book a call if your OAuth implementation has been quietly accumulating tutorial debt since 2018.