A school-district parent portal starts an authorization-code grant but omits the state parameter. Which protection is missing from that grant step?
Select an answer to reveal the explanation.
Short Explanation
State is the secret handshake sticker you put on the outbound letter and demand back unchanged. If a stranger forges a return with some other code, the missing or wrong sticker gives them away.
Full Explanation
The state parameter binds the returning redirect to the school-district parent portal’s original authorize request. On return, the app must verify that state matches what it stored for that attempt; mismatched or missing state means a forged redirect carrying an injected authorization code should be rejected. Omitting state removes that CSRF-style binding from the grant step and leaves the callback under-authenticated.
State is not encryption of access tokens at rest inside DNA Center. It does not automatically rotate the client secret after every successful token response. It does not convert authorization codes into Webex room identifiers—those are unrelated platform concerns that do not substitute for request binding. Rotate or clear stored state after successful consumption so replayed callbacks with an old state fail. Parent-portal logs should record state mismatch events as security signals, not as benign “try again” noise, because injected codes are the threat model.
Exam caveat: generate unpredictable state per authorize attempt, store it server-side or in a protected cookie, and reject callbacks that lack an exact match. Operational check: start a grant, capture issued state, complete consent, assert the callback’s state equals the stored value; then attempt a callback with altered state and confirm the code is discarded unused.