[Core Modules]

Authentication Audit Logging Pipeline

After a brute-force campaign against a government agency's platform accounts, the security team needs to reconstruct exactly what happened: which accounts were targeted, which IPs were involved, when lockouts triggered,

Module metadata

After a brute-force campaign against a government agency's platform accounts, the security team needs to reconstruct exactly what happened: which accounts were targeted, which IPs were involved, when lockouts triggered,

Back to All Modules

Source reference

content/modules/auth-dual-write-audit-logging.md

Last Updated

Apr 2, 2026

Category

Core Modules

Content checksum

285b6b60ef9e1174

Tags

modulesreal-timecompliance

Overview#

After a brute-force campaign against a government agency's platform accounts, the security team needs to reconstruct exactly what happened: which accounts were targeted, which IPs were involved, when lockouts triggered, and whether any successful logins followed a series of failures. That reconstruction is only possible if the authentication event record is complete, consistent, and queryable. The Authentication Audit Logging Pipeline guarantees that by writing every authentication event to both the document store and PostgreSQL in the same operation.

The dual-write design closes a practical gap: lockout state fields can fall out of sync when only one persistence layer is updated. With every event mirrored to PostgreSQL, structured queries against account lockout status always return current information, not a stale snapshot from a partially-completed write.

Diagram

sequenceDiagram
    participant U as User
    participant A as Auth Service
    participant D as Document Store
    participant P as PostgreSQL
    participant S as Security Dashboard

    U->>A: Login attempt (web or mobile path)
    A->>A: Validate credentials
    A->>D: Write auth log record
    A->>P: Mirror lockout state (upsert on conflict)
    alt Login failed
        A-->>U: Return error
        Note over D,P: failed_login_attempts incremented in both stores
    else Account locked
        A-->>U: Return lockout response
        Note over D,P: account_locked_until written to both stores
    else Login success
        A->>D: Write login_success record
        A->>P: Clear lockout state
        A-->>U: Return session token
    end
    P->>S: Feeds real-time authentication metrics

Last Reviewed: 2026-04-02 Last Updated: 2026-04-14

Key Features#

  • Dual-Write Consistency: Authentication events are written to both the document store and PostgreSQL in every operation. Lockout state fields are mirrored to PostgreSQL after every update, so structured queries always reflect current state.
  • Structured Auth Log Records: Each entry captures event type, user identifier, tenant identifier, IP address, user agent, timestamp, and extensible metadata. Event types include login_failed, account_locked, login_success, and lockout_reset.
  • Account Lockout Mirroring: When a failed login triggers a lockout, the lockout state is persisted to PostgreSQL in the same operation. When lockout state is cleared, the cleared state is mirrored immediately.
  • Cross-Path Coverage: Both the standard web authentication path and the mobile authentication path generate identical auth log records, ensuring consistent audit coverage regardless of authentication method.
  • Organisation-Scoped Queries: All auth log queries are scoped by tenant and organisation, preventing cross-tenant visibility into authentication events and satisfying data sovereignty requirements.
  • Upsert Semantics: Auth log persistence uses upsert (ON CONFLICT UPDATE) semantics on the log identifier, preventing duplicate entries from retry logic or transient failures.

Use Cases#

  • Security Incident Investigation: Query the auth_logs table for all failed login attempts against a specific user or from a specific IP to identify brute-force attacks, credential stuffing, or compromised accounts
  • Compliance Reporting: Generate audit reports showing all authentication events for a tenant over a defined period, with structured fields suitable for SOC 2, ISO 27001, and EDF compliance evidence
  • Lockout Diagnostics: Trace the sequence of failed login attempts that triggered a lockout, including IP addresses and user agents, to support help desk resolution and forensic review
  • Operational Monitoring: Track authentication event volumes and failure rates across the platform to detect anomalous patterns indicative of systemic issues or coordinated attack campaigns

Integration#

The auth logging pipeline feeds into the platform-wide audit trail for unified event visibility, the security monitoring dashboard for real-time authentication metrics, and the compliance reporting system for regulatory evidence packages. All auth log entries are accessible through the admin interface and the platform API, scoped to the requesting organisation.