Top 30 OAuth 2.0 Interview Questions and Answers [2026]

TL;DR: OAuth interviews in 2026 test the authorization code flow with PKCE, the difference between OAuth and OpenID Connect, token handling and the attacks RFC 9700 was written to stop. Candidates should know that RFC 9700 (January 2025) bans the password grant and tells clients to drop the implicit grant, and that OAuth 2.1 is still an Internet-Draft, not a published standard.

OAuth 2.1 reached its sixteenth draft on September 3, 2026, and it is still not an RFC.

The rules it collects are already published, though: RFC 9700 turned a decade of attack reports into requirements in January 2025, and RFC 10017 set out how browser apps should handle tokens in August 2026.

A candidate who answers from the 2012 spec alone will get several of the questions below wrong.

Core Concepts and Roles

1. What are the four roles defined in OAuth 2.0?

RFC 6749 defines four roles:

• Resource owner: usually the user, who owns the data and grants access to it.
• Client: the application that wants to act on the user's behalf, such as a web app, mobile app or CLI.
• Authorization server: authenticates the resource owner, asks for consent and issues tokens.
• Resource server: the API that holds the protected data and accepts access tokens.

In many products the authorization server is a separate service such as Keycloak, Auth0, Okta or Entra ID, while the resource server is your own API.

A good answer adds that one company can play several roles at once, which is why the protocol keeps them apart: the API never needs to see the user's password.

2. What is the difference between authentication and authorization? Which one is OAuth 2.0 for?

Authentication proves who someone is. Authorization decides what they may do. OAuth 2.0 is an authorization framework: it lets a client obtain limited access to an API on a user's behalf.

An access token says "the bearer may read orders". It does not reliably say who the user is or when they logged in, and it is not addressed to the client, so a client that treats receipt of an access token as proof of login can be fooled.

That gap is what OpenID Connect fills.

3. How is OAuth 2.0 different from OpenID Connect?

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. OAuth gives a client an access token for an API; OIDC also gives it an ID token that tells the client who logged in.

OIDC also standardizes what OAuth leaves open: a discovery document at /.well-known/openid-configuration, standard claims such as email, and logout specifications.

The OpenID Connect Core 1.0 text now carries errata set 2, and the OpenID Foundation announced in October 2024 that nine OIDC specifications were published as ISO/IEC standards, starting with ISO/IEC 26131:2024 for Core.

4. What is the purpose of the scope parameter?

The scope parameter lists the access a client asks for, such as orders:read. The authorization server may show it on the consent screen, may grant less than requested, and returns the granted scope in the token response when it differs.

Scopes are coarse by design. When the client needs to say "pay 45 euros to this account" rather than "make payments", Rich Authorization Requests (RFC 9396) add an authorization_details parameter with a typed JSON object.

RFC 9700 asks that tokens carry only the privileges the use case needs, and scopes or authorization_details are how a client asks for that minimum.

5. Why must the redirect_uri be pre-registered and matched exactly?

Because the redirect URI is where the authorization code is delivered. If an attacker can change it, the code goes to the attacker.

RFC 9700 section 2.1 says authorization servers "MUST utilize exact string matching", with one exception: the port number of a localhost redirect URI used by a native app, which picks a free port at runtime.

This corrects an answer that used to be common in interviews and in the older version of this guide: prefix or wildcard matching is not acceptable.

RFC 9700 section 4.1 walks through how pattern matching gets bypassed with path traversal, parameter tricks and subdomains the attacker controls.

The same section bans open redirectors on both the client and the server, because an open redirect on a registered URI forwards the code to any address the attacker chooses.

6. What is the difference between a confidential client and a public client?

A confidential client can keep a credential secret, because its code runs on a server the user cannot inspect.

A public client cannot: a single-page app ships its code to the browser, and a mobile app can be decompiled, so any embedded secret is public.

Both use the authorization code flow with PKCE today. The difference is that a confidential client also authenticates at the token endpoint.

RFC 9700 recommends asymmetric methods for that, either mutual TLS (RFC 8705) or private_key_jwt, so the authorization server stores only public keys and has no shared secret to leak.

