HTTP & APIs Interview Questions: OAuth Basics

Refresh tokens are credentials used exclusively with the authorization server's token endpoint to obtain new access tokens (and optionally new refresh tokens) when the current access token expires. They are never sent to the resource server. Only access tokens are presented to the resource server as Bearer tokens in the Authorization header.

OAuth 2.0 defines four core roles: the Resource Owner (user), the Client (application), the Authorization Server (issues tokens), and the Resource Server (hosts and protects the data). The Resource Server validates incoming access tokens on API calls to decide whether to fulfil the request. Understanding these roles is fundamental to OAuth literacy.

Because there's no user involved, the client credentials grant collapses OAuth's multi-step redirect dance into a single request/response: the client presents its credentials directly and gets a token back. RFC 6749 §4.4 restricts it to confidential clients — ones that can hold a secret, i.e. server-side services, never a browser app or mobile app — and says a refresh token normally shouldn't even be issued, since the client can just re-authenticate with its own credentials to get a new access token whenever it needs one.

Access tokens are intentionally short-lived to limit the damage window if they are compromised; once expired, the client must use a long-lived refresh token to get a new one without forcing the user to log in again. The state parameter acts as a CSRF mitigation: the client stores it locally (e.g., in session or a cookie), includes it in the authorization request, and then verifies that the value returned in the callback matches—preventing a malicious site from tricking the client into completing an authorization flow it did not initiate.

RFC 7519 §4.1.4 mandates that JWT processors MUST reject tokens where the current time is at or after the exp value. RFC 6750 §3.1 specifies that an expired token is an invalid_token error and the resource server MUST respond with HTTP 401 and a WWW-Authenticate header carrying error="invalid_token". The azp claim (authorized party) is checked by the client, not required by the resource server for basic validation. The aud as a URI is perfectly valid per RFC 7519 §4.1.3. RFC 7519 does acknowledge that implementors may allow small clock skew, but it is not a default tolerance, and 'MUST reject' takes precedence — accepting is never the correct answer once past exp.

PKCE (RFC 7636) extends the Authorization Code flow: (1) The client first generates the code_verifier and its code_challenge before any network request. (2) The client redirects the user-agent to the authorization endpoint, attaching the code_challenge. (3) The user authenticates and grants consent; the authorization server redirects back with the authorization_code. (4) The client exchanges the authorization_code for tokens at the token endpoint, this time sending the raw code_verifier. (5) The authorization server hashes the code_verifier and compares it to the earlier code_challenge, then issues tokens if they match. This order ensures an intercepted authorization_code is useless without the corresponding code_verifier.

PKCE (RFC 7636) exists because OAuth 2.0 public clients using the authorization code grant are "susceptible to the authorization code interception attack" — without a client secret to prove identity at the token endpoint, anyone who intercepts the code can redeem it. The verifier/challenge pair acts as a one-time, client-generated substitute for a secret: the challenge (sent up front) is a one-way function of the verifier (sent only at the end), so binding the code to the challenge lets the token endpoint confirm the same client that started the flow is the one finishing it, without ever transmitting a reusable shared secret. This matters most for mobile/native apps, where OS-level redirect interception is a real risk, and for SPAs, whose JS is fully inspectable so no secret is truly private — current OAuth security guidance recommends PKCE for all authorization-code clients, confidential or public, as defense in depth.

In OAuth 2.0, the authorization server issues both an access token and a refresh token during the Authorization Code flow (when 'offline_access' or similar scope is requested). The access token is short-lived and used to access protected resources. The refresh token is long-lived and is sent back to the token endpoint (not the authorization endpoint) to obtain a new access token without re-prompting the user. Critically, the refresh request must include the client credentials (client_id + client_secret for confidential clients) and the grant type must be 'refresh_token'. The resource server is never involved in token refresh — it only validates access tokens.

PKCE (Proof Key for Code Exchange, RFC 7636) was introduced to protect public clients (e.g., native/mobile apps and SPAs) against authorization code interception attacks. The client generates a cryptographically random code_verifier, hashes it with SHA-256 to produce the code_challenge, and sends the challenge (plus code_challenge_method=S256) in the authorization request. Later, it sends the raw code_verifier with the token request. The authorization server re-hashes the verifier and compares it with the stored challenge — this proves the same client that initiated the flow is redeeming the code, defeating a malicious app that stole the authorization code but doesn't know the verifier. The 'plain' method is discouraged. PKCE does NOT replace client_secret for confidential clients but IS recommended for all clients in OAuth 2.1.

The correct OAuth 2.0 Authorization Code flow order is: (1) Client sends the user to the authorization endpoint with response_type=code, client_id, redirect_uri, scope, and state. (2) The authorization server authenticates the user and asks for consent. (3) The authorization server redirects back to the client's redirect_uri with the code and state parameters. (4) The client verifies state to prevent CSRF, then POSTs to the token endpoint with grant_type=authorization_code, the code, redirect_uri, client_id, and client_secret. (5) The authorization server validates everything and responds with an access token (and optionally a refresh token). (6) The client uses the access token as a Bearer token to call the resource server. Understanding the precise ordering is critical for security — e.g., swapping steps 3 and 4 or skipping state validation are common vulnerabilities.