SSO
Single Sign-On (SSO) is an authentication method that allows your users to log in to Engage using your company's existing accounts — like Google Workspace, Microsoft Entra (Azure AD), Okta, or any other identity provider you already use.
Why companies use it:
No extra passwords to manage for your users
Easier onboarding — new users get Engage access automatically if their email matches your domain
How to Connect Your SSO to Engage
Engage supports OIDC (OpenID Connect), the modern standard used by all major identity providers. The setup has two sides: first you register Engage in your identity provider, then you bring those values into Engage.
Step 1 — General Settings
Provider ID
A unique name to identify this connection internally (e.g. okta, google-workspace).
Issuer URL
Your identity provider's base URL. For example: https://accounts.google.com for Google, or https://yourcompany.okta.com for Okta.
Domain
Your company's email domain (e.g. yourcompany.com). Any user logging in with that domain will be redirected to your SSO provider.
Step 2 — OIDC Configuration
These values come from your identity provider when you register Engage as an application there.
Client ID
The public identifier assigned to Engage by your identity provider when you created the app.
Client Secret
The private secret paired with the Client ID. Keep this secure — never share it publicly.
Authorization Endpoint
The URL where users are sent to log in at your identity provider.
Token Endpoint
The URL Engage calls to exchange an auth code for tokens after login.
JWKS Endpoint
The URL that exposes public keys so Engage can verify the token signatures.
Discovery Endpoint
Optional but recommended — a single URL (usually .../.well-known/openid-configuration) that auto-populates all the endpoint fields above. If your provider supports it, start here.
Scopes
The user data Engage requests from your provider. Typical values: openid email profile.
PKCE
Enable this if your identity provider supports it (most modern ones do). It adds an extra layer of security to the login flow.
Step 3 — Claim Mapping
Once a user logs in, your identity provider sends back a token with user data called claims. This section tells Engage how to read that data.
ID Claim
sub
Email Claim
email
Email Verified Claim
email_verified
Name Claim
name
Image Claim
picture
These defaults work for most providers. If your provider uses different claim names, adjust them here.
Step 4 — Extra Fields
If you need to map additional data from your identity provider — like department, role, or employee ID — into Engage custom fields, use Add Field to create those mappings.
Step 5 — Save
Click Create Provider to activate the integration. Once configured, any user whose email matches your domain will be redirected to your company's SSO when logging into Engage.
Tip: Most identity providers offer a Discovery Endpoint URL that looks like
https://[your-provider]/.well-known/openid-configuration. Entering this in the Discovery Endpoint field will auto-fill most of the technical configuration for you.
Last updated