24 Advanced OAuth 2.0 Interview Questions for Experienced Developers

1. Resource Owner: The user who owns the data and grants permission to access it.
2. Client: The application (e.g., a web or mobile app) that wants to access the Resource Owner’s data on their behalf.
3. Authorization Server: The server that authenticates the Resource Owner and issues access tokens to the Client after getting consent.
4. Resource Server: The server that hosts the protected resources (the API). It validates the access token from the Client before serving data.

• Authentication is the process of verifying who a user is (proving identity).
• Authorization is the process of determining what an authenticated entity is allowed to do (granting permissions).

OAuth 2.0 is strictly a framework for **authorization**. It’s designed to grant a client application limited permission to access resources on behalf of a user. It is not designed for authentication, which is why OpenID Connect (OIDC) was built on top of it.

The `scope` parameter allows the client application to specify the level of access it is requesting from the resource owner. Scopes are strings (e.g., `read:profile`, `write:posts`) that limit what the issued access token is permitted to do. The authorization server presents these requested scopes to the user on the consent screen. This aligns with the principle of least privilege, as the client should only request the minimum permissions it needs to function.

The `redirect_uri` is the URL where the authorization server sends the user back to after they have granted or denied permission. It’s a critical security mechanism. It must be pre-registered with the authorization server to prevent open redirector attacks. If an attacker could provide a malicious `redirect_uri`, they could trick the server into sending the authorization code to their own malicious site, allowing them to hijack the user’s session.

• A **Confidential Client** is an application that can securely store its credentials (like a `client_secret`). This applies to backend web applications running on a secure server.
• A **Public Client** is an application that cannot securely store credentials. This applies to applications running in a user’s browser (SPAs) or on a mobile device. Because they cannot keep a secret, public clients must use the PKCE extension to securely perform the authorization code flow.

This flow adds a security layer to the standard Authorization Code grant to protect against authorization code interception attacks.

1. The client creates a secret (`code_verifier`) and a hashed version of it (`code_challenge`).
2. It sends the `code_challenge` in the initial authorization request.
3. The authorization server returns an authorization `code`.
4. The client then sends the `code` and the original `code_verifier` to the token endpoint. The server hashes the verifier and checks if it matches the challenge it received earlier.

This proves that the client making the token request is the same one that initiated the flow. It’s the current best practice for **all** clients, including confidential web apps and especially public clients (SPAs, mobile apps) where a secret cannot be stored securely. Read the official guide on PKCE.

The Implicit Grant (`response_type=token`) was an older flow where the access token was returned directly in the URL fragment after the user authenticated. It is no longer recommended because:

• It’s less secure: The access token is exposed in the browser’s history and can be leaked via referrer headers.
• No Refresh Tokens: It does not provide refresh tokens, forcing the user to re-authenticate frequently.
• Vulnerable to Attacks: It does not provide a mechanism to ensure the client receiving the token is the legitimate one.

The Authorization Code flow with PKCE should always be used instead, even for SPAs.

The Client Credentials flow is used for **machine-to-machine (M2M)** communication where there is no user involved. The client application authenticates itself directly with the authorization server using its own client ID and client secret. The resulting access token represents the identity of the client application itself, not a user. This is the correct flow for backend services, daemons, or CLIs that need to access an API on their own behalf.

The ROPC grant allows a client application to collect a user’s username and password directly and exchange them for an access token. It is highly discouraged because:

• It completely breaks the principle of delegated authorization by exposing the user’s credentials to the client application.
• It prevents the use of multi-factor authentication (MFA) or single sign-on (SSO).
• It creates a poor user experience and trains users to enter their password into untrusted applications.

It should only be used for legacy applications where redirect-based flows are not possible.

This grant is designed for devices with limited input capabilities (like smart TVs, game consoles) or no browser. The flow is:

1. The device asks the authorization server for a code and shows the user a URL and a user code.
2. The user goes to the URL on a separate device (like their phone), logs in, and enters the user code.
3. Meanwhile, the device polls the authorization server. Once the user approves, the device receives an access token and can access the API.

• An **Access Token** is a short-lived credential (typically minutes or hours) that is sent with every request to a resource server (API). It grants access to specific resources defined by its scope.
• A **Refresh Token** is a long-lived credential (days, months, or years) that is used to obtain a new access token without requiring the user to log in again. It is sent only to the authorization server’s token endpoint and must be stored securely by the client.

• Opaque Tokens: Are random strings of characters that act as a pointer to the token’s information stored on the authorization server. The resource server must call the authorization server’s introspection endpoint to validate the token and get its details. This makes them easy to revoke instantly but creates a dependency.
• JWT Tokens: Are self-contained. They carry their own expiration time, scopes, and user information, all signed by the authorization server. The resource server can validate them locally by checking the signature, without needing to call the authorization server. This is highly performant and scalable but makes immediate revocation more difficult.

Read about Self-Encoded vs. Opaque Tokens.

Because JWTs are stateless, immediate revocation is a challenge. Common strategies include:

1. Short-Lived Tokens: Using very short expiration times (e.g., 5-15 minutes) minimizes the window of opportunity for a compromised token. The user experience is maintained by seamlessly using a refresh token to get a new access token.
2. Revocation List: The authorization server maintains a blacklist of revoked token IDs (`jti` claim). The resource server must then check this list every time it validates a token, which partially re-introduces the stateful dependency that JWTs were meant to avoid.
3. Using a Gateway: An API gateway can be used to manage and check a revocation list before forwarding requests to the resource server.

Explore strategies for revoking JWTs.

The `id_token` is a JWT specific to **OpenID Connect**. Its purpose is to provide identity information about the authenticated user to the client application. It contains claims like the user’s ID (`sub`), the issuer (`iss`), and when they authenticated (`auth_time`). It is meant to be consumed and validated by the client application.

An `access_token` is for **authorization**. Its purpose is to be sent to a resource server (API) to gain access to protected resources. The client should treat the access token as an opaque string and not try to inspect its contents.

No, you should **not store tokens in Local Storage** for Single Page Applications (SPAs). Local Storage is vulnerable to Cross-Site Scripting (XSS) attacks; if an attacker can inject script onto your page, they can easily read and steal any tokens stored there.

Better alternatives include:

• In-Memory: Store the token in a JavaScript variable in memory. This is secure, but the token is lost on a page refresh, requiring a new login or a silent re-authentication flow.
• Secure, `HttpOnly` Cookies: When using a backend-for-frontend (BFF) pattern, the BFF can set the tokens in a secure, `HttpOnly` cookie. This makes them inaccessible to JavaScript and protects against XSS, while the browser automatically sends them on requests to your backend.

The `state` parameter is a critical security mechanism used to prevent **Cross-Site Request Forgery (CSRF)** attacks on the redirect URI. The flow is:

1. The client generates a random, unpredictable string and stores it in the user’s session.
2. It includes this string as the `state` parameter in the authorization request to the authorization server.
3. The authorization server redirects back to the client, including the exact same `state` parameter.
4. The client must then compare the returned `state` parameter with the one it stored in the session. If they do not match, the request should be rejected as it may have been initiated by an attacker.

Read about Redirect URIs and the `state` parameter.

An open redirector is an endpoint that redirects a user to an arbitrary URL specified in a parameter. In OAuth, an attacker could exploit this by crafting a legitimate-looking link that sends the user to the real authorization server but includes a malicious `redirect_uri`.

This is prevented by requiring all `redirect_uri` values to be **pre-registered** with the authorization server. The server must perform an exact string match (or a registered prefix match) on the provided `redirect_uri` against its allowlist. If it doesn’t match, the request is rejected.

This is an attack where an attacker takes a valid JWT, changes the payload, and then changes the algorithm in the header to `none`. Some poorly implemented libraries would then see `alg: none` and validate the token without checking for a signature at all.

To defend against it, your server-side validation logic must **never** trust the `alg` header from the token itself. You must have a pre-configured allowlist of acceptable algorithms (e.g., only `RS256`) and reject any token that does not use one of them.

Refresh token rotation is a security measure to detect token theft. When a client uses a refresh token to get a new access token, the authorization server also issues a *new* refresh token and invalidates the old one. If an attacker steals and uses the refresh token, the legitimate client will eventually try to use the same (now invalidated) token. When the authorization server receives a request with an invalidated refresh token, it knows that the token was likely compromised and can immediately invalidate the entire family of refresh tokens for that user and force a re-login.

The `id_token` contains essential identity claims, but to keep it small, it may not contain all user profile information (like profile pictures, extended attributes, etc.). The **UserInfo endpoint** is a protected resource on the authorization server that returns additional claims about the authenticated user. The client can make an authenticated `GET` request to this endpoint using the `access_token` it received to fetch this extra information.

• `acr` (Authentication Context Class Reference): A string that identifies the “level” or “strength” of authentication that was performed. For example, `urn:mace:incommon:iap:silver` might represent a standard password login, while a higher level might represent a login with MFA.
• `amr` (Authentication Methods References): An array of strings that identifies the actual methods used during authentication. For example, `[“pwd”, “mfa”]` indicates the user authenticated with both a password and a multi-factor authentication method.

PAR is an extension to OAuth 2.0 that improves security by changing how authorization requests are initiated. Instead of sending all the sensitive query parameters through the browser via redirects, the client makes a direct, authenticated back-channel request to a new `/par` endpoint on the authorization server. The server validates the parameters and returns a short-lived `request_uri`. The client then initiates the browser redirect with only this simple `request_uri`.

This prevents leaking request parameters and makes the request itself confidential and authenticated.

Read about Pushed Authorization Requests (PAR).

The Token Exchange grant is a standard way for a service to receive a token from a client and then exchange it at an authorization server for a *different* token that is valid for another, downstream service. This is a key pattern in microservices for securely propagating user identity and permissions. It allows a service to act on behalf of the user when calling other services, but with a token that is properly scoped for the downstream API, instead of just forwarding the original token.

OAuth 2.1 aims to consolidate the best practices of OAuth 2.0 into a new specification. Key changes include:

• **PKCE is required** for all authorization code grants.
• The **Implicit Grant is removed**.
• The **Resource Owner Password Credentials Grant is removed**.
• Redirect URIs must use exact string matching.
• Bearer tokens should not be sent in query parameters.