Grant Types and Flows

7. Walk through the authorization code flow with PKCE.

The client proves at the token endpoint that it is the same client that started the flow, without needing a secret. It works in five steps:

1. The client generates a random code_verifier (43 to 128 characters) and sends its SHA-256 hash, the code_challenge, with code_challenge_method=S256 in the authorization request.
2. The user logs in and consents at the authorization server, which stores the challenge with the code it issues.
3. The browser is redirected back with the code.
4. The client sends the code and the original verifier to the token endpoint.
5. The server hashes the verifier, compares it with the stored challenge and only then issues tokens.

An attacker who steals the code from a log or a malicious app cannot redeem it without the verifier, which never left the client.

Generating the pair takes three lines in Node.js; the hash of the example verifier in RFC 7636 appendix B comes out as the RFC's own challenge, E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM.

import { randomBytes, createHash } from "node:crypto";

const verifier = randomBytes(32).toString("base64url");   // 43 characters
const challenge = createHash("sha256").update(verifier).digest("base64url");

const url = new URL("https://auth.example.com/authorize");
url.search = new URLSearchParams({
  response_type: "code",
  client_id: "my-spa",
  redirect_uri: "https://app.example.com/callback",
  scope: "openid orders:read",
  code_challenge: challenge,
  code_challenge_method: "S256",
}).toString();

RFC 9700 makes PKCE mandatory for public clients and recommended for confidential ones, and requires servers to reject a code_verifier when no challenge was sent, which blocks a downgrade attack.

8. Why is the implicit grant no longer recommended?

The implicit grant (response_type=token) returns the access token in the URL fragment of the redirect.

That puts the token where browser history, extensions, referrer leaks and injected scripts can reach it, and there is no standard way to bind a token issued this way to the client.

RFC 9700 section 2.1.2 says clients "SHOULD NOT use the implicit grant" or any response type that returns access tokens from the authorization endpoint. The OAuth 2.1 draft drops response_type=token entirely.

Single-page apps use the code flow with PKCE instead, which browsers have supported through CORS on token endpoints for years. Note the scope of the removal: OIDC's id_token response type is a separate extension and is not affected.

9. When is the client credentials grant the right choice?

When no user is involved. A billing service calling a reporting API, a nightly batch job or a CLI running in CI authenticates as itself and receives a token that represents the application, not a person.

The client credentials grant cannot issue a user-bound token, and it should not return a refresh token, because the client can ask for a new token at any time.

In production, prefer private_key_jwt or mTLS over a shared client_secret, and give each service its own client so a leaked credential affects one caller.

10. Why must the resource owner password credentials grant not be used?

RFC 9700 section 2.4 is direct: the password grant "MUST NOT be used". The older wording of "highly discouraged" understated it.

The grant hands the user's password to the client, which defeats the point of delegated authorization.

It cannot support multi-factor prompts, passkeys or single sign-on, because WebAuthn credentials are bound to the authorization server's origin. It also trains users to type their password into apps other than the identity provider.

The OAuth 2.1 draft omits the grant. Teams migrating a legacy mobile app off it usually move to the code flow in a system browser tab, as RFC 8252 describes for native apps.

11. How does the device authorization grant work, and how is it attacked?

The device authorization grant (RFC 8628) serves devices with no browser or keyboard. The device requests a device_code and a short user_code, shows the user a URL and the code, and polls the token endpoint.

The user opens the URL on a phone, signs in and enters the code. If the server sends no polling interval, the client must wait 5 seconds between polls, and it slows down when it receives slow_down.

The attack is social engineering. An attacker starts the flow on their own device, then sends the victim the real login URL and code with a story ("enter this code to join the meeting").

The victim signs in and approves, and the attacker's device receives the tokens. Nothing in the protocol links the phone to the device showing the code. The mitigations are covered in question 28.

12. What is token exchange, and when do you use it?

Token exchange (RFC 8693) lets a service trade one token for another at the authorization server.

