Spots 
OAuth callback handlers are usually reviewed for the right reasons: state validation, PKCE, redirect URI checks, and token exchange errors. Logging often gets less attention. That is risky because the callback is where useful debugging data and highly sensitive protocol data meet.
The goal is not to stop logging. The goal is to create a clear boundary between evidence a developer can use and values an attacker could replay. This matters in a normal production login, and it matters even more in QA environments where a best throwaway email or free disposable email may be used as a test fixture and then copied into a ticket. The callback log is part of the attack surface
An OAuth callback can contain a code, state value, error details, scopes, a provider identifier, and a redirect URL. Some of those fields are safe to keep in a carefully controlled form. Others should never appear in plaintext logs. The common mistake is a single debug statement that serializes the whole request:
It looks convenient, but it quietly makes the logger responsible for understanding OAuth secrets. A later provider change can add a field, or a developer can turn on verbose logging during an incident. The result is often a log stream that contains more than the team intended.
This is also why callback logs should have their own threat model. Ask who can read application logs, how long they are retained, whether they are copied to a third-party tool, and wether support exports can include them. A value does not become harmless just because it is inside an internal system.
For request tracing, a narrow request ID for safer signup APIs is usually more useful than a raw callback URL. It gives the investigator a handle without turning the handle into a credential. Define a redaction boundary
Start with a deny-by-default rule: only fields explicitly selected by the callback handler may enter the structured log. Never log the authorization code, access token, refresh token, client secret, or a complete state value. Useful fields can include: a request ID generated by your service the callback outcome, such as success, state_mismatch, or exchange_failed the requested flow, such as login or link_account a hashed or truncated subject identifier, if your privacy review permits it elapsed time for the token exchange
Even a state value needs care. It is designed to bind the callback to a browser session, so logging it in full can help someone correlate or replay a request. If you need correlation, generate a separate server-side event ID. Do not use a secret as your trace ID just because it is already available. A safer structured log shape
Make the safe shape obvious in code. The callback should map provider input into an allowlisted event rather than passing the request object to the logger.
The type is not a security control by itself. A caller can still add an unsafe cast or log the original request elsewhere. Pair the shape with a code review rule and a test that fails if forbidden keys appear in the serialized event. That small bit of friction is more safer than relying on memory during an incident.
OAuth callback handlers are usually reviewed for the right reasons: state validation, PKCE, redirect URI checks, and token exchange errors.