Redirects and authorization codes

Choosing the return address

For this web client, the photo service compares the requested redirect URI against the addresses registered for the printer using exact matching. A different path or an added trailing slash makes a different address, and the server rejects it. Accepting anything that begins with the printer's hostname is not a substitute for this check.

Our example uses HTTPS:

https://printer.example/oauth/callback

Installed applications receive the response in other ways, such as loopback addresses whose port is allowed to vary. Redirect URIs and client metadata, in Clients and registration, covers those cases rather than stretching this web example to fit them.

Returning the response

A successful response in our example looks like this:

HTTP/1.1 302 Found
Location: https://printer.example/oauth/callback?code=demo-code-7&state=demo-attempt-7&iss=https%3A%2F%2Fauth.photos.example
Cache-Control: no-store

The browser follows the Location address. The code is carried in the query string of the resulting request to the printer.

iss names the authorization server that sent the response. It comes from an extension to OAuth called authorization response issuer identification, so not every authorization server includes it. Our photo service does, and Correlating requests and responses explains how the printer checks it.

state carries back the value from the authorization request. The printer must validate it against its pending transaction. The presence of familiar-looking parameter names does not make a callback trustworthy.

Handling the code

The code is short-lived and single-use. It is associated with the client and redirect URI, and in this flow with the PKCE challenge. The printer should treat its contents as opaque: it presents the code to the token endpoint rather than trying to decode an account identifier or permissions from it.

Codes still need protection. A callback URL can accidentally end up in analytics, request logs, browser history, or referrer information. Keep the callback focused on processing the response, avoid third-party resources there, and move the browser to a clean application URL after handling it. Do not record the full callback query in application logs.

Using a code creates an opportunity for the token endpoint to perform additional checks before issuing an access token. It does not make redirect validation or credential handling unnecessary.