How do you implement OAuth 2.1 (Auth Code + PKCE) for web and mobile?

OAuth 2.1 has become the standard way to implement secure user sign in in modern web and mobile applications. It simplifies the older OAuth model and removes risky flows, keeping only the authorization code flow combined with PKCE. This gives developers a clean, predictable, and secure pattern for authenticating users without ever handling their passwords directly.

When you explain this flow clearly in a system design interview, you demonstrate that you understand both authentication architecture and the practical security controls used in real world systems.

Why it Matters

OAuth 2.1 matters because it reshapes how apps handle user login. It removes unsafe practices from OAuth 2.0 and replaces them with predictable, secure behavior. For example, implicit flow is dropped, password grant is removed, and PKCE is mandatory for all authorization code clients.

For system design interviews, showing how web and mobile apps authenticate users without storing passwords, how tokens circulate, and how PKCE protects the redirect flow sends a very strong signal that you understand modern distributed systems and security boundaries.

How it Works Step by Step

OAuth 2.1 uses a single secure pattern for user facing login: authorization code flow with PKCE. The process is the same across platforms, but token storage and redirect handling differ between browsers and mobile apps.

Core Building Blocks

Before separating web and mobile, understand these shared pieces.

• Roles

  • Resource owner the user
  • Client your app
  • Authorization server identity provider
  • Resource server the API

• Endpoints

  • Authorization endpoint for login redirect
  • Token endpoint for exchanging the code

• Tokens

  • Access token for API calls
  • Refresh token for renewing access
  • ID token for identity claims

• PKCE elements

  • code_verifier random string generated by the client
  • code_challenge a transformation of the verifier
  • code_challenge_method usually S256

The authorization server stores the challenge. Later, the verifier proves the request came from the same client.

Web App Flow

Web apps fall into two categories

• Server rendered web apps
• Single page apps with or without a backend for frontend

The high level flow is the same for both.

Step 1. Register the Client

Configure

1. Client name
2. Allowed redirect urls
3. Authorization code grant
4. PKCE required
5. Exact redirect matching

Step 2. Start Login

When the user clicks sign in

1. Generate the code_verifier

2. Create the code_challenge from it

3. Store the verifier securely

   • On server apps inside the server session
   • On single page apps in memory or inside a secure cookie

4. Redirect the browser to the authorization endpoint with

   • response_type code
   • client_id
   • redirect_uri
   • scope
   • state
   • code_challenge
   • code_challenge_method S256

Step 3. User Logs in

The identity provider

1. Shows login

2. Authenticates the user

3. Redirects back to your redirect url with

   • authorization code
   • state

Your app confirms the state matches.

Step 4. Exchange the Code

Your server sends a POST to the token endpoint with

• grant_type authorization_code
• code
• redirect_uri
• code_verifier
• client_id
• client_secret for server apps

If the verifier is valid, the server returns access, id, and refresh tokens.

Step 5. Storage and Usage

• Server apps store tokens on the backend, never in the browser. The browser only gets a secure http only session cookie.

• Single page apps either

  • Use a backend for frontend that stores tokens and sets secure cookies
  • Or store tokens in memory only, not in local storage

The backend attaches the access token to API requests using the Authorization header.

Mobile App Flow

Mobile apps are public clients. They cannot store secrets safely in the app binary, so PKCE is critical.

Step 1. Register Mobile Client

Mobile clients use

• Custom schemes like myapp://callback
• App links or universal links that open the app directly

Step 2. Start Login through the System Browser

Best practice is to authenticate using the system browser.

• On Android use Chrome Custom Tabs
• On iOS use ASWebAuthenticationSession

Steps

1. Generate the verifier and challenge
2. Store the verifier
3. Open the authorization url in the system browser

When login completes, the browser redirects back to your custom scheme and the operating system routes control to your app.

Step 3. Exchange the Code

Your app calls the token endpoint using

• authorization code
• code_verifier
• client_id
• redirect_uri

Tokens are issued in response.

Step 4. Store Tokens

Store tokens in secure device storage

• Keychain on iOS
• Keystore or encrypted preferences on Android

The mobile app then attaches the access token to backend API calls.

Real World Example

Imagine a streaming platform with both web and mobile clients.

• On web, the user clicks sign in, gets redirected to the identity provider, logs in, and comes back with a code. The server exchanges that code and stores tokens in a server side session.
• On mobile, the app opens the system browser for login. After the user signs in, the redirect brings the code directly into the app. Tokens are stored in secure device storage.
• Both platforms call the same backend services using access tokens.
• No app ever sees the user password.

This gives you a clean, scalable architecture with clear security boundaries.

Common Pitfalls or Trade offs

• Using the implicit flow Implicit flow is removed from OAuth 2.1 because it exposes tokens in the browser url fragment.

• Storing tokens in local storage Local storage is accessible to injected scripts and is not safe for tokens.

• Wildcard redirect urls Exact redirect matching is required to avoid open redirect vulnerabilities.

• Not enabling refresh token rotation Rotation reduces risk if a refresh token leaks.

• Using WebViews for login in mobile apps Users cannot verify the real domain and the security indicators. System browser login is safer.

Interview Tip

A strong interview answer describes

• Authorization code flow with PKCE for both web and mobile
• Server side storage for web tokens
• Secure device storage for mobile
• State parameter validation
• Exact redirect matching
• Refresh token rotation
• The fact that your backend never handles passwords

This demonstrates understanding of modern authentication patterns and threat models.

Key Takeaways

• OAuth 2.1 simplifies the model by keeping only secure flows
• Authorization code with PKCE is the default for all user facing clients
• Web and mobile use the same flow but differ in token storage
• PKCE protects against code interception attacks
• Secure token storage is vital for both browser and mobile platforms

Table of Comparison

FAQs

Q1. What is the main purpose of OAuth 2.1 for web and mobile apps?

OAuth 2.1 provides a secure and consistent way to authenticate users without apps handling passwords. It standardizes the safe flows and removes insecure ones.

Q2. Why is PKCE mandatory in OAuth 2.1?

PKCE prevents attackers from stealing the authorization code during redirects. The verifier proves the request comes from the same client.

Q3. Should single page apps use implicit or authorization code flow?

Single page apps should use authorization code with PKCE. Implicit flow is removed from OAuth 2.1.

Q4. How should tokens be stored in browser applications?

Store them on the server and give the browser only a secure http only cookie. If needed on the client, keep tokens in memory only.

Q5. How do mobile apps handle redirects securely?

They use the system browser for login and custom schemes or app links to return control to the app.

Q6. Does PKCE replace the client secret?

No. Confidential clients still use a client secret. PKCE adds an extra protection layer.

Further learning

To master authentication patterns inside larger distributed architectures

• Explore identity, tokens, gateways, and API security in Grokking the System Design Interview

• Build a deep understanding of scalable services and secure communication in Grokking Scalable Systems for Interviews