During OAuth setup for a parks reservation app, a developer changes the authorize redirect to an ad-hoc localhost URL that was never registered with the authorization server. What grant rule does that violate?
Select an answer to reveal the explanation.
Short Explanation
The return address on the ticket has to match the address on file—like a courier who only delivers to the registered desk. Inventing a convenient localhost mid-flight is how a code gets stolen.
Full Explanation
Authorization-code construction binds the redirect URI tightly: the value used on the authorize hop and on the token exchange must be the same URI pre-registered at the authorization server. Inventing an ad-hoc localhost mid-setup for the parks reservation app breaks that bind and opens authorization-code interception if a mismatched or open redirect is accepted.
Redirect URIs are not optional decoration inventable per request. The resource API is not the primary validator of redirects—the authorization server enforces registration on both authorize and token hops. Any HTTPS localhost is not automatically trusted without registration; even local development URIs must be explicitly allow-listed when used. Maintain the registered redirect list in the authorization-server console beside the parks app’s config repo so drift is visible. For local development, register a dedicated localhost URI deliberately rather than improvising a new one when a laptop port changes.
Exam caveat: mismatched redirect_uri is a common invalid_grant cause and a classic code-theft risk both on the exam and in production civic apps. Operational check: compare the registered redirect, the authorize redirect_uri parameter, and the token request’s redirect_uri byte-for-byte before testing resident consent in the parks app.