OAuth 2.0 flow in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identify the main purpose of the OAuth 2.0 Authorization Code flow

Which of the following best describes the main purpose of the OAuth 2.0 Authorization Code flow?

A To directly provide the client application with the user's password for authentication.

B To allow the client application to refresh the access token without any prior authorization.

C To enable the client application to access resources without any user interaction or consent.

D To allow a client application to obtain an access token by exchanging an authorization code received after user consent.

💡 Hint

Think about how the client gets permission from the user before accessing protected resources.

The Authorization Code flow is designed to let a client app get an access token by first getting an authorization code after the user consents. This code is then exchanged securely for the token.

❓ Architecture

intermediate

Select the correct sequence of steps in OAuth 2.0 Authorization Code flow

What is the correct order of steps in the OAuth 2.0 Authorization Code flow?

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Remember the user must first login and consent before the client gets the code.

The user first logs in and consents (step 1), then the authorization server sends an authorization code (step 2). The client exchanges this code for an access token (step 3), which it uses to access resources (step 4).

❓ scaling

advanced

Choose the best approach to scale an OAuth 2.0 Authorization Server

Which approach best supports scaling an OAuth 2.0 Authorization Server to handle millions of users securely and efficiently?

A Disable token expiration to reduce database lookups and improve performance.

B Store all tokens and sessions in a single database instance to ensure consistency.

C Use a stateless token design like JWTs and deploy multiple authorization server instances behind a load balancer.

D Use a monolithic server with synchronous blocking calls to handle all token requests.

💡 Hint

Think about how to avoid bottlenecks and maintain security with many users.

Using stateless tokens like JWTs allows multiple servers to validate tokens without querying a central database, enabling horizontal scaling. Load balancers distribute requests efficiently.

❓ tradeoff

advanced

Evaluate tradeoffs between using JWT access tokens vs opaque tokens

What is a key tradeoff when choosing JWT access tokens over opaque tokens in OAuth 2.0?

A JWT tokens allow stateless validation but can be larger and harder to revoke immediately.

B JWT tokens require a central database lookup for every request, increasing latency.

C Opaque tokens contain user credentials, making them less secure than JWTs.

D Opaque tokens are self-contained and can be validated without contacting the authorization server.

💡 Hint

Consider token size, validation method, and revocation capabilities.

JWT tokens carry all info inside and can be validated without server calls, but revoking them immediately is difficult. Opaque tokens require server checks but can be revoked easily.

❓ estimation

expert

Estimate token storage requirements for an OAuth 2.0 system

An OAuth 2.0 system issues 10 million access tokens daily. Each token record stored in the database requires 1 KB. If tokens expire after 1 hour and the system keeps expired tokens for 24 hours for audit, approximately how much storage in GB is needed to store all tokens for 24 hours?

A 1 TB

B 10 GB

C 240 GB

D 100 GB

💡 Hint

Calculate tokens per hour, multiply by 24 hours, then convert KB to GB.

10 million tokens issued daily, kept for 24 hours: 10M tokens * 1 KB = 10M KB ≈ 9.77 GB ≈ 10 GB (B).

Practice

1. What is the main purpose of the OAuth 2.0 Authorization Code flow?

easy

A. To replace user authentication with biometric data

B. To store user passwords safely on the server

C. To allow apps to access user data securely without sharing passwords

D. To encrypt all user data before sending it

Solution

1. Step 1: Understand OAuth 2.0 Authorization Code flow

   This flow lets apps get permission to access user data without needing the user's password directly.

2. Step 2: Identify the main goal

   The goal is to keep user credentials safe while allowing apps to act on behalf of the user.

3. Final Answer:

   To allow apps to access user data securely without sharing passwords -> Option C

4. Quick Check:

   OAuth 2.0 Authorization Code flow = Secure app access without passwords [OK]

Hint: Remember: OAuth avoids sharing passwords directly [OK]

Common Mistakes:

• Confusing OAuth with password storage
• Thinking OAuth encrypts all user data
• Assuming OAuth replaces authentication methods

2. Which of the following is the correct sequence in the OAuth 2.0 Authorization Code flow?

easy

A. User logs in -> App receives access token -> App requests authorization code