A typical case: an API gateway receives a user's token scoped for the gateway and exchanges it for a narrower token whose audience is the orders service.

The request carries a subject_token (whose identity the new token represents) and optionally an actor_token (who is acting). The result can include an act claim, so the downstream service can see that "service A is acting for user 42".

That is safer than forwarding the original token, which would let every downstream service replay it against every other.

For calls that cross into another company's domain, the IETF draft on identity chaining combines a token exchange with a JWT authorization grant; it is in the RFC Editor queue as of September 2026.

Tokens: Access, Refresh, ID

13. What is the difference between an access token and a refresh token?

An access token is sent to the API on every request and should expire in minutes. A refresh token is sent only to the authorization server's token endpoint, to get a new access token without asking the user to log in again.

The split limits damage. A leaked access token works only until it expires; the refresh token, which lives longer, never travels to resource servers where it could be logged or leaked.

The refresh token must be stored more carefully than the access token for that reason, and for public clients RFC 9700 requires extra protection (question 22).

14. What is the difference between an ID token and an access token?

An ID token is for the client; an access token is for the API. The ID token is always a signed JWT defined by OIDC.

Its aud is the client's own client_id, and it carries claims such as sub, iss, auth_time and nonce that tell the client who logged in and how.

The access token may be a JWT or an opaque string, and the client should treat it as opaque either way.

Two mistakes to listen for: sending the ID token to an API as a bearer credential (its audience is the client, so a correct API rejects it), and reading user details out of the access token in the client instead of from the ID token or UserInfo endpoint.

The JWT interview guide covers how either kind of JWT should be validated.

15. Opaque access tokens or JWT access tokens?

Opaque tokens are random references. The API checks them by calling the authorization server's introspection endpoint (RFC 7662), which returns whether the token is active and what it grants.

Revocation is immediate, at the cost of a network call per request or a short cache.

JWT access tokens carry their claims and a signature, so the API validates them locally with the server's public keys.

RFC 9068 standardizes the format, including the at+jwt type header that stops an ID token being accepted as an access token. Local validation scales well but makes revocation slow.

Many teams use JWTs inside their own network and opaque tokens for third parties, so no claims leak to outside clients.

16. How do you revoke access in an OAuth deployment?

Revoke at the authorization server and keep access tokens short-lived. The revocation endpoint (RFC 7009) lets a client invalidate a refresh token or access token, for example on logout.

Revoking a refresh token should also end the grant it belongs to.

Whether the API notices depends on the token type. With opaque tokens, the next introspection call fails. With JWT access tokens, the API keeps accepting the token until exp, so the lifetime you choose is the revocation delay you accept.

Five to fifteen minutes is a common trade-off; high-risk APIs add introspection or a deny list for critical actions.

17. How do you stop a token issued for one API being replayed at another?

Restrict its audience. RFC 9700 section 2.3 says access tokens "SHOULD be audience-restricted to a specific resource server", and each resource server must refuse tokens not meant for it, typically by checking the aud claim.

The client names the API it wants with the resource parameter from RFC 8707. Without audience restriction, any service that receives a token, including a compromised or malicious one, can call every other API that trusts the same issuer.

The MCP authorization spec for AI tool servers depends on exactly this check.

18. Where should a browser-based app keep its tokens?

Preferably nowhere in the browser.

RFC 10017 (August 2026) ranks three architectures and puts a backend for frontend first: a server-side component runs the OAuth flow as a confidential client, keeps the tokens and gives the browser only an HttpOnly, Secure, SameSite session cookie.

If the app must hold tokens itself, keep them in memory rather than localStorage, use short access token lifetimes and rotated refresh tokens, and treat any XSS as full token theft.

The RFC's threat model assumes the attacker can already run script in the page; only the design with no tokens in the browser leaves that attacker nothing to take away.

Security Best Practices

19. Is the state parameter still needed if the client uses PKCE?

Not for CSRF protection, provided the client has confirmed the authorization server supports PKCE. RFC 9700 section 2.1 says such clients "MAY rely on the CSRF protection provided by PKCE"; OIDC clients can rely on nonce.

