Overview

A service account can authorize a connection in Okta Workflows regardless of how that account signs in to the target application. The three supported sign-in cases include:

• A target application with its own login separate from Okta
• A target application that signs in through Okta
• A target application that is Okta itself

Solution

Case 1: A target application with its own login separate from Okta

The service account signs in to the target app using a username and password managed by that 3rd-party app. Sign out of the target app in the browser, then sign in to Workflows and complete authorization using the service account credentials:

1. Sign out of the target app in the browser.
   1. Alternatively, open a private or Incognito window, or a separate browser that is not normally used to sign in to the target app.
2. Sign in to Okta Workflows.
3. Start authorizing the connection, and enter the service account credentials when prompted.

NOTE: No changes in Okta are required for this case.

Case 2: A target application that signs in through Okta

This case requires temporarily granting the service account access to Okta Workflows, authorizing the connection as the service account, and then removing that temporary access. Assign the service account to the Okta Workflows app, sign in as the service account in a separate browser context, create the connection, then sign out and remove temporary access.

1. Temporarily assign the service account to the Okta Workflows app. A super admin role is not required — Workflows admin, or Connection Manager within Workflows, is sufficient.
2. In an Incognito window or a different browser, sign in to Workflows as the service account.
3. Create the connection to the target application.
4. Sign out.
5. If the service account does not need to remain in Workflows for any other purpose, remove it from the Workflows app and revoke the permission granted in step 1.

The connection remains authorized as the service account. The app assignment and admin role are only required while creating the connection, so it is safe to remove them afterward if they are not needed for any other purpose.

Case 3: A target application that is Okta itself

When the target application is Okta itself, specific permissions must remain in place for as long as the connection must continue working — unlike Case 2, temporary access is not sufficient. Assign the super admin role and the Okta Workflows OAuth app to the service account, sign in as the service account in a separate browser context, then create the connection to Okta.

1. Assign the super admin role to the service account (authorize the Okta connection as a super admin).
2. Assign the service account to the Okta Workflows OAuth app — this is a separate application from the Okta Workflows app used for Workflows Console access.
3. In an Incognito window or a different browser, sign in to Workflows as the service account.
4. Create the connection to Okta.
5. Sign out.

Keep both the super admin role and the Okta Workflows OAuth app assignment in place for as long as the connection needs to work. Removing either one can break the connection.

NOTE: If the service account is not assigned to the Okta Workflows OAuth app, creating or reauthorizing the connection can hang with a spinning wheel instead of completing.

Related References

• Okta Workflows Microsoft Connector Disconnecting Frequently / Re-Authorize Step-by-Step Guide
• Okta Support – Actions Taken by Okta Workflows are Attributed to a User Account in the System Log