Personal data in audit events
SecureAuth Connect audit events record who did what, when, and from where. Many events therefore include personal data, such as the IP address and device behind a request and the user's identifiers. This page is for administrators who forward audit events to a SIEM or logging system. It explains which fields contain personal data and shows how to limit what you store.
The admin console, the list audit events API, and webhooks all expose the same fields.
Fields in metadata
Every event has a metadata object. It carries the request context, such as the network, location, and device behind a request, and the identifiers of the users and session involved. These are personal data under GDPR. For the full list of fields, and which of them are personal data, see Metadata fields.
Configuration IDs in metadata, such as client_id, idp_id, and user_pool_id, identify the setup involved in the event, not a person.
Events with personal data in the payload
Some event payloads contain personal data in addition to the metadata:
| Event subject and action | Personal data in the payload |
|---|---|
user created, updated, deleted | The user's profile, identifiers, and addresses. |
user authenticated | The identifier the user typed, for both successful and failed sign-ins. |
otp, all actions | The address the code was sent to, such as an email address or phone number. |
password and credential reset events | The identifier used for the reset. |
jit failed | The user record that was to be provisioned. |
saml_assertion issued | The SAML NameID. |
gateway_request, gateway_policy | The claims of the access token presented to the protected API. |
script executed | The extension's standard output, standard error, and caught error. Without debug, standard output and standard error are cut to 80 characters each. With debug enabled for the extension, they are recorded in full, together with the extension's input and output. Values from your secrets store are masked in every case, but anything else the extension prints is recorded as is. |
CDR consent | Account IDs and the customer ID. |
authorization_code, access_token, saml_assertion, id_jag, gateway_*, and dcr created or rejected | The client IP address and forwarding headers, user agent, location, subject, session ID, and dbfp (the device fingerprint cookie value). |
login attempted, accepted, and failed payloads contain the identity provider's ID, name, and method, the authentication methods used (amr), and an error description on failure. They don't contain the user's email address, name, or profile. For login events, personal data is in metadata. When an authorization request enables debug mode, login accepted events also include the identity provider's response in idp_input. In debug mode, idp_mapping_details also holds the input and output values of each attribute mapping.
SecureAuth doesn't write passwords or password hashes, one-time codes, client secrets, tokens, or authorization codes into audit events. The exception is extension output: an extension can print any value it handles, so review script events before you forward them.
How the subject format affects identifiers
subject follows the workspace subject format. With the hash format, subject is a one-way hash, so it doesn't reveal the identity provider's value. With the legacy or custom format, it holds the identity provider's subject or the attribute you chose, which can be an email address.
idp_subject always holds the identity provider's original value, whatever the subject format. For users who sign in with an identity pool, that value is the pool's opaque user ID.
Forward events to a system with a data-minimisation policy
If your SIEM or logging system may store only some personal data, reduce what reaches it:
- Subscribe the webhook only to the event subjects and actions you need.
- In your pipeline, drop or hash the personal-data fields your policy excludes before they are indexed. For a Logstash example, see Integrating external logging solutions.
- If you need to correlate events by user without storing the raw identifier, use the hash subject format so that
subjectis a hash.idp_subjectstill holds the raw value, so drop or hash it in your pipeline. - Use an HTTPS endpoint with a valid certificate, and keep Developer mode off for the webhook. See Secure the receiving endpoint.