Logs

Authentication Cloud creates log events of service interactions. This gives you the possibility to view and analyze your data for potential issues, without the need to contact the customer support team. You can also use the logs to provide data for support, or for audit purposes. You can access the logs on the Management Console under the Logs sidebar item.

Log event latency

Events are registered and processed asynchronously. Because of this, a delay of several minutes can happen between the interaction and its appearance in the log.

The log overview table contains the following data:

• Date: the date and time of the event.

• Category: the category of the event. The category can be registration, authentication, or management. If the event cannot be categorized, the category is None.

• Event: the status and name of the event. The status can be succeeded or failed, and it is indicated with a green or red icon respectively.

• Channel: the authentication channel used for the event.

• Initiated by: the type of the actor that initiated the event. This can be user, admin, API, or app.

  • User: the action was initiated by an end-user.
  • Admin: the action, under the Management category, was initiated through the Management Console.
  • API: the action was initiated through a REST API request.
  • App: the action was initiated on a mobile app, such as the Access App.

• Target user: the username of the target user. If the event does not have a target user, this field is marked as Unknown.

When you click on a log entry, you can access the log details with additional data.

You can search for specific events using a free-text search, or use the filtering options to narrow down the list of events.

Operations with multiple events

Registration, authentication and approval operations include multiple subsequent events that are logged separately. The entire operation is only successful if every event is successful. In some cases, for example, when an operation is aborted, not every event is logged. For more information, see the Logging unfinished operations section.

A registration operation includes the following events:

1. Registration created
2. Registration redeemed (only applicable when the channel is app)
3. Registration verified

An authentication or approval operation includes the following events:

1. Authentication created
2. Authentication redeemed (only applicable when the channel is app or push)
3. Authentication verified

Reaching the push or SMS rate limit includes the following events:

1. Authentication created with status=failed
2. SMS or push authentication rate limited

List of log events

The following table shows the events that are logged:

Category	Event	Channel	name	Event summary
Registration	Registration created	App or push	uaf.registration.created	Registration started
Registration	Registration redeemed	App or push	uaf.registration.redeemed	Registration token redeemed
Registration	Registration verified	App or push	uaf.registration.verified	Registration finalized
Authentication	Authentication created	App or push	uaf.authentication.created	Approval started
Authentication	Authentication redeemed	App or push	uaf.authentication.redeemed	Approval token redeemed
Authentication	Authentication verified	App or push	uaf.authentication.verified	Approval finalized
Management	De-registration created	App or push	uaf.deregistration.created	Device de-registration requested
Management	De-registration verified	App or push	uaf.deregistration.verified	Device de-registered
None	FacetIDs viewed	App or push	uaf.facet_id.viewed	Facet ID requested
Authentication	Push authentication rate limited	Push	uaf.authentication.ratelimited	Rate-limited push authentication attempt
Management	Rate limit reset for user	Push or SMS	user.ratelimit.deleted	User unblocked
Registration	Registration created	FIDO2	fido2.registration.created	Registration started
Registration	Registration verified	FIDO2	fido2.registration.verified	Registration finalized
Authentication	Authentication created	FIDO2	fido2.authentication.created	Approval started
Authentication	Authentication verified	FIDO2	fido2.authentication.verified	Approval finalized
Registration	Registration created	SMS	sms.registration.created	Registration started
Registration	Registration verified	SMS	sms.registration.verified	SMS registration verified
Authentication	Authentication created	SMS	sms.authentication.created	Approval started
Authentication	Authentication verified	SMS	sms.authentication.verified	SMS authentication verified
Authentication	SMS authentication rate limited	SMS	sms.authentication.ratelimited	Rate-limited SMS authentication attempt
Registration	Registration created	Recovery	recovery_code.created	Registration started
Registration	Registration verified	Recovery	recovery_code.verified	Recovery code verified
Management	Recovery codes deleted	Recovery or empty	recovery_code.deleted	Recovery codes deleted
Management	User deleted	Unknown	user.deleted	User deleted
Management	Device deleted	Unknown	device.deleted	Device deleted
Management	Device renamed	Unknown	device.updated	Device renamed
Management	Logs exported	Unknown	logs.exported	Logs exported

In some cases, the Event column might not match the name and the description field. For more information, see the Logging failed events with integration errors section.

Exporting logs

To export your logs to CSV, click the three vertical dots menu in the top-right corner. The following options are available:

• Export logs: Export every log generated in the last 24 hours.
• Export filtered logs: Export the currently filtered logs. This option is only enabled if a filter is applied.

The maximum number of records that can be exported in a single export is limited. The default limit configured on each instance is 10000 records. If you want to customize this limit, submit a request on our Support portal.

You can export logs with an API call as well. For more information, see the Log export endpoint documentation.

info

CSV exports are protected from code injection through a full escaping solution. See How are the logs and reports functions protected from code injection for details.

Data retention

Log entries are retained for 550 days.

Logging failed events with integration errors

When an registration, approval, or verification operation fails due to an integration error, the Event column in the table and the corresponding name and description fields in the JSON file might not be accurate. Instead, these fields have the following default values, regardless of the authentication channel:

Operation	Event	name	description
Registration started	Registration created	uaf.registration.created	Registration created
Approval started	Authentication created	uaf.authentication.created	Authentication created
SMS or recovery code verified	Authentication verified	sms.authentication.verified	Authentication verified

This inaccuracy can happen in the following cases:

• The provided userId does not exist. For example, the user was deleted.

• The request is badly formed with issues such as the following:

  • channel is missing or incorrect

  • displayName is missing or incorrect for fido2 channel

  • userId or authenticatorId is not a UUID

  • statusToken is included for recovery channel

    For more information on the use of parameters, see the Developer documentation.

Logging unfinished operations

An operation can include multiple events. For example, an approval operation includes an event for starting the approval, redeeming the token, and finalizing the approval. Each of these events are logged separately. If the entire operation is unfinished, an event can be still logged as succeeded. In this case, the subsequent event or events are not logged. The following example demonstrates this use case:

1. The user starts and completes an approval operation.
2. The Approval started event is successful and it is logged.
3. The user aborts the operation but does not redeem the approval token.
4. The Approval token redeemed and the Approval finalized events are not logged.