> For the complete documentation index, see [llms.txt](https://docs.datacake.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datacake.de/organization/white-label/enterprise-single-sign-on.md).

# Enterprise Single Sign-On

## What is Enterprise Single Sign-On

Enterprise Single Sign-On (SSO) lets the users of your white label site sign in with your organization's identity provider instead of a Datacake email and password. Once SSO is enabled, a **Sign in with Single Sign-On** button appears on the login page of your white label site. If you want to, you can go one step further and switch the password login off entirely, so that Single Sign-On becomes the only way in.

Datacake supports any identity provider that speaks SAML or OIDC, including Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, JumpCloud and Ping Identity.

{% hint style="info" %}
One identity provider is connected per white label site. The connection belongs to the organization that owns the site, so all users signing in through that site use the same identity provider.
{% endhint %}

## Requirements

* **Enterprise Single Sign-On** included in your plan or booked as an add-on package. If it is not included, the Single Sign-On settings are visible but disabled — contact your account manager to add it to your subscription.
* The **White Label** permission on the workspace that manages your white label site.
* An identity provider that supports SAML or OIDC, and administrative access to it.
* Access to the DNS configuration of every email domain your users sign in with.

## Step 1: Enable Single Sign-On

Open **White Label** from the left sidebar navigation, select your site and switch to the **Single Sign-On** tab.

Enable **Single Sign-On**. This makes the Single Sign-On button appear on the login page of your white label site and unlocks the rest of the configuration below.

## Step 2: Add and verify your email domains

Before your identity provider can be connected, you have to prove that you own the email domains your users sign in with. In the **Verified domains** section, enter a domain (for example `techcorp.com`) and click **Add**.

{% hint style="warning" %}
These are the **email domains of your users**, not the web address your white label site is served on. The two are usually different, and you can add more than one if your organization uses several email domains.
{% endhint %}

Free email providers such as `gmail.com`, `outlook.com` or `gmx.de` cannot be used. A Single Sign-On domain routes every account at that domain to one organization, so consumer domains are rejected. If another organization has already claimed the domain you entered, adding it fails as well — please reach out to support in that case.

### Publish the DNS record

After adding a domain it shows the status **Pending verification**. Click **Show record** to reveal the DNS record you have to publish at your DNS provider:

| Field     | Value                                                                                                              |
| --------- | ------------------------------------------------------------------------------------------------------------------ |
| **Type**  | `TXT`                                                                                                              |
| **Name**  | `@` — the root of the domain. Some DNS providers write this as `@`, others expect the host field to be left empty. |
| **Value** | `verification_token=…` — copy the value exactly as shown, including the `verification_token=` prefix.              |

Verification runs automatically. Once the record is live, the domain flips from **Pending verification** to **Verified** within a few minutes, without you having to do anything. The list refreshes itself while a domain is pending; you can also use **Refresh** to check immediately.

{% hint style="warning" %}
Leave the TXT record in place. Verification is re-checked over time, so if the record is deleted — for instance while cleaning up or rebuilding a DNS zone — the domain drops back to **Pending verification** and stops counting as verified.
{% endhint %}

## Step 3: Connect your identity provider

With at least one verified domain in place, click **Configure Single Sign-On** under **Configure your identity provider**. A configuration portal opens in a new tab, where you pick your identity provider and follow its specific setup instructions — typically exchanging metadata URLs or certificates between the portal and your identity provider's admin console.

{% hint style="info" %}
The configuration portal is hosted by WorkOS, our identity infrastructure provider. You will be redirected to a `workos.com` address — this is expected. The link is valid for a few minutes; if it expires, just click the button again.
{% endhint %}

The portal opens in a new tab so your white label settings stay open in the background. Once the connection is live in the portal, users can sign in.

## Step 4 (optional): Require Single Sign-On

By default, users can still sign in with an email address and password alongside Single Sign-On. To make Single Sign-On the only option, disable **Allow password login**.

On a site with password login disabled:

* the password fields, the "forgot password" link and the public sign-up are hidden from the login page,
* the standalone password reset and public sign-up pages redirect away,
* invitation-based sign-up still works, so you can keep inviting users.

{% hint style="success" %}
**Allow password login** only takes effect while Single Sign-On is enabled. If you switch Single Sign-On off again, password login comes back automatically, so a site can never be left with no way to sign in. The setting also applies to your white label domain only — `app.datacake.de` is never affected.
{% endhint %}

## What your users see

Users open the login page on your white label domain and click **Sign in with Single Sign-On**. They are sent to your identity provider, authenticate there, and land back on your domain, signed in. If you disabled password login, the Single Sign-On button is the only thing on the login page.

Signing in for the first time creates the user's Datacake account automatically — there is no separate registration step.

## Accounts and organizations

Because accounts are created on first sign-in, it is worth checking how new users are placed before you roll Single Sign-On out to a larger group.

{% hint style="warning" %}
If **Auto-assign signups to this organization** is switched off in the **Sign-up & Login** settings, every user who signs in via Single Sign-On for the first time gets their **own new organization**, with its own billing. To have your users share your organization and your billing, enable that setting before inviting people to sign in. See [Sign-up & Login](/organization/white-label.md#sign-up-and-login).
{% endhint %}

A few more interactions to keep in mind:

* **Allow sign-up** does not gate Single Sign-On. Even with sign-up switched off, a user who authenticates successfully through your identity provider gets an account. The setting only governs the email and password sign-up form.
* **Restrict Login** still applies. A user whose account belongs to a different white label site and is restricted to it cannot sign in through your site.
* If a user already has an account **on this site** with the email address your identity provider reports, that existing account is used — nothing is duplicated.

### Email addresses already in use elsewhere

If the email address reported by your identity provider already belongs to a Datacake account **outside** your site — on `app.datacake.de`, on another white label site, or a private account — the sign-in is refused instead of taking over that account. Datacake never claims an existing account based on an identity provider's assertion alone.

{% hint style="danger" %}
There is currently no self-service way to merge such an account. The error message on screen suggests signing in with a password to link Single Sign-On, but that flow does not exist yet — please contact support, who can resolve the conflict for you.
{% endhint %}

## Troubleshooting

| Message on the login page                                              | What happened                                                                                                    | What to do                                                                                                                |
| ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| We could not complete sign-in with your identity provider.             | The exchange with the identity provider failed, for example because the connection is incomplete or was changed. | Try again. If it persists, reopen **Configure Single Sign-On** and check that the connection is complete and active.      |
| Your identity provider authenticated you for a different organization. | The user was authenticated against a different organization than the one this white label site belongs to.       | Check that the user signs in on the correct white label domain, and that only one connection is configured for your site. |
| Your account is restricted to a different site.                        | The user's account belongs to another white label site that has **Restrict Login** enabled.                      | The user has to sign in on their own site, or their account needs to be moved.                                            |
| An account already exists for this email.                              | The email address is already used by a Datacake account outside your site.                                       | Contact support — see [Email addresses already in use elsewhere](#email-addresses-already-in-use-elsewhere).              |

**A domain stays on "Pending verification".** Confirm that the TXT record is published on the **root** of the domain and that the value includes the `verification_token=` prefix exactly as shown. DNS changes can take a while to propagate; use **Refresh** to check again. If your DNS provider appends the domain name to the host automatically, leave the host field empty rather than entering `@`.

## Limits

* One identity provider per white label site.
* An email domain can be claimed by one organization only. If your domain is already taken, contact support.
* Users are not assigned to workspaces based on groups or roles from your identity provider. Workspace membership and permissions are managed in Datacake.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.datacake.de/organization/white-label/enterprise-single-sign-on.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.