B. App sends password -> User grants access -> App receives token

C. App directly receives access token -> User logs in -> Access granted

D. User logs in -> App gets authorization code -> App exchanges code for access token

Solution

1. Step 1: Recall the OAuth 2.0 Authorization Code flow steps

   User logs in and authorizes the app, which then receives an authorization code.

2. Step 2: Understand token exchange

   The app exchanges the authorization code for an access token to access user data.

3. Final Answer:

   User logs in -> App gets authorization code -> App exchanges code for access token -> Option D

4. Quick Check:

   Authorization Code flow sequence = Login, code, token [OK]

Hint: Authorization code comes before access token [OK]

Common Mistakes:

• Thinking app gets token before authorization code
• Confusing password sending with OAuth flow
• Mixing order of login and token receipt

3. Given this OAuth 2.0 flow snippet, what is the expected output after exchanging the authorization code?

POST /token
Headers: Content-Type: application/x-www-form-urlencoded
Body: grant_type=authorization_code&code=abc123&redirect_uri=https://app.com/callback&client_id=client123&client_secret=secretXYZ

Response:
{
  "access_token": "token456",
  "token_type": "Bearer",
  "expires_in": 3600
}

medium

A. An access token 'token456' valid for 3600 seconds

B. An error because client_secret is missing

C. A refresh token instead of access token

D. No token, only a confirmation message

Solution

1. Step 1: Analyze the token request

   The app sends a POST request with grant_type authorization_code and includes the code and client credentials.

2. Step 2: Interpret the response

   The response contains an access_token 'token456', token_type 'Bearer', and expires_in 3600 seconds, meaning the token is valid for one hour.

3. Final Answer:

   An access token 'token456' valid for 3600 seconds -> Option A

4. Quick Check:

   Token response includes access_token and expiry [OK]

Hint: Token response includes access_token and expiry time [OK]

Common Mistakes:

• Expecting refresh token instead of access token
• Missing client_secret causes error
• Confusing confirmation message with token response

4. A developer implements OAuth 2.0 Authorization Code flow but the app never receives an access token after exchanging the code. What is the most likely cause?

medium

A. The app forgot to include the client_id in the authorization request

B. The redirect URI used in the token request does not match the one registered

C. The user did not enter their password correctly

D. The access token expired before the request

Solution

1. Step 1: Identify common OAuth token exchange errors

   One frequent error is a mismatch in redirect URI between authorization and token requests.

2. Step 2: Understand impact of redirect URI mismatch

   If the redirect URI differs, the authorization server rejects the token request, so no access token is returned.

3. Final Answer:

   The redirect URI used in the token request does not match the one registered -> Option B

4. Quick Check:

   Redirect URI mismatch blocks token issuance [OK]

Hint: Check redirect URI matches exactly in all requests [OK]

Common Mistakes:

• Blaming user password errors for token issues
• Ignoring client_id in authorization request
• Assuming token expires before it is issued

5. You are designing a system that uses OAuth 2.0 Authorization Code flow for a mobile app and a web app. Which approach best secures the access tokens and refresh tokens?

hard

A. Use Authorization Code flow with PKCE for the mobile app and standard Authorization Code flow for the web app

B. Use Implicit flow for both apps to simplify token handling

C. Store access tokens in local storage for both apps to allow easy access

D. Send access tokens directly in URL query parameters for both apps

Solution

1. Step 1: Understand security needs for mobile and web apps

   Mobile apps cannot keep client secrets safe, so PKCE (Proof Key for Code Exchange) enhances security for Authorization Code flow.

2. Step 2: Choose best practices for token storage and flow

   Web apps can use standard Authorization Code flow with client secret. Implicit flow is deprecated due to security risks. Storing tokens in local storage or URLs exposes them to attacks.

3. Final Answer:

   Use Authorization Code flow with PKCE for the mobile app and standard Authorization Code flow for the web app -> Option A

4. Quick Check:

   PKCE secures mobile OAuth; standard flow suits web apps [OK]

Hint: Use PKCE for mobile apps, standard flow for web apps [OK]

Common Mistakes:

• Using Implicit flow despite security risks
• Storing tokens insecurely in local storage
• Passing tokens in URL parameters