OAuth callback flows for third-party developer tools

An authorization round trip fails in a small number of specific places, and nearly all of them are visible in what the provider sent back rather than in your own logs.

• The redirect URI the provider received, character for character — a trailing slash or a different host is the most common cause.
• The state value, which must match the one that started the flow; a mismatch is a refusal, not a warning.
• The PKCE verifier and challenge pair.
• The provider's own error code and description, which usually names the real problem directly.

1. loginStartXOOZLY sends the user to the provider with a redirect URI, a state value and a PKCE challenge.
2. verified_userThe provider authenticatesWhatever happens here is the provider's own screen; XOOZLY sees nothing until the user comes back.
3. call_receivedCallbackThe provider returns to the redirect URI with a code, the state it was given, and — if something went wrong — an error code instead.
4. swap_horizExchangeThe code plus the PKCE verifier are exchanged for tokens. A mismatched state or verifier is refused here, not warned about.

• The redirect URI does not match what the provider has registered, character for character — a trailing slash or a different host is the most common cause by a wide margin.
• The state value does not match the one that started the flow, which is a refusal rather than a warning.
• The transaction has already been completed; it is deleted atomically on completion, so a replayed callback finds nothing.
• The provider itself returned an error, in which case its own description usually names the real problem directly.