A proposed redesign of the city’s permitting SSO returns an access token in the front-channel redirect fragment (implicit-style) and skips the code-for-token exchange. Relative to the official authorization-code happy path, what is wrong?
Select an answer to reveal the explanation.
Short Explanation
Handing the full badge through the lobby window (implicit) skips the secure back-room trade of ticket-for-badge. Official DEVCOR wants the authorization code path with that back-channel token exchange.
Full Explanation
Returning an access token in the front-channel redirect fragment (implicit-style) skips the back-channel code-for-token exchange. Official DEVCOR authorization-code construction keeps the token off the browser redirect and performs the swap at the token endpoint with client authentication. Implicit therefore fails the permitting SSO happy-path requirement even if a token appears to arrive faster in the fragment.
Implicit is not the preferred confidential-client grant for this objective. Requiring the fragment token to be posted to Meraki before any civic API call invents an unrelated platform hop. Omitting PKCE does not make implicit required—PKCE strengthens public clients on the code path; it is not a switch that mandates implicit delivery. Prefer confidential-client redirects that return only the code, with tokens confined to server memory and secure storage. If a redesign PR reintroduces fragment tokens, reject it against the DEVCOR happy-path checklist before it reaches the city’s permitting SSO.
Exam caveat: code grant with server-side token exchange is the tested happy path; front-channel token delivery is the discarded pattern relative to task 2.5. Operational check: ensure the redirect returns a code rather than access_token in the fragment, then confirm the token POST happens from the confidential backend before any permitting resource call.