Authentication isn't authorization, and OAuth proves it

OAuth interview questions show up in backend, frontend, platform, and security loops because they force you to explain identity and permissions without hiding behind buzzwords.

This topic goes sideways when candidates mix up authentication and authorization, or when they describe an old flow that was common years ago but is a weak answer now.

As of April 2026, the useful baseline is clear:

• OAuth is for delegated authorization
• OpenID Connect adds identity on top of OAuth
• modern public-client answers should include authorization code flow plus PKCE

If you can explain those three ideas clearly, you will already sound more current than a lot of candidates.

What interviewers are actually testing

Strong OAuth answers usually prove five things:

1. You can name the actors instead of treating OAuth like one black box.
2. You understand the difference between getting permission and proving identity.
3. You can walk through the authorization-code flow in product terms, not just protocol jargon.
4. You know why PKCE exists and when it matters.
5. You can spot risky design choices, such as treating public clients as if they can safely keep secrets.

Name the OAuth flow before you design the system

Answer two questions: is the client confidential or public, and who is the flow acting on behalf of? The answer routes to exactly one modern flow. Two legacy flows — Implicit Grant and Password Grant (ROPC) — are deprecated by OAuth 2.1 and should never appear in a new design. If an interviewer names them, say "deprecated, Auth Code + PKCE replaces both" and move on.

Diagram

Copy source

Rendering diagram...

Green terminals are the modern defaults — pick one and the rest of the design follows. Amber terminals are real but narrow: device flow for TVs and CLIs, client credentials for service-to-service only. Red terminals are legacy flows you should be able to name as bad and skip.

The six OAuth interview questions that keep repeating

1. What problem does OAuth solve?

The clean answer is:

OAuth lets a user grant a client limited access to a resource server through an authorization server, without giving the client the user's password.

Keep the actors straight:

• resource owner: usually the user
• client: the app asking for access
• authorization server: the system that authenticates the user and issues tokens
• resource server: the API or service holding the protected data

If you skip the actors, your answer will sound hand-wavy.

2. Walk me through the authorization-code flow with PKCE

The short version:

1. The client sends the user to the authorization server with a code_challenge.
2. The user signs in and approves access.
3. The authorization server redirects back with an authorization code.
4. The client exchanges that code, along with the matching code_verifier, for tokens.
5. The client uses the access token to call the resource server.

TEXT

Copy

Browser -> Authorization Server: /authorize?response_type=code&client_id=...&code_challenge=... Authorization Server -> Browser -> Client: redirect with authorization code Client -> Authorization Server: /token with code + code_verifier Authorization Server -> Client: access token (+ optional refresh token) Client -> Resource Server: API request with access token

The interview point is not to memorize parameter names. It is to explain why the code alone should not be enough.

PKCE exists to bind the authorization code to the client that started the flow. That matters for public clients, where an intercepted code should not be redeemable by someone else.

3. What is the difference between authentication and authorization?

This question exists because people misuse OAuth constantly.

The short answer:

• authentication answers who the user is
• authorization answers what the client is allowed to access

OAuth is about authorization. If the interviewer asks how identity enters the picture, the useful next line is:

OpenID Connect adds an identity layer on top of OAuth 2.0, which is why OIDC introduces concepts such as the ID token.

4. Access token vs refresh token vs scope

This question is really about blast radius and access control.

A strong answer makes the trade-offs explicit:

• access token: short-lived credential used to call the API
• refresh token: longer-lived credential used to obtain a new access token
• scope: the permissions the client is requesting or receiving

One mistake to avoid:

Do not treat scopes and application roles as the same thing. Scopes describe delegated API permissions. Roles are part of your product's own authorization model.

5. Why is PKCE so important for public clients?

Interviewers ask this because it separates current answers from outdated ones.

Public clients include software that cannot reliably keep a secret hidden, such as native apps and browser-delivered clients.

That is why a static client secret is not strong proof of identity for those clients. Official native-app guidance is blunt on this point: a secret shipped to many users should not be treated as confidential in the way a server-side secret is.

For native apps, the strong answer is:

• use the system browser or another external user-agent
• use authorization code flow
• use PKCE
• do not lean on an embedded secret as if it solves impersonation risk

That is also why the OAuth implicit flow is a weak answer for native apps. If your answer still defaults there, you sound dated.

6. What mistakes or attack surfaces would you worry about?

This is where seniority shows up.

A useful OAuth answer names a few concrete failure modes:

• leaking an authorization code and redeeming it without proper PKCE checks
• over-broad scopes
• long-lived tokens with weak rotation or revocation discipline
• trusting a public client secret too much
• confusing OAuth with identity and skipping OIDC where identity claims matter

You do not need a giant security monologue. One clean sentence per risk, plus the control that reduces it, is usually enough.

The answer shape that works in interviews

When the question is broad, use this order:

1. name the actors
2. state whether the problem is authentication, authorization, or both
3. describe the happy-path flow
4. name the main risk
5. explain the control that reduces that risk

For example:

"OAuth solves delegated authorization. The user is the resource owner, our app is the client, the identity provider is the authorization server, and the API is the resource server. For a public client I would use authorization code flow with PKCE, so the code is not enough on its own if intercepted. If the product also needs identity claims for sign-in, I would use OpenID Connect on top of OAuth rather than pretending the access token itself is the whole identity story."

Common mistakes that cost easy points

Calling OAuth an authentication protocol

OAuth alone is not the whole identity story. If identity matters, say where OIDC fits.

Forgetting the actors

If you never name client, authorization server, resource server, and user, the protocol stays abstract and confusing.

Treating PKCE like a nice-to-have

Modern answers should treat it as part of the normal secure flow for public clients, not as an optional add-on.

Defending old defaults

If you lead with implicit flow for native apps or act as though a shipped client secret is real protection, you are giving the interviewer a reason to doubt your baseline.

Ignoring least privilege

Scopes, token lifetime, and refresh-token handling are where "works" and "reasonable security posture" start to diverge.

A short prep loop before the real interview

1. Practice explaining OAuth in under one minute without using the word "basically."
2. Rehearse the authorization-code flow with PKCE until you can say why the verifier matters.
3. Prepare one crisp sentence for authentication vs authorization.
4. Prepare one crisp sentence for OAuth vs OpenID Connect.
5. Pair this guide with API Design Interview Questions if the role expects you to reason about sign-in or API-integration flows.