Skip to main content


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 menu.

Log event latency

Log events are registered few minutes after the interactions.

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, app, or API.
  • 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

Enrollment, authentication and approval 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.

An enrollment 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

List of log events

The following table shows the events that are logged.

CategoryEventChannelnameEvent summary
RegistrationRegistration createdAppuaf.registration.createdEnrollment started
RegistrationRegistration redeemedAppuaf.registration.redeemedEnrollment token redeemed
RegistrationRegistration verifiedAppuaf.registration.verifiedEnrollment finalized
AuthenticationAuthentication createdAppuaf.authentication.createdApproval started
AuthenticationAuthentication redeemedAppuaf.authentication.redeemedApproval token redeemed
AuthenticationAuthentication verifiedAppuaf.authentication.verifiedApproval finalized
ManagementDe-registration createdAppuaf.deregistration.createdDevice de-registration requested
ManagementDe-registration verifiedAppuaf.deregistration.verifiedDevice de-registered
NoneFacetIDs viewedAppuaf.facet_id.viewedFacet ID requested
RegistrationRegistration createdFIDO2fido2.registration.createdEnrollment started
RegistrationRegistration verifiedFIDO2fido2.registration.verifiedEnrollment finalized
AuthenticationAuthentication createdFIDO2fido2.authentication.createdApproval started
AuthenticationAuthentication verifiedFIDO2fido2.authentication.verifiedApproval finalized
RegistrationRegistration createdSMSsms.registration.createdEnrollment started
NoneRegistration verifiedSMSsms.registration.verifiedSMS registration verified
AuthenticationAuthentication createdSMSsms.authentication.createdApproval started
NoneAuthentication verifiedSMSsms.authentication.verifiedSMS authentication verified
RegistrationRegistration createdRecoveryrecovery_code.createdEnrollment started
NoneRegistration verifiedRecoveryrecovery_code.verifiedRecovery code verified
ManagementRecovery codes deletedRecovery or emptyrecovery_code.deletedRecovery codes deleted
ManagementUser deletedUnknownuser.deletedUser deleted
ManagementDevice deletedUnknowndevice.deletedDevice deleted
ManagementDevice renamedUnknowndevice.updatedDevice renamed
ManagementLogs exportedUnknownlogs.exportedLogs 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.

Data retention

Log entries are retained for 550 days.

Logging failed events with integration errors

When an enrollment, 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:

Enrollment startedRegistration createduaf.registration.createdRegistration created
Approval startedAuthentication createduaf.authentication.createdAuthentication created
SMS or recovery code verifiedAuthentication verifiedsms.authentication.verifiedAuthentication 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.