Keycloak User Events
You enable keycloak user events in your realm settings to record logins and password changes. The system writes each login action to a central log for your team to review. Most teams set up these logs to track who signs in and to catch bad login attempts. Still, broad roles still let logged-in users run risky commands on backend databases and servers. How keycloak user events work in your realm The identity server watches every step a person takes during the sign-in flow. When a person logs i
Keycloak + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You enable keycloak user events in your realm settings to record logins and password changes. The system writes each login action to a central log for your team to review. Most teams set up these logs to track who signs in and to catch bad login attempts. Still, broad roles still let logged-in users run risky commands on backend databases and servers.
How keycloak user events work in your realm
The identity server watches every step a person takes during the sign-in flow. When a person logs in, refreshes a token, or updates a profile, the server fires an event. Admins turn on event saving in the realm settings to keep these records in a database. You can also send these records to external log tools for long-term storage and alerts.
The system splits records into two main groups for better tracking. User events cover actions like sign-ins, logouts, code exchanges, and password resets. Admin events track changes made by operators, such as creating realms, adding roles, or updating client rules. Each record holds the user ID, IP address, client name, and a timestamp.
Teams use built-in listeners to route these records to the right place. One listener writes records straight to the local database for quick checks in the admin console. Another listener pushes the data to standard output so log shippers can read it. You can set an expiration time so old login records do not fill up your disk.
What identity logs solve and what they miss
Identity logs prove when a person signed in and which app asked for a token. Security teams read these records to spot brute-force attacks or logins from strange locations. Auditors also check these logs to verify that former staff members no longer sign in. This setup works well for tracking entry at the front door of your apps.
Yet identity logs stop watching the moment the user gets a valid token. The login server knows who signed in, but it cannot see what happens inside a database session. If an engineer logs in with a broad role, they might run a destructive query on production data. The login log shows a clean sign-in, while the actual SQL command goes unrecorded.
Keycloak + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The same gap appears when staff or AI agents run commands on servers or read sensitive tables. An identity record will not show if a query returns raw emails, phone numbers, or card numbers. It also cannot ask a manager to approve a risky command before it runs in flight. To control real actions, teams must inspect and filter requests at the database and command level.
Best practices for managing login event logs
Only save the event types that your security team needs to review. Recording every token refresh in a busy realm can slow down your database and fill storage fast. Set a clear retention limit in your realm so the server deletes old records on schedule. Send important login and admin records to an external log store so attackers cannot erase their tracks.
Pair your login records with fine-grained controls on your actual databases and cloud systems. Do not rely on broad identity roles to protect production tables or live servers. Check every query and command at runtime, and mask fields like national IDs or card numbers in results. This approach links the login record with the exact actions taken during the work session.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between user events and admin events in Keycloak?
User events record login actions taken by regular people, such as signing in or changing a password. Admin events record setup changes made by operators, such as adding new roles or changing realm rules.
Do keycloak user events log database queries or server commands?
No, these records only track identity actions like logins, logouts, and token refreshes. They do not see or record the SQL queries or shell commands a person runs after signing in.
How long does Keycloak keep saved user events?
By default, saved records stay in the database until an admin clears them or sets an expiration limit. You can set a retention timer in the realm settings to delete old records by default.