A confidential client for a city GIS portal holds an authorization code after resident consent. Which step correctly obtains the access token?
Select an answer to reveal the explanation.
Short Explanation
The trade happens backstage: server calls the token desk with the code, secret, matching redirect URI, and grant_type=authorization_code. Doing that swap in a public browser bundle leaks the client secret.
Full Explanation
A confidential client for the city GIS portal exchanges the authorization code on the server: POST to the token endpoint with the code, client secret or other client authentication, the same registered redirect URI used at authorize time, and grant_type=authorization_code. That back-channel hop returns the access token without exposing the secret in the resident’s browser and without treating the code as already usable on resources.
Embedding the client secret in a public JavaScript bundle and posting the code from the browser leaks the confidential credential and violates confidential-client assumptions. Reusing the authorization code as if it were already a refresh token skips the token URL and fails. Asking the resource owner to paste the code into a Meraki dashboard form is not OAuth construction for this GIS portal.
Exam caveat: redirect_uri on the token request must match the authorize redirect_uri and the registered value, or the exchange is rejected as invalid_grant. Operational check: perform the token POST from server-side code only, verify grant_type and redirect_uri, confirm the secret never ships in the browser bundle, and parse access_token from the token response before calling GIS APIs.