Otherwise, a one-time state value bound to the user's session is required.

Many clients still send state because it has a second use: carrying where the user was headed, such as the page to return to after login. The mistake to watch for is the opposite one: a fixed or reused state value, which protects nothing.

20. What is a mix-up attack, and how does the iss parameter stop it?

A mix-up attack targets clients that work with more than one authorization server, such as an app with "Log in with A" and "Log in with B".

The attacker's server tricks the client into sending a code issued by the honest server to the attacker's token endpoint.

The fix in RFC 9207 is an iss parameter in the authorization response. The client records which issuer it sent the user to, then rejects any response whose iss does not match.

Servers advertise support with authorization_response_iss_parameter_supported in their metadata. RFC 9700 makes a mix-up defense required whenever a client talks to more than one authorization server.

21. What are sender-constrained tokens? Compare mTLS and DPoP.

A sender-constrained token only works when the caller also proves possession of a key, so a stolen token alone is useless. RFC 9700 says authorization and resource servers "SHOULD" use one of two mechanisms:

• Mutual TLS (RFC 8705): the token is bound to the client's TLS certificate. Strong and simple for server-to-server traffic, but awkward in browsers and behind proxies that terminate TLS.
• DPoP (RFC 9449): the client signs a small JWT for each request with the HTTP method (htm), URL (htu), a unique jti and, at the API, a hash of the access token (ath). It works at the application layer, so it suits SPAs and mobile apps.

A candidate should mention the weak spot of DPoP in the browser: if the private key is extractable, XSS can steal it. Non-extractable WebCrypto keys reduce that risk.

22. What does RFC 9700 require for refresh tokens issued to public clients?

They "MUST be sender-constrained or use refresh token rotation". With rotation, every refresh returns a new refresh token and invalidates the old one.

If an old token is presented again, the server knows two parties hold copies and revokes the whole grant, logging out both the attacker and the user.

Implementation details matter: allow a short grace period for a client whose refresh response was lost in transit, bind the rotation chain to the grant rather than to a single token, and set an absolute lifetime so a stolen chain cannot be kept alive forever.

23. What is authorization code injection, and what stops it?

The attacker obtains a valid authorization code for the victim's account (for example from a leaked log) and injects it into their own session with the legitimate client, which then redeems it and logs the attacker in as the victim.

Client authentication does not help, because the legitimate client redeems the code.

PKCE stops it: the code is tied to a verifier held by the session that started the flow, and the attacker's session holds a different one. For confidential OIDC clients, RFC 9700 accepts nonce as an alternative with additional precautions.

Either value "MUST be transaction-specific", so a hard-coded challenge is a finding in any review.

OpenID Connect and Beyond

24. What does the nonce do in OpenID Connect?

The client generates a random nonce, sends it in the authentication request and checks that the ID token contains the same value.

That binds the ID token to this login attempt in this browser, so a token captured elsewhere cannot be replayed into a new session.

It overlaps with state but checks a different thing: state (or PKCE) protects the redirect, while nonce protects the ID token itself.

OIDC Core makes the nonce required in the implicit flow and in hybrid flows that return an ID token from the authorization endpoint; in the code flow it is optional, and RFC 9700 accepts it as the injection defense for confidential clients.

25. What are the acr and amr claims, and how does step-up authentication use them?

acr names the level of assurance of the login (a value agreed between the parties). amr lists the methods used, such as ["pwd", "otp"]. The client requests a level with acr_values or a freshness limit with max_age.

Step-up (RFC 9470) lets an API demand more when the stakes rise. A request to change payout details can fail with WWW-Authenticate: Bearer error="insufficient_user_authentication" plus the required acr_values or max_age.

The client sends the user back to the authorization server, which prompts for a second factor and issues a token that meets the requirement.

26. What are Pushed Authorization Requests (PAR)?

With PAR (RFC 9126), the client posts its authorization request parameters directly to the authorization server over an authenticated back channel and gets back a short-lived request_uri.

The browser redirect then carries only the client_id and that reference.

