Articles on: Admin And Team Management

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.



Updated on: 14/07/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!