> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.supersend.io/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Single Sign-On (SSO) for Your Organization

# Single Sign-On (SSO) for Your Organization

## Purpose

This article is for **organization administrators** and **IT teams** who want users with your company email domain to sign in to SuperSend through your identity provider (IdP)—**Microsoft Entra ID** or **Okta**—instead of email codes, passwords, or generic Google/Microsoft login.

After setup, users on your domain can use **Continue With Organization SSO** on the login page. You can optionally **require** SSO so other sign-in methods are blocked for that domain.

## Prerequisites

- **Organization admin** access in SuperSend (`org_admin` role). Open **Admin** in the left sidebar (organization navigation, not team navigation).
- An **OIDC application** you control in Microsoft Entra or Okta (customer-owned app—not SuperSend’s shared login app).
- Your company’s **email domain** (for example `acme.com`). Users must already exist in SuperSend with that domain before they can sign in via SSO (SSO does not create new accounts except through team invites).
- Ability to add a **redirect URI** in your IdP admin console.

## Where to configure SSO in SuperSend

1. Go to **Admin**.
2. Open the **Security** tab (`/org/admin?tab=security`).
3. Under **Single sign-on**, choose your identity provider:
   - **Microsoft Entra ID**
   - **Okta**

The page shows setup steps, a **Redirect URI** field (with **Copy**), provider-specific credentials, and two toggles explained below.

## Redirect URI (register this in your IdP)

SuperSend shows the exact redirect URI to register. **Copy the value from the Security page**—do not guess.

| Provider | Redirect URI (production example) |
| --- | --- |
| **Microsoft Entra ID** | `https://api.supersend.io/v1/auth/sso/microsoft/callback` |
| **Okta** | `https://api.supersend.io/v1/auth/sso/okta/callback` |

Staging and other environments use the same path on that environment’s API host (for example `https://api-stage.supersend.io/v1/auth/sso/microsoft/callback`). Always copy the **Redirect URI** shown on your **Admin → Security** page for the environment you are configuring.

The URI must match **exactly** (including `https`, path, and no trailing slash unless your IdP requires it). Mismatches are the most common cause of “redirect URI” errors at login.

## Enable SSO vs Require SSO

| Setting | What it does |
| --- | --- |
| **Enable SSO** | Turns on organization SSO for your email domain. Users see **Continue With Organization SSO** on login. Email verification, password (if enabled), and generic Google/Microsoft login **still work**. |
| **Require SSO for users on this domain** | Locks sign-in to organization SSO only. Email codes, password login, and generic OAuth buttons are hidden and blocked for users on that domain. |

**Recommended rollout**

1. Save IdP credentials with **Enable SSO** off (or on but **Require** off).
2. Confirm **Continue With Organization SSO** works for a test user.
3. Turn on **Enable SSO** for the wider team.
4. Turn on **Require SSO** only when everyone is ready—there is no password fallback for that domain once enforced.

**Require SSO only applies when Enable SSO is on.** If SSO is disabled, login behaves normally.

---

## Option A — Microsoft Entra ID

### In Microsoft Entra admin center

1. Register an **enterprise application** (or app registration) for SuperSend in your tenant.
2. Under **Authentication**, add a **Web** redirect URI using the value from SuperSend’s **Redirect URI** field (see table above).
3. Grant **admin consent** for sign-in permissions your app needs (OpenID Connect sign-in; your app registration wizard may also reference Microsoft Graph permissions depending on how you configure the app).
4. Create a **client secret** and copy the secret **value** (shown once).
5. Note your **Directory (tenant) ID** and **Application (client) ID**.

### In SuperSend (Admin → Security)

1. Select **Microsoft Entra ID**.
2. Enter **Email domain** (for example `acme.com`—no `@`).
3. Enter **Azure Tenant ID**, **Application (Client) ID**, and **Client Secret**.
4. Click **Save SSO Settings**.
5. Test login with a user `@acme.com` who already belongs to your SuperSend organization.
6. When satisfied, check **Enable SSO**, save, then optionally **Require SSO for users on this domain**.

