Redirects and authorization codes
After the photo service finishes its interaction with you, your browser needs to return to the printer. The return address matters because the response can contain a credential.
Imagine changing the delivery address on a parcel after someone has packed it. It would not help to pack the right item if it then went to the wrong recipient. Similarly, a correctly issued authorization code can be exposed if the server sends it to an untrusted address.
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 is not automatically the same registered address. Accepting anything that begins with the printer's hostname is not a substitute for this check.
Our example uses HTTPS:
https://printer.example/oauth/callbackNative applications have additional redirect patterns, including special handling for loopback addresses. We will cover those in Application architectures rather than generalizing this web example to every client.
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-storeThe browser follows the Location address. The code is carried in the query string of the resulting request to the printer.
This example assumes the photo service supports authorization response issuer identification. Its iss parameter names the authorization server. We will explain the client's issuer check in Correlating requests and responses. This extension is not a parameter that every older OAuth deployment necessarily returns.
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.