---
title: Federation connectors
description: Register your organization's own OIDC identity provider as a
  reusable connector, then use it to offer enterprise sign-in or force a domain
  through SSO.
editUrl: true
head: []
template: doc
sidebar:
  order: 4
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

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

A **federation connector** is your organization's own external OIDC identity provider, registered with Sudomimus once and reused everywhere. If your company runs Microsoft Entra ID, Okta, Google Workspace, Ping, Auth0, or any standards-compliant OIDC provider, you register it as a connector and then either:

- offer it as a **"Sign in with …" button** on one of your applications ([application-managed](/en-us/domains-federation/sign-in-with-your-idp/#application-managed-sign-in)), or
- **force** a verified domain's users through it ([domain-managed / forced SSO](/en-us/domains-federation/sign-in-with-your-idp/#forced-sso-domain-managed)).

The connector is the shared mount point for both. Sudomimus acts as a **relying party** (OIDC client) against your IdP — it consumes your provider; your provider stays the source of truth for those identities.

## What a connector stores

You register a connector from the With portal on one of your organizations. It holds:

| Field | What it is |
|---|---|
| **Display name** | Shown on the login button and in management UIs (e.g. "Acme Corp SSO"). |
| **Issuer** | Your IdP's issuer URL (`https://login.acme.example`). Sudomimus fetches its OIDC discovery document from `<issuer>/.well-known/openid-configuration`. |
| **Client ID** | The OAuth client ID Sudomimus presents to your IdP. |
| **Client secret** | The confidential client secret. **Encrypted at rest** and **write-only** — see below. |
| **Scopes** | The scopes Sudomimus requests; must include `openid`. |

Each connector is addressed by an opaque **connector anchor** (a value like `Bastion-K7Q2-M9XB-3FNP-Covenant`) — the developer-facing identifier you reference from rules and policies. The internal identifier never leaves the system.

:::note[Confidential client + PKCE]
Sudomimus authenticates to your IdP as a **confidential client** using the client secret, and uses **PKCE (S256)** on every authorization. `private_key_jwt` and public (secret-less) clients are not supported yet — the providers Sudomimus targets first (Entra, Okta, Workspace) all support confidential + PKCE.
:::

### The client secret is never revealed back to you

The client secret is encrypted the moment you save it. On every read — the connector list, the detail page, the API — it is simply **absent**: the portal can never display it back to you. To rotate it, supply a new secret; to keep the existing one when editing other fields, leave the secret blank.

## Validation at save time

When you create or update a connector, Sudomimus **fetches your IdP's discovery document then and there**. If the issuer is unreachable or does not publish a valid OIDC discovery document, the save is rejected (`FederationConnectorDiscoveryFailed`) rather than storing a dead connector — the failure is loud and immediate, not a surprise at first login.

## The redirect URI to register at your IdP

Sudomimus uses a single, platform-fixed redirect (callback) URI for **all** connectors — your IdP distinguishes flows by the per-login `state` value, not by the redirect URI. The connector page shows this URI read-only; register it as an allowed redirect URI in your IdP's application configuration:

```text
https://via.sudomimus.com/oauth/enterprise-federation/callback
```

## Managing connectors

- **Disable** a connector to retire it without deleting it — useful when you are migrating IdPs.
- **Delete** removes it entirely.

:::caution[Connectors in use cannot be removed]
A connector that is still referenced cannot be disabled or deleted:

- referenced by a Layer-1 application sign-in rule → `FederationConnectorInUse`;
- pinned by a domain's `SSO_ONLY` login policy → `FederationConnectorInUseByLoginPolicy`.

Remove the rule, or revert the domain's policy to `ALLOW_ALL`, first. This guard exists so a live forced-SSO domain can never be stranded behind a deleted IdP.
:::

## Quota

Each organization can hold a limited number of connectors (default **3**). Sudomimus staff can raise the limit on request. The quota is enforced on the self-service surface only.

## Browsing connectors

The With portal has a top-level **Connectors** view that lists every connector across all your organizations, with an organization switcher.

## Related

<CardGrid>
<LinkCard
    title="Sign in with your IdP"
    description="Put a connector to work — as an application button or a forced-SSO domain policy."
    href="/en-us/domains-federation/sign-in-with-your-idp/"
/>
<LinkCard
    title="Domain login policy"
    description="Bind a connector to a verified domain to force its users through SSO."
    href="/en-us/domains-federation/domain-login-policy/"
/>
</CardGrid>