Okta Workflows Security: Connections, Roles, Endpoints

Okta Workflows can create, change and deactivate users, groups and app access across your identity estate, yet its connections, roles and API endpoints are rarely reviewed with the care given to Okta admin roles. A Workflows connection to Okta acts with the OAuth scopes and identity of whoever authorised it, third-party connections hold tokens to HR, ticketing and SaaS systems, and an API endpoint flow can be exposed to anyone who knows its URL. This guide explains the Workflows trust model, the roles and resource permissions that govern it, how to secure the Okta connection and third-party connections, how to protect invokable flows, and what to monitor in the System Log. It is for Okta administrators, identity engineers and detection teams. Okta tenant hardening in general is covered in the Okta Security Hardening Guide.

Key takeaways

Workflows actions run as the authorising user. Okta Support states that Workflows API actions appear in the System Log under the user who authorised the Okta connection; use a dedicated service account so the identity is clear and does not break when a person leaves.
The Okta connection's power is its scopes. Initial authorisation needs super admin credentials, and the default scope set covers every Okta card. Customise scopes down to what your flows use.
Workflows Administrator is powerful despite having no Admin Console rights. It can create and authorise connections, edit every flow and read sensitive data in execution history; only a super admin can grant it.
Never leave an API endpoint flow public. Endpoint flows can be secured with OAuth 2.0 (client credentials with a private key JWT), a client token, or nothing; "None" means anyone with the invoke URL can run the flow.
Execution history is a data store. It holds card inputs and outputs, which can include tokens and personal data; restrict who can view it and prefer Execution Log Streaming, which excludes card values, for monitoring.

The Workflows trust model

Every flow runs with the credentials stored in its connections. Understanding which identity sits behind each connection is the core of Workflows security.

Component	Holds or grants	Main risk
Okta connection (current org)	OAuth token from the built-in Okta Workflows OAuth app, with the granted Okta API scopes, issued to the authorising user	Over-broad scopes; actions attributed to a personal admin account
Okta connection (another org)	OIDC web app in the target org with the Refresh Token grant; authorising users need continuous super admin privileges	A long-lived refresh token with super admin backing in a second tenant
Third-party connections	OAuth tokens or API keys for HR, ITSM, chat, cloud and SaaS apps	Standing access to many systems from one console; stale connections
API endpoint flows	An invoke URL, optionally protected by OAuth 2.0 or a client token	Public flows that change identities on request
Delegated flows	Flows that Okta admins run from the Admin Console; only super admins can assign them	Lower-privilege admins running high-privilege actions through a flow
Tables and execution history	Data written or read by flows; card inputs and outputs	Sensitive data and tokens readable by anyone with view access

Workflows connections are non-human identities in their own right: each has credentials, scopes, an owner (or not) and a lifetime. Inventory them as you would service accounts. See the How to audit Okta API tokens and service apps page for the related Okta API tokens and service apps.

Roles and resource permissions

Workflows has its own role model, managed partly in the Admin Console and partly in the Workflows Console.

Role	Scope	Key permissions	Who can assign it
Super admin	Org	Full control of Okta and Workflows; assigns the Workflows app and the Workflows Administrator role	Super admin
Workflows Administrator	Org	All folders, flows, tables, connections and execution history; can view and modify sensitive data generated by flows; builds connectors; no Admin Console permissions	Super admin only
Connection Manager	Org	Create and modify any connection; activate and deactivate flows	Super admin or Workflows Administrator
Workflows Auditor	Org	Read-only across most of Workflows	Super admin or Workflows Administrator
Folder Manager	Folder	Manage folder resources, assign folder roles, create folder connections (not OAuth 2.0 connections)	Super admin, Workflows Administrator, Folder Manager
Folder Editor	Folder	Modify, activate and deactivate flows; cannot assign roles	As above
Folder Runner	Folder	Run active flows and view execution history	As above
Folder Reader	Folder	Read-only; cannot run flows or view execution history	As above

Least privilege by folder: put flows for each team or purpose (joiner-mover-leaver, help desk, security response) in separate top-level folders and grant folder roles, not org roles. Only super admins and Workflows Administrators can create top-level folders.
Treat Connection Manager as privileged: it can change any connection and switch flows on or off, which is enough to redirect a flow's credentials or disable a security flow.
Folder Runner sees history: runners can view execution history, which may contain sensitive values. Use Folder Reader for people who only need to see flow logic.
Govern the roles: with Okta Identity Governance, Governance for Workflows manages access requests and certification campaigns for the Workflows Auditor and Connection Manager roles, and the Workflows Administrator role through governance for admin roles.
Manage membership in Okta: users and groups come from Universal Directory, so assign Workflows roles to Okta groups and control group membership as you would admin groups.

