OAuth 2.0 Security Basics
OAuth 2.0 lets a user grant an application limited access to their data on another service without ever handing over their password. It is the machinery behind “sign in with” buttons and third-party integrations. Powerful and ubiquitous — and easy to implement insecurely, because its flows involve redirects, tokens, and trust boundaries that must all line up correctly.
What are the roles and the core flow?#
OAuth defines four roles: the resource owner (the user), the client (the app wanting access), the authorization server (issues tokens), and the resource server (holds the data). The recommended authorization-code flow with PKCE runs:
- The client redirects the user to the authorization server to consent.
- The authorization server returns a short-lived code to the client’s redirect URI.
- The client exchanges the code — plus a PKCE proof — for tokens over a back-channel request.
- The client uses the access token to call the resource server.
Keeping tokens off the front channel and binding the code to the client with PKCE is what makes this flow safe.
What goes wrong?#
| Mistake | Consequence |
|---|---|
| Loose redirect URI matching | Open redirect steals the code |
| Implicit flow (tokens in URL) | Tokens leak via history, referrer |
| Using OAuth as authentication | ”Sign in” confusion, account takeover |
| Not validating token audience/scope | Tokens replayed at the wrong service |
OAuth relies on exact redirect handling and careful token use, often carrying JWTs. More at the Web Security hub.
Frequently asked questions#
What is OAuth 2.0 used for?
OAuth 2.0 is a delegation framework that lets a user grant an application limited access to their resources on another service without sharing their password. It is what powers "sign in with" and third-party integrations. Importantly, it is an authorization framework, not an authentication protocol — that distinction is a common source of bugs.
Why should you use the authorization-code flow with PKCE?
The authorization-code flow keeps tokens off the front channel, exchanging a short-lived code for tokens over a back-channel request. PKCE adds a proof that the client redeeming the code is the one that started the flow, preventing code interception. It is now the recommended flow for web and mobile apps alike.