OAuth 2.0 In Depth

OAuth 2.0 solves a specific problem: letting users grant your application limited access to their data on another service — without sharing their password. When you click "Login with Google," OAuth is working behind the scenes.

Understanding OAuth requires knowing its key players. The Resource Owner is the user who owns the data. The Client is your application requesting access. The Authorization Server issues tokens (like Google's auth servers). The Resource Server holds the protected data (like Google's APIs).

The Authorization Code Flow

This is the most common flow for web applications, and it's the most secure for server-side apps.

1. User clicks "Login with Google"
2. Your app redirects to Google with:
   - client_id (identifies your app)
   - redirect_uri (where to return)
   - scope (what access you need)
   - state (CSRF protection token)

3. User authenticates with Google
4. Google redirects back with an authorization code

5. Your server exchanges the code for tokens:
   POST to Google with code + client_secret
   
6. Receive access_token (and optionally refresh_token)

7. Use access_token to call APIs

The critical security feature here is that the access token never passes through the browser. Your server exchanges the code for tokens directly with Google's servers.

PKCE for Public Clients

Mobile apps and single-page applications can't keep a client_secret secure — users can inspect the code. PKCE (Proof Key for Code Exchange) solves this.

Before redirecting, your app generates a random code_verifier and sends a hashed version (code_challenge) to the authorization server. When exchanging the code for tokens, you send the original code_verifier. The server verifies it matches the challenge, proving you're the same client that started the flow.

Common Confusion

OAuth is about authorization (what can you access?), not authentication (who are you?). OAuth alone doesn't tell you who the user is — it just gives you permission to access their resources. For authentication, you need OpenID Connect, which builds on OAuth.

Choosing the Right Flow

Use Authorization Code with PKCE for most applications — it's now recommended even for server-side apps. The Implicit flow is deprecated due to security concerns. Client Credentials flow is for server-to-server communication where no user is involved.

See More

Further Reading

You need to be signed in to leave a comment and join the discussion