Implement OAuth 2.0 flow to get an access token for API requests

WHAT THIS TESTS: Whether you can select the correct OAuth 2.0 grant type for a scripted, potentially non-interactive client and explain the full token lifecycle from issuance to usage to refresh. Senior engineers are expected to understand the security boundaries between the authorization endpoint, token endpoint, and resource server, not just parrot that you add Bearer to a header.

A GOOD ANSWER COVERS: First, grant-type selection. For a server-side script acting on its own behalf, client credentials is usually correct. For a script acting on behalf of a user without a browser, authorization code with a stored refresh token is the alternative. Second, the authorization phase. In client credentials, the script authenticates directly to the token endpoint using its client_id and client_secret. In authorization code, the script or a one-time setup redirects a user to the authorization endpoint with response_type=code, scope, state, and redirect_uri, then captures the authorization code. Third, token issuance. The script POSTs to the token endpoint with grant_type, the code or credentials, and optional scope to receive an access_token, token_type, expires_in, and optionally a refresh_token. Fourth, making requests. The script attaches the access token to API requests in the Authorization header using the token_type, typically as Bearer. Fifth, lifecycle management. The script must store tokens securely, not log them, handle 401 responses by using the refresh_token to obtain a new access token, and gracefully handle failures by stopping rather than looping infinitely.

COMMON WRONG ANSWERS: Treating OAuth 2.0 like a static API key that never expires. Describing the implicit flow for a backend script, which is insecure and largely deprecated. Omitting client authentication at the token endpoint. Storing client secrets or refresh tokens in source control. Failing to mention TLS for all token transmissions. Suggesting the resource owner password credentials grant as a first choice, which RFC 6749 explicitly discourages.

LIKELY FOLLOW-UPS: How would you handle token storage securely in a CI environment? What happens if the refresh token is revoked or expires? How do you choose between client credentials and authorization code for a daemon that acts on behalf of multiple users? How would you implement PKCE if this were a native script without a secret?

ONE CONCRETE EXAMPLE: A Python ETL script needs nightly Salesforce data. It uses the client credentials grant. It stores CLIENT_ID and CLIENT_SECRET in environment variables. It POSTs to the token endpoint with grant_type=client_credentials. It receives an access token with a 7200-second expiry and no refresh token. It caches the token in memory, attaches Authorization: Bearer TOKEN to every API call, and when a call returns 401, it repeats the token request once, backs off on failure, and alerts rather than retrying forever.

Source: RFC 6749