Where should a confidential municipal client use its client secret during the authorization-code grant?
Select an answer to reveal the explanation.
Short Explanation
The secret is the shop’s back-door key for the token counter—not a hallway badge and not something you hand to visitors. Keep it on the token hop; never ship it to the browser or slap it on as Bearer.
Full Explanation
For a confidential municipal client, the client secret authenticates the client to the token endpoint during the authorization-code exchange. That is its place in the grant: proving which registered client is redeeming the code. It is not a substitute resource credential and must never be shipped to browsers, embed in authorize URLs, or presented as Bearer on civic APIs.
Using the secret as the Authorization Bearer value on every protected resource GET confuses client authentication with the access token the resource expects. Putting the secret in the resource owner’s browser as a hidden form field during consent exposes it to the resident and to XSS. Placing it in the authorize redirect query string next to response_type=code leaks it via history, proxies, and referrers. Rotate the client secret through the authorization server and the municipal secret store together when compromise is suspected, and revoke old secrets promptly. Never mirror the secret into mobile apps, browser storage, or ChatOps messages “for convenience.”
Exam caveat: confidential secrets stay server-side on the token hop; public clients use other protections such as PKCE instead of a shared secret in the browser. Operational check: grep front-end bundles and authorize URLs for the secret, confirm only the server token POST authenticates the client, and verify resource calls use the access token as Bearer—not the secret.