What log level reveals OAuth redirect_uri mismatches without leaking secrets?

Short answer

There is no universal log level for this. On the client side, the redirect_uri value in a failed token exchange normally appears at DEBUG — but only when that level is scoped to the library's OAuth package (for example, the org.springframework.security.oauth2 loggers in Spring Security's client). On the authorization server side you usually need no extra verbosity at all: a compliant server rejects an unregistered redirect_uri and records the failure in its normal audit or event stream, typically at WARN or INFO. Start with the server's audit log, and fall back to scoped client DEBUG only if the server log does not name the URI.

What is established vs. implementation-specific

Established behavior: under RFC 6749 the server must not redirect to an unregistered redirect_uri and instead returns an OAuth error (invalid_request or invalid_grant with an error_description). The client secret is not part of that check — it travels in the token request body or a Basic auth header, separate from redirect_uri validation — so a redirect_uri error message has no inherent reason to contain it.

Implementation-specific, and worth verifying against your deployed versions: the exact logger names, whether the full URI value is printed at DEBUG or only the fact of a mismatch, and whether the server redacts or truncates the URI. Many servers deliberately omit or truncate redirect_uri in logs to prevent log injection and open-redirect phishing, so an absent value does not mean validation was skipped.

Steps for this case

1. Reproduce the failing token request against a staging server, not production.
2. Read the authorization server's audit/event log at its default level first (Keycloak's login-error events are one common example) and note whether the requested redirect_uri is recorded.
3. If the URI is not there, enable DEBUG only on the OAuth/OIDC client package. Do not raise the root logger, and do not enable HTTP request/response or filter logging.
4. Compare the logged redirect_uri with the value registered for the client. Mismatches are most often a trailing slash, an http/https scheme difference, or a missing path segment.

Confirming the level does not leak secrets

After enabling the level, search the same log for secret material and expect zero hits:

grep -F 'redirect_uri' client.log
grep -FiE 'client_secret|authorization: basic' client.log   # expect no output

The realistic leak risk is not the OAuth logger itself but broad TRACE levels or request-dumping filters, which capture form parameters and headers containing client_secret, authorization codes, and tokens. Keep those disabled in production and do this diagnosis in staging.

Server-side redaction controls

There is no cross-vendor switch. Whether the authorization server redacts the redirect_uri or other request parameters is governed by its own audit/event configuration — for instance, whether its event store persists request parameters, and any sanitize or truncate setting applied to logged URIs. Check your server's audit-logging documentation for the option controlling which request parameters are persisted, and treat any logged URI as untrusted input, since its query string can be attacker-crafted.

One detail that would change the recommendation

Which client library and authorization server, and at which versions? Logger names, whether DEBUG prints the full URI, and the exact redaction option differ enough between stacks (Spring Security, Keycloak, and others) that the specific logger name and configuration key can only be confirmed against your deployed versions. The sequence above is the safe generic path; the exact settings should be treated as a draft pending that verification.