Redirect and code flow

The redirect URI keeps being rejected as unregisteredCopy Anchor Link

Check three things:

1. Does it have a non-root path — https://example.com fails, https://example.com/cb works;
2. Is the scheme https — only loopback addresses may use http;
3. Does it contain a query string or # fragment — neither is allowed; it must match the registered value verbatim.

The redirect_uri in the authorization request must match the registered value exactly; one extra slash is rejected. See Redirect URI policy.

Testing callbacks locallyCopy Anchor Link

Use a loopback address: http://127.0.0.1:port/callback or http://localhost:port/callback. Only loopback may use http; everything else must be https. Register that loopback address as its own client rather than mixing it with the production address.

Why implicit flow or the password grant is unsupportedCopy Anchor Link

Third-party applications have exactly one path: authorization code + PKCE (S256). Other flows are rejected outright.

• The implicit flow puts tokens in the URL fragment, where they leak into logs and browser history;
• The password grant requires the application to handle user passwords, violating the premise that an application should never see credentials.

Can an authorization code be reusedCopy Anchor Link

No. Codes are single-use and die once exchanged. Reuse yields invalid_grant; see Token exchange and refresh.

RelatedCopy Anchor Link

• Full flow steps: Authorization code flow
• Redirect URI matching rules: Redirect URI policy