End-User Authentication

Authenticate end users mid-conversation

End-user authentication is how an agent verifies who someone is, during a conversation. The platform supports two paths: validate a token the embedding site already supplies, or prompt the user to sign in mid-conversation. Either way, the verified claims become workflow inputs you can use to personalize answers, gate sensitive actions, or route conditionally.

Advanced feature: End-user authentication is one of the platform's most powerful capabilities. See the Key Terms for any unfamiliar vocabulary.

How Authentication Works

Authentication is how the platform verifies who the end user actually is. Once verified, the user's name, email, and other claims become variables the workflow can read for the rest of the session. The platform supports two modes for authenticating end users. The mode is selected automatically, based on whether a valid pre-auth token arrives with the conversation.

A few platform behaviors keep the authentication experience smooth at runtime.

Auto-Resume

The conversation picks up at the exact node once the user completes the sign-in

Automatic Token Refresh (Supported)

Expired tokens refresh in the background so long sessions never re-prompt the user

Identity in the Workflow

Verified claims become Auth.* variables that any node can read

Per-Host Validation

Add a separate token provider for each embedding context, validated independently

Channel availability: End-user authentication is available only on Webchat. Other channels are not yet supported.

Prerequisites

The two modes have different prerequisites. Confirm the right pieces are in place before enabling either on a live agent.

Pre-Authenticated Tokens

No Workspace integration needed. The embedding site must already authenticate the user against an external identity provider, then deliver the token to Webchat via setAuthToken or customData.

Interactive Sign-In

This mode requires an OpenID integration to authenticate users with your identity provider. Set up the integration in Workspace > Integrations.

Configure Authentication for an Agent

Authentication is configured per agent under Designer > Security. The page has two independent sections:

• pre-authenticated tokens

• interactive OIDC sign-in

Configure at least one for the agent to authenticate users. Both can run side by side if your deployment needs them.

1

Enable OIDC Sign-In (Optional)

Toggle OIDC Authentication on and pick an integration. Adjust the claims and email-verification options as needed.

OIDC Authentication configuration

• OIDC Integration: The Workspace OpenID integration used for interactive sign-in. Configured in Workspace > Integrations.

• Additional Claims: Comma-separated list of extra claim names to extract from the ID token, beyond the standard ones. Example: preferred_username, tid, groups.

• Require email verification: When enabled, sign-ins are rejected unless the identity provider returns email_verified: true

2

Add a Pre-Auth Token Provider (Optional)

Skip if the agent will never be embedded in a page that already authenticates the user.

Toggle Pre-Authenticated Token Providers on, then select Add Provider for each distinct embedding context the agent serves.

Pre-Authenticated Token Provider configuration

• Provider name: A label for the provider, used only inside the platform for identification

• Audience (aud): The aud claim the platform expects in incoming tokens. Tokens whose aud does not match any configured provider are rejected.

• JWKS URI: The URL where the identity provider publishes its JSON Web Key Set. Used to verify the token signature.

• Refresh Token Endpoint: Optional. The endpoint the platform calls to refresh expired tokens during a session.

3

Save and Verify

Select Save to commit the configuration. With at least one mode enabled, you can now use the authentication nodes in your workflows to authenticate end users.

Using Identity in Workflows

Once a user is authenticated, their claims are exposed as workflow session variables under Auth.* and stay available for the rest of the session. Reference them in conditions, prompts, API calls, or any node that reads workflow variables, the same way you would reference any other user attribute.

Three workflow nodes work directly with this state and are what most workflows use to gate access:

Authenticate User

Triggers authentication for the current user: pre-auth token check first, sign-in button as fallback

Is Authenticated

Checks the current session and routes to Success or Error, refreshing expired tokens automatically

Logout

Clears the authentication session, with an optional sign-out from the identity provider

The End-User Experience

The user-facing journey depends on which authentication path the agent takes:

Pre-Authenticated Tokens

The conversation starts already authenticated. The user is never prompted to sign in or offered a sign-out option.

Interactive Sign-In

The agent shows a sign-in button the moment the workflow reaches an authentication step. After a successful sign-in, a green shield appears in the sendbox bottom bar. Selecting it lets the user sign out.

Key Terms

Term	Meaning
OIDC	OpenID Connect, an identity-layer protocol built on OAuth 2.0. The standard the platform uses for interactive sign-in.
OpenID integration	A Workspace-level configuration that captures an identity provider's discovery URL and client credentials.
Identity provider	The external system that authenticates users and issues tokens, for example Microsoft Entra ID, Google, Okta, or Keycloak
Claim	A single piece of identity information returned by the identity provider, such as name, email, or groups. Multiple claims together describe the user.
Token	A signed string the identity provider issues to represent an authenticated user. The platform verifies the signature before trusting any claims inside.
Pre-authenticated token	A token the embedding site already holds when the conversation starts, because the user is signed in upstream. The platform validates it without prompting for a fresh sign-in.
Audience (aud)	A claim inside the token that names who the token is meant for. The platform only accepts tokens whose aud matches a configured provider.
JWKS	JSON Web Key Set, the public keys the identity provider publishes so token signatures can be verified
Embedding site	The web page or host context where the agent is loaded through webchat. Examples: a SharePoint web part, an intranet portal, a public landing page.

Best Practices

• Prefer pre-authenticated tokens when the host already authenticates: Skipping the sign-in button removes a step from the user journey and keeps the experience inside the embedding page's session

• Use the Is Authenticated node for mid-flow re-checks: It is cheaper than re-prompting and handles token refresh transparently

• Request only the claims you use: Add to Additional Claims what the workflow actually reads, since extras clutter your variables and make audits harder

• Authenticate as late as possible: Place the Authenticate User node just before the first step that needs identity, so unauthenticated users can still reach steps that don't require it

• Add a provider per embedding context: When the same agent runs in two host sites with different audiences, configure two pre-auth providers rather than one broad rule

You can now authenticate end users mid-conversation, validate tokens from embedding sites, and use the resulting claims to personalize and adjust any step of the workflow.