> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/federation.md). # Configure federation and application SSO Choose between SAML, OpenID Connect and the Access Gateway by naming the protocol and each side's role, then go to the page that configures it. ## What this is, and when you need it Federation lets two systems exchange authentication under a defined trust. This section is for the administrator building one side of that trust in OpenIAM — the provider row, its attributes, the endpoints OpenIAM exposes, the entitlement that authorizes the population, and how to verify the result. Before you open a form, name two things: **the protocol**, and **which side OpenIAM is on**. "Provider", "target" and "SSO" are all ambiguous enough to send you to the wrong provider type, and the two SAML types look nearly identical on screen while pointing in opposite directions. ## Choose your outcome | I want to… | Go to | | ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Let users sign in to a SaaS or internal application using their OpenIAM credentials | [OpenIAM as a SAML identity provider](/administration-guide/federation/saml-identity-provider.md) | | Route sign-in for a whole verified Microsoft 365 domain to OpenIAM | [Federate a Microsoft Entra domain](/administration-guide/federation/federate-a-microsoft-entra-domain.md) | | Let an external corporate IdP authenticate users *into* OpenIAM | [OpenIAM as a SAML service provider](/administration-guide/federation/saml-service-provider.md) | | Issue access tokens and ID tokens to an application, or expose a discovery document | [OAuth 2.0 and OpenID Connect](/administration-guide/federation/oauth-and-oidc.md) | | Create an OpenIAM identity on an external user's first federated sign-in | [Just-in-time provisioning](/administration-guide/federation/jit-provisioning.md) | | Sign users in through Google, Facebook, LinkedIn or Apple | [Social sign-in](/administration-guide/security/social-authentication.md) | | Put a legacy application that speaks no federation protocol behind SSO | [Administer the Access Gateway](/administration-guide/gateway.md) | | Find out why a field the documentation names is not on the provider form | [Authentication providers and MFA](/administration-guide/security/authentication-providers-and-mfa.md#capability-flags-decide-which-fields-you-see) | | Look up a SAML identity provider attribute and its shipped default | [Every SAML identity provider attribute, with its shipped default](/administration-guide/federation/saml-identity-provider/saml-identity-provider-reference.md) | | Look up an OAuth endpoint, grant type, scope or signing algorithm | [OAuth endpoints, grants, scopes and signing](/administration-guide/federation/oauth-and-oidc/oauth-and-oidc-reference.md) | | Look up the JIT script contract and its claim mapping | [The JIT script contract and claim mapping](/administration-guide/federation/jit-provisioning/jit-provisioning-reference.md) | | Look up an authentication level, a shipped rule or a capability flag | [Authentication levels, rules and capability flags](/administration-guide/security/authentication-providers-and-mfa/authentication-provider-reference.md) | ### Which provider type each answer is Every one of these is an `AUTH_PROVIDER` row, and the capability flags on the row decide which fields the form renders. | OpenIAM's role | Provider type | Page | | ------------------------------------------------ | ----------------------------------- | ---------------------------------------------------------------------------------------------------------- | | SAML **identity provider** | `SAML_PROVIDER` | [OpenIAM as a SAML identity provider](/administration-guide/federation/saml-identity-provider.md) | | SAML **identity provider**, tenant-wide | `SAML_PROVIDER` | [Federate a Microsoft Entra domain](/administration-guide/federation/federate-a-microsoft-entra-domain.md) | | SAML **service provider** | `SAML_SP_PROVIDER` | [OpenIAM as a SAML service provider](/administration-guide/federation/saml-service-provider.md) | | OAuth 2.0 authorization server and OIDC provider | `OAUTH_CLIENT` | [OAuth 2.0 and OpenID Connect](/administration-guide/federation/oauth-and-oidc.md) | | OAuth/OIDC **consumer** | `GOOGLE_AUTH_PROVIDER` and siblings | [Social sign-in](/administration-guide/security/social-authentication.md) | | Reverse proxy and policy enforcement point | — | [Administer the Access Gateway](/administration-guide/gateway.md) | ## SAML, OIDC or the Access Gateway The decision is usually made for you by what the application supports. If it speaks SAML 2.0 or OIDC, use whichever the vendor documents as supported — `SAML_PROVIDER` for SAML, `OAUTH_CLIENT` for OIDC — and do not implement the other because it looks simpler. A single-page or mobile application calling APIs wants OIDC with `AUTHORIZATION_CODE_PKCE`; SAML has no useful answer for a public client. Delegated API authorization rather than sign-in is OAuth 2.0 without the `openid` scope, which is an access-token question, not an authentication question. An application that speaks neither goes behind the Access Gateway, which authenticates at the proxy and passes the identity in a header or a Kerberos ticket — the only one of the four that does not require the application to change. See [Administer the Access Gateway](/administration-guide/gateway.md). Two differences worth knowing before you commit. **SAML is a browser protocol with a signed XML document; OIDC is a token protocol with a signed JWT** — SAML's trust is a certificate you exchange and rotate with an overlap, OIDC's is a JWKS endpoint the relying party polls, so certificate expiry is a scheduled outage in SAML and usually not in OIDC. **Single logout is real in SAML and largely absent in OIDC**: OpenIAM ships SAML IdP logout, global logout and SP logout endpoints, whereas on the OIDC side revocation is per token. If "one click signs the user out of everything" is a requirement, it is a SAML conversation. ## Two things federation does not do **Federation does not create or disable accounts.** A working SAML trust logs a user in; it does not provision them into the application, and it does not disable them when they leave. Account lifecycle for the same application is a connector and a managed system — [Connect applications and automate lifecycle](/administration-guide/lifecycle.md) — configured separately. The exception is inbound [Just-in-time provisioning](/administration-guide/federation/jit-provisioning.md), which creates the *OpenIAM* identity, not the application's. **A working trust does not authorize anyone.** Every provider is backed by a resource, and access to the application is an entitlement on that resource. Two shipped defaults make this easy to get wrong in opposite directions: OAuth entitlement is **not** enforced out of the box (see [OAuth 2.0 and OpenID Connect](/administration-guide/federation/oauth-and-oidc.md#fence-the-client-oauth-entitlement-enforcement-is-off-out-of-the-box)), whereas OpenIAM as a SAML service provider does check the entitlement and refuses an unentitled user. Prove protocol validation and business authorization separately, on every trust, in both directions — the two defaults fail in opposite ways, so proving one tells you nothing about the other. ## Guide boundary This section does not own the partner's console. Where a step happens in Entra, Okta, a SaaS admin panel or the Google Cloud console, this guide names the values to enter and points at the vendor's current documentation, because those consoles change independently of OpenIAM. The one place it goes further is Microsoft 365 domain federation, which is a routing change rather than an application registration. Installing the product and the reverse proxy in front of it are the [Installation Guide](/installation/installation.md); writing extension code against OpenIAM's Java APIs is the **Developer Guide**. Read [Change configuration safely](/administration-guide/start/change-safely.md) once before your first change, and keep a tested break-glass administrator whose route does not touch the trust you are building. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/federation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.