OAuth 2.0: How to Explain It in an Interview (2026)

OAuth 2.0 is a standard way for an application (the client) to act on a user’s behalf without handling the user’s credentials directly. In an interview you need to convey three things quickly: the problem it solves, the high‑level flow, and why you would choose it over alternatives.

The One‑Sentence Definition

OAuth 2.0 is a delegated‑authorization protocol that enables a client to obtain limited, revocable access to a protected resource on behalf of a user, using tokens instead of passwords.

Core Mechanism

At its heart OAuth 2.0 defines four roles and a set of grant types that dictate how a client gets a token.

The most common grant type is the Authorization Code Grant. The typical steps are:

1. Authorization Request – The client redirects the user’s browser to the authorization server with a request that includes its client ID, requested scopes, and a redirect URI.
2. User Authentication & Consent – The user logs in (if not already) and consents to the scopes.
3. Authorization Code – The server redirects back to the client with a short‑lived code.
4. Token Exchange – The client sends the code (plus its client secret) to the token endpoint.
5. Access Token – The server returns an access token (and optionally a refresh token).
6. API Call – The client calls the resource server, presenting the access token in the Authorization: Bearer header.

Other grant types—client credentials, implicit, resource‑owner password credentials, and device code—serve specialized scenarios such as server‑to‑server communication or IoT devices.

Trade‑offs and Design Decisions

• Flexibility vs. Simplicity – OAuth 2.0’s many grant types let you tailor the flow to mobile apps, SPAs, or backend services, but each adds implementation complexity and security considerations.
• Token Lifetime – Short‑lived access tokens reduce risk if stolen, but require refresh‑token handling, which introduces its own security surface.
• Scope Granularity – Fine‑grained scopes give users better control, yet increase the burden on developers to manage many permission combinations.
• State Parameter – Prevents CSRF attacks; forgetting it is a common security bug.
• PKCE (Proof Key for Code Exchange) – Modern best practice for public clients (e.g., native mobile apps) to mitigate authorization‑code interception.

When asked why you’d pick OAuth 2.0, you can point to its industry adoption, delegated security model, and token‑based revocation. Contrast it with alternatives like API keys (no user context, hard to rotate) or basic auth (exposes credentials on every request).

Concrete Example: Integrating Google Calendar

Imagine you’re building a project‑management tool that lets users sync their Google Calendar events.

1. Register the app in Google Cloud Console – you receive a client ID and secret.
2. User clicks “Connect Calendar.” Your front‑end redirects to https://accounts.google.com/o/oauth2/v2/auth with scopes https://www.googleapis.com/auth/calendar.readonly and a PKCE challenge.
3. Google shows a consent screen listing the calendar read‑only permission.
4. After consent, Google redirects back with an authorization code.
5. Your back‑end exchanges the code for an access token (and refresh token) at Google's token endpoint.
6. API calls to https://www.googleapis.com/calendar/v3/calendars/.../events include Authorization: Bearer <access_token>.
7. When the token expires, the back‑end uses the refresh token to get a new access token without user interaction.

This flow demonstrates the separation of concerns: the user never shares their Google password with your service, and you can revoke the app’s access from the Google account settings at any time.

Typical Interview Questions

Practicing these answers aloud can be tricky. A tool like Call Assistant can listen to your rehearsal, catch when you drift off topic, and suggest concise phrasing that stays rooted in your own experience.

60‑Second Spoken Answer

"OAuth 2.0 is a delegated‑authorization protocol that lets an app obtain limited access to a user’s data without ever seeing the user’s password. The most common flow is the Authorization Code grant: the app redirects the user to the auth server, the user authenticates and consents, the server returns a short‑lived code, and the app exchanges that code for an access token. The token is then sent as a Bearer token to the resource server. This design isolates credentials, enables revocable permissions, and works across web, mobile, and server environments. Trade‑offs include managing multiple grant types, handling token lifetimes, and ensuring proper CSRF protection with the state parameter. In practice, I used the flow to integrate Google Calendar into a SaaS product, storing refresh tokens securely and refreshing access tokens automatically. I’d choose OAuth when I need user‑scoped access that can be revoked without disrupting the user’s other services."

How to Practice This

1. Write the flow on a whiteboard – sketch the four roles and the step‑by‑step exchange; repeat until you can do it without notes.
2. Record a 45‑second answer and play it back. Use Call Assistant to flag any filler words or moments where you stray from the core points.
3. Build a tiny demo (e.g., a GitHub OAuth login) and walk through the code, then explain each line as if you were interviewing. This grounds the abstract protocol in concrete experience you can reference on the spot.

---

FAQ

• What is the difference between OAuth 2.0 and OpenID Connect? OpenID Connect sits on top of OAuth 2.0 and adds an identity layer, returning an ID token that contains user profile information. OAuth alone only provides authorization.
• Can OAuth 2.0 be used without HTTPS? No. The spec requires TLS for all token exchanges; without it, tokens can be intercepted, breaking the security model.
• Why is the refresh token considered more sensitive than the access token? A refresh token can be used to obtain new access tokens indefinitely, so if it leaks, an attacker can maintain long‑term access. Access tokens are short‑lived and typically limited to a single resource.
• When would you avoid using OAuth 2.0? In simple internal services where a shared secret or API key suffices, the overhead of OAuth may be unnecessary. Also, if the client cannot securely store a secret (e.g., a pure static website), you might consider the implicit flow—though PKCE‑enabled Authorization Code is now preferred.