When reviewing the Okta System Log, the API actions performed by Okta Workflows show a user account as the Actor field. This article explains why these actions are attributed to a user account rather than Workflows.
- Okta Workflows
- Okta System Logs
Okta Workflows is authorized using the OAuth 2.0 Authorization Code flow. The token issued at the time of authorization is issued to the user account that is logged in when granting consent on the OAuth consent screen, and subsequent actions taken using that token will be logged under that same account.
To verify it was an action taken by Workflows, expand the logs for an event, and see if client.userAgent.rawUserAgent is Azuqua. See How to search System Log for actions taken by Okta Workflows for more details.
The actions being attributed to a user account are not strictly a problem, as this complies with OAuth design. However, there are some considerations involved. If the user account used to authorize the Workflows connection is in a Suspended, Deactivated, or Deleted state, or has its active sessions cleared, Workflows invoking Okta API functions will cease to function as expected, returning 401 Unauthorized or 403 Forbidden, depending on the scenario.
In many cases, it is a better practice to create a specific Super Admin service account for Okta Workflows and authorize the connection with that account. This will attribute any actions taken to a descriptively named account and help to avoid scenarios where the account is Suspended, Deactivated, Deleted, or has its active sessions cleared mistakenly.