---

## Option B — Okta

### In Okta Admin Console

1. Create an **OIDC Web** application for SuperSend.
2. Under **Sign-in redirect URIs**, add the redirect URI from SuperSend’s **Redirect URI** field (see table above).
3. Assign users or groups who should be able to sign in.
4. Copy the **Client ID** and **Client secret**.
5. Note your **Okta domain** (for example `acme.okta.com`).

### In SuperSend (Admin → Security)

1. Select **Okta**.
2. Enter **Email domain**.
3. Enter **Okta Domain**, **Client ID**, and **Client Secret**.
4. **Issuer URL (optional)** — leave blank to use your Okta **org authorization server** (recommended for most Okta orgs). Only set this if you use a **custom** authorization server (for example `https://company.okta.com/oauth2/default`).
5. Click **Save SSO Settings**.
6. Test, then enable **Enable SSO** and optionally **Require SSO** as above.

---

## What users see at login

**SSO enabled, not required**

- User enters work email on the login page.
- **Continue With Organization SSO** appears (label may include your provider, for example Microsoft Entra ID).
- User can still use email verification or other methods if your org allows them.

**SSO required**

- Login page prompts: *Sign in with your organization account to continue.*
- Only the organization SSO button is shown for users on your domain.
- Submitting the form with a matching email redirects to your IdP.

**Team invites**

- Invited users on your domain can complete invite acceptance through organization SSO when SSO is configured for that domain.

## Expected result

- A user with email `@yourdomain.com` who is already a member of your SuperSend organization can sign in through your IdP.
- After successful authentication, they land in SuperSend as usual (team summary or onboarding, depending on account state).
- With **Require SSO** on, password and email-code login return an error for that domain.

## Troubleshooting

- **Issue:** IdP shows “redirect URI mismatch” or AADSTS50011.  
  **Fix:** Copy the **Redirect URI** from Admin → Security again and paste it exactly into Entra **Web redirect URIs** or Okta **Sign-in redirect URIs**. Confirm you registered the API host (`api.supersend.io`), not the app URL (`app.supersend.io`).

- **Issue:** User signs in at Microsoft/Okta but SuperSend shows “No account found.”  
  **Fix:** The user must already exist in your SuperSend organization (invite them under **Admin → Users**). Organization SSO signs in existing members; it does not provision brand-new self-serve accounts.

- **Issue:** “Email domain does not match” or tenant/issuer errors.  
  **Fix:** The email domain in SuperSend must match the user’s email domain. For Entra, the **Azure Tenant ID** must match the tenant the user signs into. For Okta, **Okta Domain** must match your tenant, and **Issuer URL** (if set) must match the authorization server that issued the sign-in token.

- **Issue:** **Require SSO** is on but a user still needs a fallback.  
  **Fix:** Turn off **Require SSO for users on this domain**, save, and have the user sign in with an alternate method. Re-enable require only after SSO is verified.

- **Issue:** Switching from Microsoft Entra to Okta (or the reverse) while SSO is enabled.  
  **Fix:** Disable **Enable SSO**, save, update provider credentials, test, then re-enable. SuperSend may block provider switches while SSO is enabled without confirming the change.

- **Issue:** Cannot open **Admin → Security**.  
  **Fix:** Only **organization administrators** can configure SSO. Ask an existing org admin to complete setup or grant you org admin access.

## Related articles

- [Admin Overview](https://help.supersend.io/en/article/admin-overview-ffatn4/)
- [Manage Users and Roles](https://help.supersend.io/en/article/manage-users-and-roles-zrnrx8/)
- [Sign Up and Log In](https://help.supersend.io/en/article/sign-up-and-log-in-68qsbj/)
- [Azure app and Microsoft service account (Outlook)](https://help.supersend.io/en/article/azure-app-registration-and-microsoft-service-account-outlook-g1uq5k/) — separate from login SSO; used for Outlook mailbox sending