Okta Certified Workflows - Specialty · Part I

Workflows Overview

27% of Part I — the exam's largest single knowledge area alongside Building Flows.

Workflows Overview

Sub-topic 5: Webhook-Exposed vs. Public-Service-Exposed Flows

7 sub-topics · this deck covers sub-topic 5 of 7

The Task

"There are three ways of securing your API endpoint for Okta Workflows."

An API Endpoint flow (Sub-topic 2) can be invoked by any external client that calls its designated endpoint with valid security credentials — but "valid" depends entirely on which of three security levels you chose when configuring the endpoint. The exam focuses on the two ends of that spectrum: registered-webhook-with-a-client-token vs. wide-open public service.

Security Level 1 — OAuth 2.0

The endpoint is secured with OAuth 2.0 scoped access tokens. An admin adds the appropriate scopes to any app integration that needs to call the API. This method supports the OAuth client credentials grant type using a private JSON Web Token (JWT), and the flow triggers only after the Okta authorization server receives and approves the access token. Custom authorization servers aren't supported for this method.

Security Level 2 — Client Token (Webhook-Exposed)

"The API endpoint flow is registered as a webhook and is secured through a unique client token. It's only accessible if the requesting service passes the proper client token through the invoke URL."

Selecting Secure with client token auto-generates a client token, added as the alias value in both the Invoke URL and Resume URL. To call it, the requester passes that token either as the clientToken query parameter (default behavior) or in the x-api-client-token header (the more secure option — don't use both together).

Security Level 3 — None (Public Service)

"The API endpoint flow is publicly available to anyone with the invoke URL... you don't need to pass along any authentication options in the request to invoke a flow."

Selecting None (public service) makes the invoke URL itself the only barrier — no token, no header, nothing else to check. To invoke either a client-token or public-service flow, the caller performs a GET or POST to the Invoke URL (POST if data needs to go in the request body). After invocation, the flow sends its output back as a response object.

The Common Thread — Flow Aliases

Both the client-token and public-service invoke URLs are "constructed using a flow alias" — the alias is what makes the URL predictable/reusable rather than an opaque, ever-changing address. This is why rotating or exposing a public-service flow's URL is effectively equivalent to handing out an unauthenticated API key.

The Gotcha — One Security Setting Per Flow

"A flow can have only one endpoint security setting" — you can't mix OAuth 2.0 for some callers and a public URL for others on the same flow. This also means Pause and Pause Raw cards (which generate their own resumption URL as a second endpoint) can't be used inside a Delegated flow, since that would create a second, conflicting security boundary. Use a helper flow instead — its endpoint security can differ from its parent's.

The Connection

This sub-topic is a deep dive on one branch of Sub-topic 2 (API Endpoint flows). It also foreshadows Sub-topic 6: public-service and client-token flows are exactly the kind of "synchronous," externally-callable flows Okta's execution-limits documentation places in the Yellow Zone, subject to a 60-second synchronous timeout.

The Angle — What Trips People Up

→ Assuming "webhook-exposed" and "public service" are the same thing — a client-token webhook still requires a secret (the token); public service requires nothing at all.

→ Passing the client token in both the query parameter and the header at once — Okta's docs explicitly say not to combine them.

→ Forgetting custom authorization servers aren't supported for the OAuth 2.0 security level — only the standard Okta authorization server applies.

One Line To Remember

An API Endpoint flow has exactly one of three security levels — OAuth 2.0 (scoped access tokens, client credentials grant, no custom auth servers), client token (webhook-registered, token via query param or header), or None/public service (anyone with the alias-based invoke URL, no auth at all) — and a flow can only ever have one endpoint security setting.

Sources: help.okta.com — Invoke a flow with an API endpoint (ext-invoke-api-endpoint-flow); Invoke a flow with an API as a public service; Invoke a flow with an API endpoint using a Client Token; Flow endpoint security limits

Next: Sub-topic 6 →