A civic permitting portal will use the OAuth2 three-legged authorization code grant so residents approve access to their profile API. What is the first hop the constructed flow must perform?
Select an answer to reveal the explanation.
Short Explanation
Three-legged starts by walking the resident to the front desk (authorization endpoint)—not by stuffing a password into the vault API or asking for tokens first. The user must be present for that first hop.
Full Explanation
Three-legged authorization-code for a civic permitting portal begins with the resource owner present in the browser: redirect the user-agent to the authorization endpoint with client id, registered redirect URI, response_type=code, scope, and state. That hop is where residents authenticate and approve before any token exists. Skipping it breaks the grant the portal must construct for profile API access.
POSTing the resident’s password directly to the protected resource API is resource-owner-password territory and poor practice, not the authorization-code grant’s first hop. Calling the token endpoint with grant_type=client_credentials before any browser redirect is a two-legged machine path that never shows consent. Attaching an empty Bearer header and waiting for a 401 challenge page is not how OAuth authorization-code starts.
Exam caveat: DEVCOR’s happy path orders authorize → code → token → resource; the browser authorize redirect is mandatory and first among those four. Operational check: capture the outbound authorize URL and confirm it includes client_id, redirect_uri, response_type=code, scope, and state before any token or resource call is attempted from the permitting app.