Audit Logs
Track and present information about the approved transactions or data access requests within an external client portal or provide an audit of transactions in an external CRM system or logging system.
Audit Logs
Audit Logs enable security engineers to identify and respond to suspicious activities, detect data breaches, and comply with regulatory standards that require data access and modification tracking.
Workspace administrators can observe user actions server-wide across the entire instance of SecureAuth tenant and its connected authorizers. You can find all audit data within your workspace in Dashboards > Audit Events.
 |
Audit events provide you with useful data such as who performed certain action and the time it happened. The events do not provide technical information itself, as they are focused on business data. For example, if the request for a token is denied, audit events do not provide information on why it is denied.
You can observe user actions such as:
Login events
Login events contain several actions that take place when users go through their login process. You can see that the user attempted to log in, that their request is accepted, or their login attempt failed.
Consent events
Consent events provide administrators with insight when consents are created, accepted, rejected, and revoked. Those events are especially useful in Open Banking and Open Data initiatives.
Authorization and client authentication events
When client applications go through the authorization and authentication process, administrators can see that, for example, authorization code is denied/issued, and, later on, that the client application successfully authenticated itself and the token was issued.
and more.
Detailed List of Audit Events
To know what audit events are available and what payload parameters are available for each event, check list audit events API reference and its audit_events.payload parameter.
External Logging with Event-based Notifications
Event-based Notifications allow you to build secure event communication between SecureAuth and third parties. For example, such communication could grant the ability to track and present information about the approved transactions or data access requests within an external client portal or provide an audit of transactions in an external CRM system. It is up to you to decide which events captured by SecureAuth are communicated via notifications. They could be, for example:
User consent grants and revocations in the Open Banking space
Registration of a new client application
Tokens being issued and revoked
New services being discovered by the authorizers
Event-based notifications are implemented via Webhooks (user-defined one-way HTTP callbacks triggered by events) added to a SecureAuth workspace. Each webhook is responsible for a single target URL. SecureAuth sends a notification together with a Webhook-specific API key to the target URL each time an event you set up to trigger the webhook occurs. HTTPS communication between SecureAuth and the target is enforced by default, but can be turned off by the administrator.
Note that not all events are captured by all workspaces. For example, if you subscribe to Open Banking events, and your workspace is not an Open Banking workspace, you won't get notifications since the data source (audit events) won't be available. For more information on audit events, read Getting Business Audit Data Using SecureAuth's Audit Events.