Instructions and covered skills
Read each scenario carefully before selecting an answer. Keep your attention on the stated OAuth roles, endpoints, and request parameters. Turn off notifications and avoid switching between unrelated tasks while completing the test. Choose the response that best fits the OAuth 2.0 authorization code flow with PKCE. Do not assume that a browser, client application, resource server, and authorization server have identical responsibilities. Review your selections for parameter names and validation requirements before submitting.
Key Areas
This test examines the OAuth 2.0 authorization code flow when it is protected by Proof Key for Code Exchange (PKCE). Candidates should understand the responsibilities of the authorization server, client application, resource server, and resource owner. They should be able to distinguish the browser-facing authorization request from the server-facing token request and identify which values belong in each interaction.
Core areas include generating a high-entropy code_verifier, deriving an S256 code_challenge, and retaining the verifier only until the authorization code is exchanged. Candidates should understand why the authorization server stores the challenge with the issued code and compares it during the token request. They should also recognize why plain challenges are less desirable when S256 is available.
The assessment covers callback safety controls, including exact redirect URI matching and state correlation. It also addresses scope selection, authorization-code lifetime, one-time code use, token endpoint errors, refresh-token handling, and appropriate use of access tokens at resource servers. Candidates should be able to recognize common implementation faults, such as reusing a verifier, accepting an uncorrelated callback, or sending client credentials from a public client.
Recommended Preparation
Review the OAuth 2.0 authorization code flow from the initial authorization request through token issuance and API access. Practice constructing authorization URLs with response_type=code, client_id, redirect_uri, scope, state, code_challenge, and code_challenge_method=S256. Then practice token requests containing the authorization code, the same redirect URI, client identifier where required, and the original code verifier.
Study how URL-safe Base64 encoding without padding is used after SHA-256 hashing the verifier for S256. Review client registration rules for redirect URIs and public versus confidential clients. Finally, use an identity-provider sandbox or API client to inspect authorization redirects, token responses, expiry behavior, and documented error codes without exposing real tokens in logs or source control.