Securing the Okta connection

Use a dedicated service account: create a named account (for example svc-okta-workflows) used only to authorise the Okta connection. Okta Support recommends this so Workflows activity is easy to identify and does not fail when a personal account is suspended or deactivated.
Protect that account like an admin: phishing-resistant authentication, no email or SaaS use, sign-in restricted to admin network zones, and its sessions monitored. The Okta support system breach shows what happens when a service account credential ends up in a personal browser profile.
Customise scopes: on the connection's Permissions tab choose "Customize scopes (advanced)" and grant only the okta.* scopes your flows need, and grant the same scopes in the Okta Workflows OAuth app. Scopes not granted in the app are silently left out of the connection; cards that need them fail with an Insufficient Scope error, which is a safe failure.
Separate connections by purpose: a read-only connection for reporting flows and a write connection for lifecycle flows, each in its own folder, limit what a single flow can do.
Cross-org connections: for a connection to another Okta org, the OIDC web app holds a refresh token and its authorising users need continuous super admin rights. Limit app assignment to the service account, and review whether the cross-org flow is still needed.
Reauthorisation: Workflows Administrators and Connection Managers can reauthorise the Okta connection. Log and review each reauthorisation, because it can switch the identity behind every flow.

Third-party connections and secrets

Inventory every connection: list connector, nickname, authorising account, scopes or permissions, folders using it and last use. Remove connections no active flow uses.
Authorise with service identities: connections to HR, ITSM, Slack, Google Workspace, Microsoft 365 or cloud platforms should use dedicated integration accounts or app registrations with least privilege, not an administrator's personal OAuth grant. See the Machine-to-Machine OAuth (Client Credentials) Guide.
No secrets in flows or tables: do not store API keys, passwords or tokens as constants in cards or rows in Workflows tables. Use the connection's credential store or call a secrets manager. Tables and history are readable by roles that do not manage connections.
HTTP and custom API cards: raw HTTP calls often carry an authorisation header typed into the card. Review them in every flow export, and rotate any credential found.
Rotation: after rotating an integration account's credential, reauthorise the connection and confirm flows recover.

Protecting API endpoint and delegated flows

Security option	How the caller proves itself	Use it when
Secure with OAuth 2.0	OAuth client credentials grant with a private key JWT; the Okta authorisation server must approve the access token (custom authorisation servers are not supported)	Default for any flow that changes users, groups or access; callers are app integrations granted the scope
Secure with client token	A unique client token generated for the flow, passed as the `clientToken` query parameter or, more securely, the `x-api-client-token` header	Webhook senders that cannot do OAuth; send the token in the header only
None (public service)	Nothing: anyone with the invoke URL can call the flow	Only for flows that take no action and return no sensitive data; avoid

Prefer OAuth for anything privileged: it ties each call to a registered client that you can revoke.
Client tokens are bearer secrets: query parameters end up in proxy and web server logs, so use the header. Store it in the caller's secrets manager.
Validate input: an endpoint flow should check every field it receives (user ID formats, allowed group names) and refuse unexpected values, because callers can send anything.
Delegated flows: only super admins can assign delegated flows to Okta admins, and runs are logged as workflows.user.delegatedflow.run. Design them to perform one narrow action (for example "reset this user's MFA after a verified ticket") with checks inside the flow, so delegation does not become a route around admin role limits. Help desk social engineering was the reported route to Okta admin access in the MGM Resorts breach.

Monitoring Workflows in the System Log

Event or signal	Meaning	Action
`workflows.user.role.user.add` / `.remove`	Workflows role added to or removed from a user	Alert on any addition outside a change ticket
`workflows.user.role.group.add` / `.remove`	Workflows role added to or removed from a group	Alert; review group membership
`workflows.user.delegatedflow.run`	An admin ran a delegated flow	Correlate with tickets; alert on unusual volume
`workflows.user.execution_log_stream_connection.deactivate`	Execution log streaming turned off for the org	High priority: possible defence impairment
`workflows.user.flow.execution_log_stream.deactivate`	Streaming turned off for a single flow	Investigate which flow and why
`application.user_membership.add` for the Okta Workflows app	Someone was given access to Workflows	Review against the role request
Actions by the Workflows service account (user agent `Azuqua`)	Okta changes made by flows	Baseline per flow; alert on new event types or volumes, such as admin role grants

