Learn Authentik - Events & Auditing

#Introduction

Episode 21 showed automation. The more that runs automatically, the more important the audit trail — who did what, when, and from where. Episode 22 covers event logs and auditing: reading events, inspecting system tasks, exporting via the API, integrating with SIEM, and setting up alerts on anomalies.

Think of it like the cameras and guest book in a building. Everyone may come and go, but there must be a record: who, when, and where to. When an incident happens, that record is the first evidence you open.

#The Event Log System

Every important action in Authentik produces an event: a JSON record containing information like the action, related user, application, IP address, and context metadata. Events are stored in the database and can be searched and filtered from the UI.

Because the volume can be large, mind the retention period and periodic cleanup — keeping every event forever will bloat the database over time.

#Event Types

Some of the most useful actions to audit:

Action	Meaning
`login`	Successful authentication
`login_failed`	Failed authentication
`logout`	User logged out
`user_creation`	A new user was created
`user_update`	User data was changed
`authorize_application`	An application accessed a resource
`model_created`, `model_updated`, `model_deleted`	Configuration changes
`policy_execution`	Policy evaluation results
`system_task_execution`	Background task run
`system_exception`	Internal error

Understanding these categories helps you know where to look when investigating a problem — like knowing which page of the guest book to open.

#Inspecting Events

Events → Logs in the admin provides search and filtering by action, user, or application.
Click an event to see the JSON details, including context like the IP address or the policy denial reason.

A good habit: every time login behavior feels odd, start here before touching configuration.

#System Tasks and Error Logs

Not everything runs on the main path. Authentik runs system tasks — background jobs like source synchronization, event rule execution, and other periodic tasks:

See their status at Events → System Tasks: successful, running, or error.
Internal errors appear as system_exception events; the combination of both is a good starting point for troubleshooting (covered further in episode 28).

#Exporting Events via the API

Events can also be fetched via the API — for example from the /api/v3/events/events/ endpoint — for analysis outside Authentik:

Fetch failed login events via the API

curl -s "https://auth.example.com/api/v3/events/events/?action=login_failed" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" \
  | jq '.results[] | {action, user: .user.username, client_ip, created}'

With the core/reputation endpoint from episode 19 and this event list, you have the material to map attack patterns in a data-driven way.

#Event Rules and Alerts

Authentik can react to events automatically via Event Rules (the Events → Rules menu). Here's how it works: a rule contains an event matcher policy to select events, then runs an action — for example sending an email or webhook notification. Example of creating a matcher via a blueprint:

Event matcher policy — failed login

version: 1
entries:
  - model: authentik_policies_event_matcher.eventmatcherpolicy
    identifiers:
      name: event-matcher-login-failed
    attrs:
      action: login_failed

This matcher is then bound to an event rule in the UI along with your chosen notification transport. The effect: every login_failed triggers an alert without a human needing to watch the screen.

#SIEM Integration

For environments that demand compliance, events need to flow into a central system:

Pull — a script schedules exports from /api/v3/events/events/ into a log pipeline (for example Loki or ELK).
Push — the webhook transport on an event rule pushes real-time events to receivers like Slack, or directly to a SIEM.
Keep events for the period your organization's rules require, and routinely verify the delivery flow still works.

#Alerts on Anomalies

A frequently used combination:

Alerts on repeated login_failed for privileged accounts, for example akadmin.
Alerts when authorize_application comes from an unknown application.
Dashboards comparing login_failed spikes per IP as an indication of brute force attacks.

Remember: the goal of alerts is to reduce noise, not add to it. Choose patterns that truly need human attention.

Tip

Test your event rules: intentionally trigger one failed login and confirm the notification arrives. An alert that's never been tested is worth the same as no alert.

#Closing

Summary of episode 22:

The event log records action, user, IP, and context in JSON.
System tasks and system_exception become the starting point for troubleshooting.
Events are exported via the API, pushed via webhooks, or pulled by a SIEM.
Event matchers and event rules create automatic alerts on anomalies.

In episode 23, we make sure all of it stays running: high availability with replicated servers, workers, and a data layer that shares the load. See you there!