Log authentication events safely: authentication logging without tokens

How to log authentication events without leaking secrets

Log authentication events in a way that preserves forensic value while excluding secrets. Record who attempted an action, when, from where, and why it succeeded or failed; avoid storing raw passwords, full tokens, session secrets, or connection strings. The operational goal is authentication logging without tokens while keeping logs actionable for incident response, detection, and compliance.

Start with a minimal event schema: event type, timestamp, principal id, outcome, client IP, user agent, and a safe reference to any credential material. For credential material use non secret derivatives such as hashes, stable id prefixes, or audit identifiers. This reduces exposure while preserving the ability to correlate events across systems and time.

What to never put in authentication logs

Follow well established guidance and exclude sensitive secrets. OWASP explicitly recommends excluding passwords, access tokens, connection strings, keys, and raw session identifiers from logs (see OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html). The same protection applies to one time secrets used for magic links and password resets, and to raw session tokens described in session guidance (see OWASP Session Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html).

• Do not log plain passwords or secret answers.
• Do not log full authorization tokens or raw session tokens.
• Do not log private keys, connection strings, or PII beyond what your retention policy permits.

What to log instead

Record high value, low risk fields that help investigators and automation. Fields to include are event type, outcome code, user id or account id, API key visible prefix, timestamp, client IP, user agent, geolocation hint, device id, and failure reason classified by type. For any secret like artifact record only a safe derivative such as a truncated prefix or a strong hash. OWASP ASVS and logging guidance emphasize protecting sensitive data while meeting verification and audit requirements (see OWASP ASVS logging requirements: https://owasp.org/www-project-application-security-verification-standard/).

Examples of safe references: store API key visible prefixes (not the secret part), store the last four characters of a token only when that helps operator identification, or store an HMAC or SHA256 of the token value using an audit only key. Do not store the plain token. If you use a hash, document the hashing key rotation policy and treat the hashed outputs as sensitive when the same key is used by other systems.

Designing event records for authentication logging without tokens

A compact event record example that balances telemetry and secrecy might include: event, outcome, user_id, api_key_prefix, authentication_method, device_id, ip, user_agent, reason_code, correlation_id, and optional safe_reference. The safe_reference is a nonreversible or truncated value you can use to link an event to an in system artifact without exposing secrets.

// Node example: record a safe auth event after initiating a magic link request
// Do not log any magic link tokens or raw session identifiers
const event = {
  event: 'magic_link_requested',
  timestamp: new Date().toISOString(),
  userId: user.id,                    // application user id
  emailHash: sha256(user.email),      // one way hash for correlation
  authMethod: 'magic_link',
  clientIp: req.ip,
  userAgent: req.get('user-agent'),
  outcome: 'requested',
  reasonCode: null,
  correlationId: uuidv4()
};
logger.info('auth.event', event);

// Note: do not include the magic link URL, token, or raw session id in logs.

If your authentication library returns a stable, nonsecret id for a token or session, prefer that id. Many systems expose a visible API key prefix or an opaque session id that is safe when truncated. Own Auth, for example, stores application API keys with visible prefixes and hashes the secret portion. Use the visible prefix in logs rather than the secret itself. Do not assume a visible prefix is sufficient to reconstruct a secret.

Practical controls and operational rules

• Treat logs as sensitive data. Apply the same access controls, retention policies, and encryption in transit and at rest as for other sensitive telemetry.
• Redact automatically. Use structured log pipelines that remove common secret patterns and replace them with tokens like [REDACTED].
• Use context ids. Correlation ids let you link multi step flows without recording secret artifacts.
• Audit ingestion points. Validate that downstream analytics or third party loggers do not expand or store removed fields.

OWASP: logs should exclude passwords, access tokens, connection strings, keys, and raw session identifiers. See OWASP Logging Cheat Sheet for specific examples: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

Apply lifecycle awareness. Session management guidance warns that session identifiers, their expiration, and revocation are part of security operations. Design logging to capture session creation, revocation, and expiry events without recording raw session secrets. For example, record session created and session revoked events with the session id hashed or truncated, the issuing principal, and the revocation reason (see OWASP Session Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html).

Instrumentation and verification: map logging requirements back to the OWASP ASVS verification requirements so that auditors can confirm you are protecting sensitive data while providing adequate forensic records (see OWASP ASVS logging requirements: https://owasp.org/www-project-application-security-verification-standard/).