Execution Log Streaming: sends metadata about each flow execution (time, flow type, end state) to a logging service, without card-level input and output values.
Attribution checks: filter Okta events whose actor is the Workflows service account and whose client.userAgent.rawUserAgent is Azuqua; actions from that account with a different user agent suggest someone signed in as the service account directly.

For detection rules on the wider Okta event stream see the Okta System Log Detection Guide.

Rolling out Workflows controls

Inventory: export every folder and flow, list connections with their authorising accounts and scopes, list API endpoint flows with their security option, and list role holders.
Fix the worst first: change any public endpoint flow that acts on identities to OAuth 2.0 or client token, and remove unused connections.
Introduce the service account: reauthorise the Okta connection with the dedicated account in a test org or sandbox first, run each flow, then switch production during a change window.
Trim scopes: move the Okta connection to custom scopes, test every flow, and watch for Insufficient Scope errors.
Restructure roles: move people from org roles to folder roles; keep Workflows Administrator to two or three named people.
Turn on monitoring: forward System Log events above to the SIEM and enable Execution Log Streaming where available.
Roll back: keep flow exports and the previous connection details; if a flow breaks after a scope or identity change, reauthorise with the previous settings, fix the gap, and repeat.

Decision guidance

A small organisation with a handful of flows can run with one dedicated service account, one Workflows Administrator plus the super admins, and a quarterly manual review of connections and endpoints. A large organisation with dozens of flow builders should separate folders by team, assign folder roles through Okta groups governed by access certification, require change tickets for activating flows that write to Okta, and stream execution logs to the SIEM.

Detection and measurement

Public endpoints: number of API endpoint flows with security set to None; target zero for any flow that writes.
Connection ownership: share of connections authorised by a dedicated service identity rather than a person.
Scope minimisation: whether the Okta connection uses custom scopes, and the count of write scopes granted.
Privileged role holders: number of Workflows Administrators and Connection Managers, reviewed each quarter.
Stale connections: connections with no flow use in 90 days.
Unticketed changes: role changes and flow activations without a matching change record.

Common failure patterns

Connection authorised by a person: flows stop when that admin leaves, and every action in the System Log looks like the admin did it.
Default scopes forever: the Okta connection keeps every scope, so any flow editor can build a card that grants admin roles.
Public endpoint flows: a flow built for a quick integration test is left on None and can create or modify users for anyone who finds the URL.
Client token in the query string: the token lands in proxy, browser and SIEM logs and becomes a shared secret nobody can rotate safely.
Secrets in tables and history: API keys stored in a Workflows table, or tokens visible in execution history, readable by every Folder Runner.
Workflows Administrator treated as low risk: because it has no Admin Console rights, it is handed out widely, although its holders control every connection and flow.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-2 Account Management; AC-6 Least Privilege; IA-5 Authenticator Management; AU-6 Audit Record Review, Analysis, and Reporting; CM-3 Configuration Change Control	Service accounts, scopes and roles, connection credentials, monitoring, flow change control
NIST CSF 2.0	PR.AA Identity Management, Authentication and Access Control; DE.CM Continuous Monitoring	Access control and monitoring of automation
MITRE ATT&CK	T1098 Account Manipulation; T1078.004 Cloud Accounts; T1685 Disable or Modify Tools	Flows abused to change accounts, stolen automation identities, turning off log streaming
ISO/IEC 27001:2022 Annex A	A.5.15 Access control; A.8.2 Privileged access rights; A.8.32 Change management	Role design, privileged roles, change control for flows
OWASP Non-Human Identities Top 10	NHI2 Secret Leakage	Tokens and keys in flows, tables and endpoint URLs

Practitioner checklist

Authorise the Okta connection with a dedicated, strongly protected service account.
Switch the Okta connection to custom scopes and grant only what flows use.
Limit Workflows Administrator to a few named people and treat Connection Manager as privileged.
Use folder roles through Okta groups, and Folder Reader rather than Runner where history access is not needed.
Set every API endpoint flow that acts on identities to OAuth 2.0 or client token, with the token sent in the x-api-client-token header.
Remove unused connections and keep an inventory with owner, scopes and last use.
Keep secrets out of cards, tables and flow constants.
Forward Workflows role, delegated flow and log streaming events to the SIEM and alert on streaming being turned off.
Export flows regularly so you can review changes and roll back.

Okta Workflows security: lock down connections, roles and flow endpoints