# Single Sign-On
URL: https://docs.autociso.io/product/sso/overview/
Description: How AutoCISO decides who may sign in to your organization — allowed providers, your own identity provider, email domains, and how to recover if you lock yourself out.

Everything that decides who can sign in to your organization lives on one page:
**user menu → [Organization Settings](https://docs.autociso.io/console/settings/organization/) → Sign-In Policy**. This page explains what each section does and,
just as importantly, what it does *not* do.

Single Sign-On requires [The Growth plan or higher](https://docs.autociso.io/getting-started/plans-and-features/).

## The three sections

### 1. Allowed Providers

The list of sign-in methods your people are offered. It always contains at least
one entry. Out of the box that entry is **Email / Password**.

Once you have connected your own identity provider and it is **Active**, it
appears here as a fourth option alongside Email / Password, Google, GitHub and
Microsoft.

**Whatever you select here is exactly what your people are offered** when they
sign in through your organization's sign-in link. Select only your own provider
and nobody sees a password field.

Two things to know:

- Choosing among Email / Password, Google, GitHub and Microsoft is available on
  every plan. Adding **your own** identity provider requires The Growth plan or higher.
- Removing Email / Password asks you to confirm. Read that dialog — it is the
  one change on this page that can lock people out.

### 2. Single Sign-On

Where you connect your company's identity provider. AutoCISO supports:

| Provider | What you supply |
|---|---|
| [Google Workspace](https://docs.autociso.io/product/sso/google-workspace/) | Client ID, client secret |
| [Microsoft Entra ID](https://docs.autociso.io/product/sso/microsoft-entra-id/) | Client ID, client secret, directory (tenant) ID |
| [Okta](https://docs.autociso.io/product/sso/okta/) | Issuer URL, client ID, client secret |
| Generic OIDC (same steps as Okta) | Issuer URL, client ID, client secret |
| [Generic SAML 2.0](https://docs.autociso.io/product/sso/saml/) | Metadata XML |

A new connection starts as **Pending**. Use **Test connection** to move it to
**Active**. A pending connection deliberately does not appear in Allowed
Providers — you cannot select a provider nobody has proven can sign in yet.

After saving, the section shows the values to paste into your identity provider
(**Redirect URI**, or **ACS URL** and **Entity ID** for SAML). Copy them from
here rather than typing them.

**Automatic account creation** (also called just-in-time provisioning) is off by
default. Turn it on and anyone your identity provider authenticates gets an
AutoCISO account on first sign-in, at the role you choose. That role can be
Member, Contributor or Auditor — never Owner or Manager ([what each role can do](https://docs.autociso.io/getting-started/roles-and-permissions/)). With it off, people
still need an invitation from [User Management](https://docs.autociso.io/console/settings/members/).

Your client secret is sent to your identity provider's configuration and is
never stored by AutoCISO. When you edit a connection, leaving the secret blank
keeps the existing one. SAML metadata works differently: because AutoCISO keeps
no copy, an edit to a SAML connection requires pasting the metadata XML again.

### 3. Email domains

An optional restriction. Leave it empty and anyone your identity provider
authenticates can sign in.

Add domains and the restriction applies to **everyone signing in to your
organization**, not only to people arriving through your identity provider.
Someone whose address is outside the list cannot sign in at all.

Because of that, AutoCISO refuses a domain list that would exclude you or any
other active Owner. If you need to add a domain list that does not cover an
Owner's address, change that person's address first.

Email domains never *route* anyone to a provider — they only narrow who is
accepted. Your sign-in link is what routes people.

## Your organization's sign-in link

Also on this page: a copyable link of the form
`https://app.autociso.io/console/login/your-org`.

Share it with your team or put it on your intranet. It sends people straight to
your identity provider, skipping the provider chooser. If your organization has
no active connection, the link quietly shows the ordinary sign-in page.

## If you lock yourself out

Two ways back, in order of preference:

1. **Restore email & password sign-in.** When Email / Password is not in your
   Allowed Providers, a button of that name appears on the Sign-In Policy page.
   It is available on every plan, including an expired trial, and it can only
   *add* password sign-in back — it never changes anything else. Any Owner can
   use it, as long as they can still sign in.
2. **Contact support.** If nobody can sign in at all, AutoCISO support can
   restore your providers for you. This is the path for "our identity provider
   is down and password sign-in was switched off".

The first option is why we recommend keeping at least one Owner able to sign in
by password while you are setting up a new connection.

## If activating or saving a connection fails

When **Test connection** or **Save** on an active connection shows *"sign-in
could not be prepared in the identity provider; try again, and contact support
if it keeps failing"* (error code `SSO_CLAIMS_ACTION_FAILED`), AutoCISO could
not finish preparing your organization's sign-in in the identity service.
Nothing about your sign-in has changed:

- A new connection stays **Pending**, so nobody is sent to it yet.
- An active connection stays **Active**, and your edits are saved. Saving again
  retries the step that failed.

Try again after a minute. If it keeps failing, contact support and mention the
error code. The cause is logged on our side, and the message deliberately does
not show it.

## What this does not do

Deliberately out of scope today, so you can plan around it:

- **No SCIM.** Accounts are not created or deactivated from your directory in
  the background. Automatic account creation happens at sign-in; removing
  someone from your directory stops them signing in, but does not remove their
  AutoCISO membership. Remove them in **User Management**, and open a
  [leaver case](https://docs.autociso.io/product/lifecycle/offboarding/) if they left the company.
- **No group-to-role mapping.** Automatic account creation uses one role for
  everyone. Change individual roles in AutoCISO afterwards.
- **No email-domain routing.** Typing a work address on the generic sign-in page
  does not send anyone to your identity provider. Use your sign-in link.
- **One connection per organization.**
- **SP-initiated SAML only.** Starting from a tile in your identity provider is
  not supported; people must start at AutoCISO.

## Email verification with corporate SSO

Corporate Microsoft Entra ID, Okta, OIDC and SAML connections trust the email address supplied by the identity provider configured for your organization. Users do not need a separate email verification code after successful corporate SSO. Your identity-provider administrators control the accounts and email addresses allowed to sign in, including any guests. Google sign-in uses Google's email verification result. Multifactor authentication requirements still apply.