That keeps parameters out of browser history and logs, stops them being tampered with in transit, lets the server reject a bad request before the user sees a login page, and removes URL length limits for large authorization_details.

FAPI 2.0 requires PAR for every flow.

What Changed Recently

27. Is OAuth 2.1 a standard yet, and what does it change?

No. draft-ietf-oauth-v2-1 reached revision 16 on September 3, 2026 and remains a working group document. It consolidates RFC 6749, RFC 6750, PKCE, the native apps and browser apps guidance, and RFC 9700.

Its own list of differences from OAuth 2.0:

• PKCE is part of the authorization code grant by default.
• Redirect URIs are compared by exact string match.
• The implicit grant and the password grant are omitted.
• Bearer tokens may not be sent in URI query strings.
• Refresh tokens for public clients must be sender-constrained or one-time use.
• The token request no longer carries redirect_uri, and servers must accept client credentials in the request body.
• The PKCE plain method is removed.

In an interview, "we follow OAuth 2.1" is fine shorthand, but a precise candidate cites RFC 9700 for the rules that are already published.

28. What does RFC 10027 say about cross-device flows?

RFC 10027, a Best Current Practice published in August 2026, covers every flow where the user starts on one device and approves on another: the device grant, CIBA, QR-code logins and wallet flows.

Its core rules: implementers "MUST perform a risk assessment" first, "SHOULD avoid cross-device flows if risks cannot be sufficiently mitigated", and should include proximity checks where possible.

The mitigations it lists include short-lived and one-time codes, rate limits, limited scopes and short token lifetimes for these flows.

It also asks for a consent screen that tells the user who started the flow and why, with "decline" as the default or at least as prominent as "grant".

For a company, the practical takeaway is to disable the device grant for every client that does not need it; the RFC's own attack examples include a phishing message that tricks a user into granting access to their productivity apps.

29. What is FAPI 2.0, and why do banks use it?

FAPI 2.0 is an OpenID Foundation profile that fixes OAuth's optional choices for high-risk APIs such as open banking. The FAPI 2.0 Security Profile became final in February 2025.

Among its requirements: authorization servers must use PAR, must require PKCE with S256, must issue sender-constrained access tokens through mTLS or DPoP, and must authenticate confidential clients with mTLS or private_key_jwt.

A useful interview question is whether a team outside finance should adopt it; a strong answer treats it as a well-tested checklist even where no regulator demands it.

30. How do AI agent protocols such as MCP use OAuth?

The MCP authorization spec (version 2026-07-28) treats each MCP server as an OAuth resource server and each AI client as an OAuth client.

Clients discover the authorization server through Protected Resource Metadata (RFC 9728), use the code flow with PKCE, and send the RFC 8707 resource parameter so each token is bound to one server.

The new part is client registration. An agent may connect to servers it has never seen, so pre-registering every client is impractical.

The spec lets a client obtain a client ID through pre-registration, Dynamic Client Registration or a Client ID Metadata Document, an IETF draft in which the client_id is an HTTPS URL pointing to a JSON document that describes the client.

The server fetches it when needed. Candidates should see the trade-off: no registration step, but the server now fetches URLs supplied by strangers and must defend against SSRF.

Signs of a Strong Answer

• They cite RFC 9700 for current rules and know OAuth 2.1 is still a draft.
• They say "exact string match" for redirect URIs without prompting, and know the localhost port exception.
• They keep the ID token and the access token apart: who logged in versus what the API allows.
• They pick a grant by asking whether a user is present, whether the client can keep a secret and whether the device has a browser.
• They connect access token lifetime to revocation delay and can defend a number.
• They describe device code phishing or mix-up attacks from the attacker's side, not only the mitigation.

Hiring Engineers Who Know OAuth

OAuth bugs rarely show up in testing: the login works, and the flaw waits for an attacker. Second Talent matches companies with pre-vetted API developers and back-end engineers from Asia, screened with questions like these.

Our backend developer cost guide shows current rates.

Tell us the stack and we send a shortlist within 24 hours. Start hiring, or see our JWT and API security interview guides.