Audit Logging for Auth Events: What to Log, What Not to Log, and Why the Difference Matters
Audit Logging for Auth Events
Every authentication event is evidence. A successful login is evidence of access. A failed login is evidence of an attempt. A token refresh is evidence of continued activity. A password change is evidence of credential modification. A permission escalation is evidence of authorization change.
Without audit logging, incident response is guesswork. “Was the account compromised?” becomes unanswerable. “When did the attacker first access the system?” has no data to answer it. “What did they access?” cannot be determined.
What to Log
| Event | Why it matters |
|---|---|
| Login success | Access timeline, session start |
| Login failure | Attack detection, account compromise indicator |
| Token issued | What client, what scopes, what TTL |
| Token refreshed | Session continuation, scope changes |
| Token revoked | Voluntary logout vs forced revocation |
| Password changed | Self-service vs admin-initiated |
| MFA enrolled/removed | Security posture change |
| Permission changed | Authorization scope modification |
| Account locked/unlocked | Attack indicator or false positive |
What NOT to Log
Credentials. Passwords (even hashed). Tokens (even partially). Session IDs that could be replayed. PII beyond what is needed for identification (username or user ID, not email address in every log line).
Log Structure
Auth logs must be structured (JSON), not free-text. Free-text logs are unparseable at scale. A structured log entry:
{
"timestamp": "2024-07-15T14:23:01.442Z",
"event_type": "AUTH_LOGIN_SUCCESS",
"user_id": "usr_abc123",
"tenant_id": "acme-corp",
"client_id": "frontend-shell",
"ip_address": "203.0.113.42",
"user_agent": "Mozilla/5.0...",
"session_id_hash": "sha256:a1b2c3...",
"mfa_used": true,
"grant_type": "authorization_code"
}What This Chapter Covers
Section 1: Implementing secure auth event logging in Spring Security. Using Spring Security’s AuthenticationEventPublisher, structured logging with SLF4J and MDC, and ensuring auth events are never logged at DEBUG level (where they can be silently disabled in production).
Section 2: Incident detection from auth patterns. Building alerts from log data: credential stuffing signatures, impossible travel, session anomalies, and privilege escalation sequences.