Enterprise SSO

For organization admins — connect AdtoSign sign-in to your company's identity provider so employees authenticate with their existing corporate credentials, MFA, and Conditional Access policies. You can additionally require SSO for everyone at your domain.

MFA: admins who sign in via enterprise SSO are exempt from AdtoSign's platform TOTP requirement — your IdP's Conditional Access policies are the MFA authority. Social (Google/Microsoft/Zoho) and magic-link sign-ins still require platform MFA for admin/owner roles.

Before you start

Enterprise SSO requires an active directory connection for the domain you want to protect — the connection (Microsoft, Google, or Zoho) is how AdtoSign verifies your organization controls the sign-in domain. Set that up first under Directory → Connections, then open Settings → Security → Enterprise SSO.

One SSO provider per organization. Sign-ins are SP-initiated only: users start at the AdtoSign sign-in page, not from the IdP's app launcher (IdP-initiated login is disabled by design).

---

Option A — OIDC (recommended for Entra / Google / Zoho)

1. In the Enterprise SSO card, keep OIDC selected and pick your connected domain. The issuer URL and client ID prefill from your directory connection.
2. In your identity provider, create (or reuse) an app registration / OAuth client for AdtoSign:
   • Microsoft Entra: Entra admin center → App registrations → New registration → Accounts in this organizational directory only → add a Web redirect URI (shown after you save — format https://app.adtosign.com/api/auth/sso/callback/org-<orgId>) → grant delegated openid, email, profile → create a client secret.
   • Google Workspace: Google Cloud console → APIs & Services → Credentials → Create OAuth client ID → Web application → add the same redirect URI format → copy client ID + secret.
   • Zoho: Zoho API console → add a Server-based Application → register the redirect URI → copy client ID + secret.
3. Paste the client secret into the card and save. AdtoSign validates the issuer's discovery document before storing — if it can't be reached, the save fails with a clear error.
4. After saving, the card shows the redirect URI — confirm it is registered in your IdP, then test sign-in (below).

The issuer is restricted to the provider's canonical endpoint (your Entra tenant, accounts.google.com, or accounts.zoho.<dc>) — for any other IdP, use SAML below.

Option B — SAML 2.0 (Okta, Ping, ADFS, Keycloak, and others)

1. In your IdP, create a new SAML application for AdtoSign.
2. In the Enterprise SSO card, select SAML 2.0 and pick your connected domain.
3. Provide the IdP configuration — either:
   • Metadata XML (recommended): paste the IdP's federation metadata document, or
   • Manual: IdP Entity ID, IdP SSO URL (must be https://), and the IdP signing certificate (PEM, -----BEGIN CERTIFICATE-----).
4. Save — the card then shows the two values your IdP needs:
   • SP metadata URL — import it in the IdP if it supports metadata (https://app.adtosign.com/api/auth/sso/saml2/sp/metadata?providerId=…)
   • ACS URL — the Assertion Consumer Service endpoint (https://app.adtosign.com/api/auth/sso/saml2/sp/acs/<providerId>), sometimes called "Reply URL" or "Single sign-on URL" on the SP side.
5. Attribute mapping: the assertion must carry the user's email (as NameID or an email attribute). Signed assertions are required — most IdPs sign them by default.
6. Test sign-in (below) from a user account in that IdP.

Quick references

Signing in

On the AdtoSign sign-in page, choose "Use single sign-on (SSO) with a work account", enter your work email, and you'll be redirected to your IdP and back. If your email already has an AdtoSign account, SSO links to it — your existing workspaces, signatures, and roles are unchanged. New users get a standalone account (organization membership still comes via invite).

Requiring SSO for your domain

Once a provider is configured and verified working, enable "Require SSO for this domain" in the card. This blocks magic-link, password, and platform social sign-in for every account at your domain — everyone must arrive through your IdP.

Rehearse first. Enable enforcement only after at least one real user has completed a full SSO sign-in. If the IdP integration breaks while enforcement is on, removing the SSO provider clears enforcement — or contact AdtoSign support for assistance.

What auditors should note

• Domain ownership is proven by the directory connection — SSO can't be claimed for a domain you don't control.
• SAML assertions must be signed; IdP-initiated SSO and unsolicited responses are rejected (InResponseTo validation is enforced).
• The OIDC issuer is restricted to the connected provider's canonical endpoint — arbitrary IdP URLs can't be registered.
• Every provider create/update/delete and every enforcement change is recorded in the organization audit log.