---
title: Sign in with your IdP
description: Put a federation connector to work — offer your identity provider
  as a sign-in button on an application, or force a verified domain's users
  through it.
editUrl: true
head: []
template: doc
sidebar:
  order: 7
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

import { CardGrid, LinkCard } from "@astrojs/starlight/components";

Once you have registered a [federation connector](/en-us/domains-federation/federation-connectors/), there are **two** ways to put it to work. They share the same connector, the same login machinery, and the same account model — they differ only in *who decides* that a user signs in through your IdP.

| Mode | Who turns it on | Who it affects |
|---|---|---|
| **Application-managed** | An application developer, per application | Anyone who chooses the "Sign in with …" button on that app |
| **Domain-managed (forced SSO)** | A domain owner, via login policy | Every account on a verified domain, on every application, with no opt-out |

Both are **Layer-1 authentication methods**, so they compose with the rest of the [three-layer rules model](/en-us/application-rules/overview/) exactly like any other method.

## Application-managed sign-in

This is the straightforward "let users of my app sign in with our corporate IdP" case. On an application your organization owns, add a Layer-1 authentication rule:

```json
{
  "method": "ENTERPRISE_FEDERATION_APPLICATION_MANAGED",
  "payload": { "connectorAnchor": "Bastion-K7Q2-M9XB-3FNP-Covenant" }
}
```

- The `connectorAnchor` must reference a connector **owned by the application's own organization** — this is enforced when the rule is saved.
- Sudomimus renders a **"Sign in with `<connector display name>`"** button in the authentication UI.
- One rule = one button. To offer several IdPs, add several rules (they OR together, like any Layer-1 rules).

When the user clicks the button, the browser is redirected to your IdP. An OIDC provider returns an authorization code to the fixed callback; a SAML provider posts a signed assertion to the fixed ACS. Sudomimus validates either proof, links or creates the account, checks Layer 2 admission and user consent, and issues tokens. Federation sign-in produces a normal Sudomimus session.

### How the federated identity links to an account

Sudomimus first looks for the identity bound to this connector subject:

1. **Seen this connector subject before** → reuse the existing account, even if the email at the IdP changed.
2. **No existing subject binding, and the asserted email is trusted** → look up the email owner and link to that account if one exists. Trust requires both an IdP-verified email and the connector organization's current verified ownership of that email domain.
3. **No matching subject or trusted email owner** → create a new account for the connector subject. An absent or untrusted email does not establish mailbox ownership; the subject identity still has to pass the application's Realize rules.

One account can hold identities from several connectors. Two IdPs asserting `jordan@acme.example` resolve to the same email owner only when each connector independently satisfies the domain-trust requirement. Matching email text alone is insufficient.


## Forced SSO (domain-managed)

Domain-managed SSO requires **every** user on a domain you own to sign in only through the designated IdP. Passkeys, email OTP, and consumer OAuth are unavailable to those users while the policy is enabled. The configuration has two parts:

1. A verified domain with its [login policy](/en-us/domains-federation/domain-login-policy/) set to **`SSO_ONLY`**, bound to one of your organization's connectors.
2. The Layer-1 method **`ENTERPRISE_FEDERATION_DOMAIN_MANAGED`** enabled on each application that accepts these logins:

   ```json
   {
     "method": "ENTERPRISE_FEDERATION_DOMAIN_MANAGED",
     "payload": {}
   }
   ```

The payload is **empty** — unlike application-managed, the connector is **not** named in the rule. It is resolved at login time from the user's email domain → the verified domain → the connector bound to that domain's `SSO_ONLY` policy. A domain owned by another organization can therefore determine the IdP used for login; the application accepts the IdP designated by the user's domain owner.

### What a gated user experiences

- **Email-first flows.** When an SSO-gated user enters their email, Sudomimus suppresses every other method and offers **only** the "Continue with `<connector>`" path.
- **No-email flows** (usernameless passkey, consumer OAuth, Steam). The user is only known *after* they authenticate, so Sudomimus catches them at realize time and redirects them into the SSO flow, then completes the login on the second pass.
- **A confirmation screen, not a silent jump.** The sign-in page shows a "Continue with `<connector>`" screen rather than auto-redirecting when there is one satisfiable connector. If verified domains require different connectors, the UI shows a terminal authority-conflict explanation instead. It never asks the user to choose which domain owner to bypass.
- **New employees.** A brand-new user whose email is on a forced-SSO domain is registered *through* the IdP on first sign-in (registration-via-SSO) — there is no separate enrolment step.

### Apps that have not opted in

An application that does **not** list `ENTERPRISE_FEDERATION_DOMAIN_MANAGED` simply **rejects** an SSO-gated user — there is no implicit SSO escape hatch injected into an app that did not ask for it. This keeps Layer-1 default-deny intact: forcing SSO never silently adds a method to an application.

:::note[Forced SSO overrides Layer 1 only]
`SSO_ONLY` changes *which authentication method* a gated user may use. It does **not** override Layer 2 or Layer 3 — an SSO-authenticated user can still be rejected by an application's email allowlist, and the result is still delivered by the application's return rules. Authentication ≠ authorization.
:::

### Offboarding

Because login requires a fresh IdP assertion, a departed employee whose IdP account is disabled cannot start a new session. Already-issued access tokens are not revoked immediately; they expire by TTL (3 hours by default). Existing refresh sessions continue only while their original login still satisfies the current domain policy: Session API `/refresh` and the OIDC refresh-token grant re-check `BLOCK_ALL` and `SSO_ONLY`, so switching the domain to `BLOCK_ALL` or repinning `SSO_ONLY` to a connector the session did not use cuts it off at the next refresh. Disabling only the user at the IdP does not make an existing Sudomimus refresh token contact the IdP retroactively.

If the same account later owns verified emails under domains pinned to distinct IdPs, **neither** IdP wins. Interactive login, code redemption, device/native issuance, and refresh all fail closed until the conflict is repaired. Multiple domains pinned to the same connector remain usable.

## Related

<CardGrid>
<LinkCard
    title="Federation connectors"
    description="Register the OIDC or SAML identity provider both modes use."
    href="/en-us/domains-federation/federation-connectors/"
/>
<LinkCard
    title="Configure OIDC"
    description="Create and test an OIDC federation connector end to end."
    href="/en-us/domains-federation/configure-oidc-connector/"
/>
<LinkCard
    title="Configure SAML"
    description="Create and test a SAML federation connector end to end."
    href="/en-us/domains-federation/configure-saml-connector/"
/>
<LinkCard
    title="Domain login policy"
    description="The SSO_ONLY policy that drives domain-managed forced SSO."
    href="/en-us/domains-federation/domain-login-policy/"
/>
<LinkCard
    title="Layer 1 — Authentication rules"
    description="How both federation methods sit in the three-layer rules model."
    href="/en-us/application-rules/authentication-rules/"
/>
</CardGrid>