SSO / IdP setup overview

DIAL authenticates end users through an external identity provider (IdP) that issues signed JWT access tokens. This page compares the supported providers and explains the shared setup workflow, so you can choose one without opening six guides. It is written for DevOps engineers who already understand JWT-based authentication in DIAL.

How DIAL works with an IdP

DIAL does not store user passwords. Instead, DIAL Chat redirects users to your IdP to log in, the IdP returns a JWT, and DIAL Core validates that token and reads its claims on every request. Two components are involved:

• DIAL Chat initiates the OIDC login flow. It reads the provider's client ID, secret, and host from environment variables.
• DIAL Core validates the token signature against the provider's JWKS endpoint and maps a role claim to DIAL roles. It reads this from the identityProviders section of settings.json.

Every provider follows the same three-stage workflow, detailed in each guide:

1. Configure the IdP — register an application, capture its client ID, secret, and endpoints, and (optionally) create groups or roles.
2. Configure DIAL — set DIAL Chat environment variables and the DIAL Core identityProviders.<name> block in settings.json.
3. Assign roles — map the IdP's group or role claim values to DIAL resources through userRoles in config.json.

Comparison of supported providers

Provider	Protocol	Hosting	Role-claim source	DIAL Core rolePath	DIAL Admin sign-in
AWS Cognito	OIDC	Managed (AWS)	Cognito groups	cognito:groups	Yes
Auth0	OIDC	Managed (SaaS)	Custom claim from a post-login action	dial_roles	Yes
Google Identity	OIDC / OAuth 2.0	Managed (Google)	Google Workspace groups (Cloud Identity API)	fn:getGoogleWorkspaceGroups	Yes
Microsoft Entra ID	OIDC	Managed (Microsoft)	Entra ID security groups	groups	Yes
Okta	OIDC	Managed (SaaS)	Okta groups	Groups	Yes
Keycloak	OIDC	Self-hosted (open source; bundled in the DIAL Helm chart)	Client roles via groups	resource_access.<client>.roles	Yes
Azure AD B2C	OIDC	Managed (Microsoft CIAM)	Custom claim from a User Flow	roles	No

Choosing a provider

• You already run one of these. Use it. DIAL imposes no preference; the validation model is identical across providers.
• You want a self-hosted, no-extra-cost option. Keycloak ships inside the DIAL Helm chart and is the default for local and on-premises deployments.
• You serve external or consumer users. Azure AD B2C targets customer identity (CIAM) and supports custom sign-up flows.
• You are standardized on a cloud. AWS Cognito, Google Identity, and Microsoft Entra ID integrate naturally with their respective clouds' group management.

Group and role membership is configured entirely in the IdP. DIAL reads whatever claim you point rolePath at; it does not manage the directory.

Sign in to DIAL Admin

DIAL Admin signs administrators in through the same IdP, with its own AUTH_* variables; DIAL Chat's settings don't apply to it. The provider guides cover DIAL Chat and DIAL Core only. To add DIAL Admin to a provider you have set up:

1. In the IdP, register a client for DIAL Admin, or add Admin's redirect URI to an existing client: <admin_url>/api/auth/callback/<provider_id>, for example <admin_url>/api/auth/callback/cognito. The provider IDs are listed in Other identity providers.
2. Set the provider's variables on Admin Frontend, from the same table. For Google, also set AUTH_IDTOKEN_PROVIDERS=google: Google access tokens are not JWTs, so Admin forwards the ID token instead.
3. Check that DIAL Core validates the client's tokens and that administrators match access.admin.rules. See Authentication and administrator access.

DIAL Admin has no Azure AD B2C provider.