> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ampup.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Single Sign-On (SSO)

> Connect your identity provider to AmpUp using SAML or OIDC

AmpUp supports Single Sign-On so your team can authenticate with the identity
provider you already use — Azure AD / Entra ID, Okta, Google Workspace,
OneLogin, Ping, ADFS, and any other SAML 2.0 or OIDC-compliant IdP.

<Note>
  SSO is included on **Business** and **Enterprise** plans. Free and trial
  tenants use email + password or Google login.
</Note>

## How it works

AmpUp uses [Auth0](https://auth0.com) as its identity broker. Your IdP
connects to AmpUp's Auth0 tenant via an **Enterprise Connection**, scoped to
your organization. Logins from your IdP land only in your AmpUp org — no
cross-tenant access is possible.

* **Protocols**: SAML 2.0 and OIDC (pick whichever your IdP team prefers).
* **Provisioning**: Just-in-Time. Users are created on first successful
  login.
* **MFA**: enforced at your IdP. AmpUp honors the assertion — you don't get
  double-prompted.
* **Access control**: restrict the AmpUp app to a specific assignment group
  in your IdP. Only members of that group can authenticate.

## Get SSO enabled for your org

<Steps>
  <Step title="Reach out to your AmpUp account team">
    Email your CS contact (or [support@ampup.ai](mailto:support@ampup.ai))
    with:

    * Your IdP type (Azure AD, Okta, Google Workspace, etc.)
    * Protocol preference (SAML or OIDC)
    * Email domain(s) to route through SSO (e.g. `@yourcompany.com`)
    * Application owner on your side (RevOps / IT sponsor)
    * Preferred display name for the app inside your IdP catalog (this is
      what end users see in the O365 / Okta launcher — usually "AmpUp")
  </Step>

  <Step title="Receive AmpUp's connection metadata">
    AmpUp will send you the values you need to configure the app in your
    IdP:

    * SAML metadata URL (or OIDC discovery URL)
    * ACS / Reply URL
    * Entity ID / Client ID
    * Required user attributes / claims

    The required claim list is short:

    | Claim         | Required | Notes                              |
    | ------------- | -------- | ---------------------------------- |
    | `email`       | Yes      | Used as the unique user identifier |
    | `given_name`  | Yes      | First name                         |
    | `family_name` | Yes      | Last name                          |
  </Step>

  <Step title="Configure the app in your IdP">
    Create the app in Azure AD / Okta / Google Workspace using the metadata
    AmpUp provided. Assign it to the AD group of users who should have
    access — start with a small pilot group.

    Send AmpUp your IdP metadata URL when ready.
  </Step>

  <Step title="Pilot test">
    AmpUp enables the Enterprise Connection. A pilot user from your
    assignment group signs in via SSO and confirms they reach your AmpUp
    org.
  </Step>

  <Step title="Cut over">
    Once the pilot succeeds, AmpUp switches your org to SSO-only. Password
    and other login paths are no longer accepted for users in your domain.
  </Step>
</Steps>

## Customer-side setup checklist

<Check>Designate an application owner (RevOps / IT sponsor)</Check>
<Check>Confirm IdP type and protocol (SAML / OIDC)</Check>
<Check>Confirm the email domain(s) to route through SSO</Check>
<Check>Create an assignment group in your IdP and populate with pilot users</Check>
<Check>Configure the app in your IdP using AmpUp-provided metadata</Check>
<Check>Send your IdP metadata URL back to AmpUp</Check>
<Check>Verify pilot login works end-to-end</Check>
<Check>Cut over the org to SSO-only</Check>

## Roles and access control

Roles in AmpUp (`admin`, `member`, `viewer`) are assigned **inside AmpUp** by
an existing admin. New users created via JIT login start at the org's default
role and are promoted in-app.

To restrict who can log in at all, control membership of the AmpUp
assignment group in your IdP — that's the recommended pattern and it's
enforced before AmpUp ever sees the request.

## Deprovisioning

To remove a user's access:

1. **Remove them from the IdP assignment group** — this blocks future logins
   immediately.
2. **Disable the user inside AmpUp** if you want to revoke any active
   in-product session.

For organization-wide offboarding (e.g. employee termination), most
customers handle this entirely on the IdP side via their existing
deprovisioning flow.

## FAQ

<AccordionGroup>
  <Accordion title="Which IdPs are supported?">
    Any SAML 2.0 or OIDC-compliant IdP. We have customers running on Azure
    AD / Entra ID, Okta, Google Workspace, OneLogin, Ping, and ADFS.
  </Accordion>

  <Accordion title="Can we test SSO before flipping the whole org over?">
    Yes. The connection is verified with a pilot user before AmpUp switches
    your org to SSO-only.
  </Accordion>

  <Accordion title="Can different teams in our company use different IdPs?">
    Reach out to your account team — we'll evaluate based on your specific
    setup.
  </Accordion>

  <Accordion title="What happens during an IdP outage?">
    If your IdP is unreachable, contact AmpUp support. We can re-enable a
    temporary non-SSO login path for your org while your IdP is recovering.
  </Accordion>

  <Accordion title="How long does setup take?">
    Typically 30–60 minutes of joint working time. End-to-end calendar
    time depends on your IT team's response cadence — most customers
    complete within 1–3 business days.
  </Accordion>

  <Accordion title="Do you support SCIM provisioning?">
    Not at this time. Provisioning is JIT on first login; deprovisioning is
    handled by removing users from your IdP assignment group. SCIM is on
    our roadmap — contact your account team if it's a requirement.
  </Accordion>
</AccordionGroup>

## Need help?

For SSO setup or any security questions, contact your AmpUp account team
or email [support@ampup.ai](mailto:support@ampup.ai).