Identifying Who Deactivated an Okta Custom Authorization Server

An Okta administrator can determine when a custom authorization server was deactivated and by whom by reviewing the Okta System Log and searching for the oauth2.as.deactivated event or the specific custom authorization server ID. Expanding the log event reveals the administrator (actor) who performed the action, the affected server or policy (target), and the exact timestamp of the modification.

• Okta Classic Engine
• Okta Identity Engine (OIE)
• System Logs
• API Access Management
• Custom Authorization Servers

A custom authorization server or its associated policy/rule was deactivated due to an explicit administrator action or environment configuration change, necessitating an audit trail investigation.

What steps reveal the Okta administrator who deactivated a custom authorization server?

To identify the source of this change, review the Okta System Log for events related to configuration changes by following these steps:

1. Log in to the Okta Admin Console.
2. Navigate to Reports > System Log.
3. In the search bar, search for:

   eventType eq "oauth2.as.deactivated"

4. Alternatively, search directly using the affected custom authorization server ID.
5. Expand the log event to review the specific details:
   • The display name and type of the policy or rule that was deactivated.
   • The Okta administrator who performed the action (including their display name and alternate ID).
   • The timestamp and Universally Unique Identifier (UUID) of the event.