Errors and denied access

An authorization request is denied

When the return address is valid, our example server can return a denial through the browser:

https://printer.example/oauth/callback
  ?error=access_denied
  &state=demo-attempt-7
  &iss=https%3A%2F%2Fauth.photos.example

The client still validates the transaction and expected issuer. An error response does not bypass those checks.

access_denied can mean the resource owner or the authorization server denied the request. The printer should not always translate it into "You clicked Cancel," because policy may have refused access without that action.

A suitable message is: "The photo account was not connected. You can continue without it or try again." No token exchange follows this denial because no authorization code was issued for the client to redeem.

If the client ID or redirect URI is invalid, the authorization server must not send the browser to an untrusted return address just to deliver an error. The user may remain on an error page at the photo service, and the printer may receive no callback.

A token request is rejected

An error at the token endpoint comes back directly to the client. For example:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "error": "invalid_grant"
}

This can cover an expired or previously used code, a code binding mismatch, or a failed PKCE verification. It does not identify one unique cause. invalid_client instead concerns failed client authentication, while invalid_request indicates a malformed request. The client should handle the documented error and HTTP behavior, not assume all failures have the same status or recovery path.

The person using the printer needs a clear next step. The developer needs enough safe diagnostic context to investigate. Record the stage, a local correlation ID, and a safe error category. Do not copy full callback URLs, authorization headers, codes, verifiers, or tokens into logs.

Optional error descriptions are untrusted text. Do not insert them into HTML as markup, and do not automatically follow supplied error links.

When the outcome is uncertain

Suppose the printer sends its token request, but the connection drops before it receives a response. The authorization server might have rejected the request, or it might have consumed the code and issued a token whose response was lost.

A timeout therefore means the client did not obtain a confirmed result. It does not prove that the server did nothing. Replaying a single-use code is not a reliable recovery strategy, and an invalid_grant on a retry would not prove that the first request failed.

For this teaching flow, the printer reports that it could not finish the connection and offers a fresh attempt. It does not silently remove PKCE, change the return address, or keep prompting for consent in a loop. More detailed retry and operational handling belongs in Implementation and operations.

A completed connection is one possible outcome. A denial, a rejected exchange, and an uncertain result each need an honest description and an appropriate next step.