What Is OAuth 2.0 Explained Simply

1What Is OAuth 2.0?

OAuth 2.0 is an open standard for delegated authorization — it lets one application access a slice of your data on another service without ever learning your password. When you click 'Sign in with Google' or let a tool post to your calendar, OAuth is what grants that access safely.

Think of it as giving a valet a special key that starts the car and opens the door but not the trunk. The app receives a limited, revocable permission — never your actual credentials. You stay in control and can withdraw access at any time from the provider's settings.

2The Problem OAuth Solves

Before OAuth, sharing data between apps meant handing over your username and password — a genuinely bad idea for several reasons.

• The app could then do anything you could do, not just the one thing you wanted.
• You could not revoke access without changing your password everywhere.
• Your password was stored by a third party you may not trust to keep it safe.
• There was no way to grant read-only or time-limited access.

3The Four Roles in OAuth

Every OAuth flow involves four participants. Naming them makes the rest of the process easy to follow.

• Resource owner: you, the user who owns the data.
• Client: the application that wants access (e.g. a photo-printing site).
• Authorization server: issues tokens after you approve (e.g. Google's login).
• Resource server: holds your data and accepts the token (e.g. Google Photos API).

4The Authorization Code Flow, Step by Step

The authorization code flow is the most common and secure OAuth pattern for apps with a backend. It keeps the powerful token exchange on the server, away from the browser.

• 1. The app redirects you to the authorization server with its client ID, requested scopes, and a redirect URI.
• 2. You log in and approve the requested permissions on the provider's own page.
• 3. The provider redirects back to the app with a short-lived authorization code in the URL.
• 4. The app's backend exchanges that code (plus its client secret) for an access token.
• 5. The app calls the resource server's API with the access token to fetch your data.

5Tokens and Scopes Explained

Tokens are the credentials OAuth actually issues, and scopes define their limits. Understanding both is the key to using OAuth safely.

• Access token: a short-lived credential the app sends with each API request.
• Refresh token: a longer-lived credential used to obtain new access tokens without re-prompting you.
• Scope: a named permission such as 'read:profile' or 'write:calendar' that bounds what the token can do.
• ID token: in OpenID Connect, a signed token that proves who you are (not used by plain OAuth).

6OAuth vs OpenID Connect

OAuth and OpenID Connect are often confused because they appear together, but they answer different questions. OAuth is about authorization — what an app is allowed to do. OpenID Connect (OIDC) sits on top of OAuth and adds authentication — proving who you are.

That distinction matters. Using a raw OAuth access token to 'log a user in' is a known anti-pattern, because an access token proves an app has permission, not that a specific person is present. OIDC fixes this by returning a signed ID token with verified identity claims like your user ID and email.

7PKCE for Mobile and Single-Page Apps

PKCE (Proof Key for Code Exchange) secures OAuth for apps that cannot keep a client secret — mobile apps and single-page web apps. Since their code ships to the user's device, any embedded secret could be extracted, so PKCE replaces the static secret with a fresh proof on every login.

The app generates a random value called a code verifier, hashes it into a code challenge, and sends only the challenge at the start. When it later exchanges the authorization code, it presents the original verifier. The server checks that the two match, proving the same app that started the flow is finishing it.

• code_verifier = random_high_entropy_string() # kept in memory
• code_challenge = base64url(sha256(code_verifier)) # sent first
• Authorization request includes code_challenge
• Token exchange includes code_verifier # server re-hashes and compares

8Common Mistakes to Avoid

OAuth is secure by design, but implementation slips can undo that. Watch for these.

• Putting client secrets in browser or mobile code where anyone can extract them — use PKCE instead.
• Requesting broad scopes 'just in case' rather than only what the feature needs.
• Failing to validate the redirect URI, which opens the door to token-stealing redirects.
• Using the implicit flow, now discouraged, instead of the authorization code flow with PKCE.
• Skipping the state parameter, which protects against cross-site request forgery on the callback.

9Key Takeaways

The core ideas of OAuth 2.0 fit into a few durable principles.

• OAuth grants apps scoped, revocable access to your data without sharing your password.
• The authorization code flow exchanges a short-lived code for a token on the server.
• Scopes limit what a token can do; short-lived access tokens limit the damage of a leak.
• OAuth handles authorization; OpenID Connect adds authentication with signed ID tokens.
• Use PKCE and the state parameter, validate redirect URIs, and request the narrowest scopes.

10Frequently Asked Questions

Q: What is the difference between OAuth and OpenID Connect? A: OAuth 2.0 handles authorization — deciding what an app can access. OpenID Connect is a thin layer on top that adds authentication, returning a signed ID token that proves who the user is. Use OIDC when you need login, OAuth when you need delegated data access.

Q: Is OAuth 2.0 an authentication protocol? A: Not by itself. OAuth is an authorization framework; it tells you an app has permission, not who the user is. For authentication, use OpenID Connect, which builds identity on top of OAuth.

Q: What is an access token versus a refresh token? A: An access token is a short-lived credential sent with each API request. A refresh token is longer-lived and kept securely on the server; it is used to obtain new access tokens without asking you to log in again.

Q: Do I need PKCE? A: Yes for mobile and single-page apps that cannot safely store a client secret. PKCE is now recommended for all clients, including server-side apps, because it adds protection with almost no downside.