> For the complete documentation index, see [llms.txt](https://onchainlabs-tech-documentation.gitbook.io/wallettwo-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://onchainlabs-tech-documentation.gitbook.io/wallettwo-documentation/engage/sso.md).

# 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

| Field           | What to put                                                                                                                           |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **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.

| Field                      | What to put                                                                                                                                                                           |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **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.

| Field                    | Typical value    |
| ------------------------ | ---------------- |
| **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.