Federated SSO vs a Single IdP: When You Need an Identity Hub

Most applications start with a single identity provider: you pick Google, Microsoft, or your own username/password database and every user authenticates through that one source. This works until you acquire customers who already have their own identity infrastructure, or you need to support workforce users from Active Directory alongside customer logins from social providers, or you merge with another company that uses a different IdP. At that point, a federated SSO hub starts making sense.

This guide explains when you need federated SSO, how an identity hub architecture works, and how to configure Skycloak or upstream Keycloak to add OIDC and SAML identity providers with domain-based routing.

What is federated SSO?

Federated SSO means delegating authentication to multiple external identity providers while presenting a single consistent identity layer to your applications. Instead of each app integrating with Entra ID, Okta, Google, and GitHub separately, they all trust one hub (your Keycloak realm or Skycloak tenant), and the hub federates out to the upstream IdPs.

Your applications see one OIDC or SAML endpoint. Your users authenticate with whichever identity provider owns their organization. You never touch application configs when a customer switches from Okta to Entra ID.

Single IdP vs federated hub

If you have more than one class of user (workforce vs customer, or multiple enterprise customers), or you expect to change identity sources without redeploying apps, federated SSO is the right architecture.

Signs you need an identity hub

You need federated SSO when:

1. B2B customers bring their own IdP. Enterprise customers require SSO with their corporate directory. Without a hub, you wire each customer directly into your app and maintain that integration forever.
2. Multiple identity sources for different user populations. Your employees use Active Directory, contractors use GitHub, and customers use social login. A hub routes each group to the right IdP.
3. Acquisitions or consolidations. Two companies merge, each with their own identity infrastructure. A hub lets both authenticate to shared applications without migration.
4. IdP portability. You want to move from Okta to Entra ID, or your customer switches IdPs. The hub insulates your applications from that change.
5. Normalized claims across IdPs. One IdP sends emailAddress, another sends email, and a third sends mail. The hub maps them all to a consistent email attribute in the token your app receives.

Architecture: apps, hub, identity providers

In a federated SSO architecture, authentication flows through three layers:

User -> Application -> Identity Hub (Keycloak/Skycloak) -> Identity Provider (Entra ID, Okta, Google, etc.)

The flow

1. User visits your application. The app has no valid session, so it redirects to your identity hub (Keycloak or Skycloak).
2. Hub identifies the user’s identity provider. Either the user selects an IdP from a list, or the hub reads their email domain and routes automatically (domain routing, covered below).
3. Hub redirects to the external IdP. The IdP authenticates the user (username/password, MFA, biometrics, whatever that IdP requires).
4. IdP sends an assertion or token back to the hub. This is a SAML assertion or OIDC ID token containing the user’s identity and attributes.
5. Hub verifies the assertion and creates a session. The hub validates signatures, maps attributes, and creates a local user record if this is the first login.
6. Hub issues a token to your application. The app receives an OIDC token (or SAML assertion) from the hub. As far as the app knows, the hub is the IdP.

Why it works

Applications integrate once with the hub. The hub handles the complexity of multiple IdPs, protocol translation (SAML upstream, OIDC downstream, or vice versa), and attribute mapping. When you add a new customer with a new IdP, you configure the hub, not the applications.

For more on Keycloak as an identity broker, see Understanding Identity Brokering in Keycloak and the existing SSO implementation guide.

Skycloak setup: add an OIDC identity provider

Skycloak provides a guided recipe wizard for the most common identity provider integrations. For Microsoft Entra ID (Azure AD), the fastest path is the built-in recipe.

Recommended: Use the Azure AD SSO recipe

For Microsoft Entra ID OIDC integration:

1. Log into your Skycloak account.
2. Navigate to Recipes in the left sidebar.
3. Select Azure AD SSO Integration from the recipe list.
4. Click Start Recipe.
5. Follow the guided wizard, which walks you through:
   • Creating the app registration in Azure Portal
   • Configuring redirect URIs
   • Adding the Client ID and Client Secret to Skycloak
   • Setting up attribute mappers for email, first name, and last name
   • Testing the integration

The recipe handles OIDC discovery, attribute mapping, and trust settings automatically.

For other OIDC providers (Google, Okta, GitHub) or self-hosted Keycloak 26.x, use the direct admin console method below or consult the Keycloak identity providers documentation.

Alternative: Direct admin console configuration

For advanced users, self-hosted Keycloak, or providers without a recipe:

1. Log into the Keycloak or Skycloak admin console.
2. Select your realm from the top-left dropdown.
3. Click Identity providers in the left sidebar.
4. Click OpenID Connect v1.0 (or select a specific provider like Google or Azure).
5. Configure the provider:

6. Add attribute mappers under Identity providers > [your-provider] > Mappers for email, firstName, lastName, and any custom claims.
7. Test by opening the account console and clicking the IdP button.

For deeper OIDC brokering details, see the Keycloak identity providers feature documentation and the enterprise SSO setup guide.

For forcing a specific IdP without showing the login page, see using kc_idp_hint to skip IdP selection.

Skycloak setup: add a SAML identity provider

Enterprise customers often use SAML-based IdPs (Entra ID, Okta, ADFS). Adding a SAML IdP to Skycloak follows the same pattern as OIDC, but uses metadata exchange instead of discovery URLs.

Prerequisites

1. A Skycloak account or self-hosted Keycloak 26.x instance.
2. Admin access to the target realm.
3. SAML metadata from the external IdP (Federation Metadata XML file or URL).

Step 1: Add the SAML identity provider

1. Log into the Keycloak or Skycloak admin console.
2. Select your realm.
3. Click Identity providers > Add provider > SAML v2.0.

Step 2: Import metadata

At the top of the form, use the Import from file or Import from URL control to load the external IdP’s SAML metadata. Keycloak auto-populates:

• Single Sign-On service URL
• Single Logout service URL
• Validating X509 certificate

Step 3: Configure provider settings

Click Add.

Step 4: Configure attribute mappers

SAML attribute names vary by IdP. For Microsoft Entra ID:

Add a mapper for each:

1. Go to Identity providers > [your-provider] > Mappers.
2. Click Add mapper.
3. Set Mapper type to Attribute Importer.
4. Enter the SAML attribute name and the local Keycloak attribute name.
5. Click Save.

For debugging SAML assertions, use the SAML Decoder tool.

For a complete SAML IdP walkthrough, see How to Set Entra ID SAML in Keycloak as an IdP.

Domain-based routing with kc_idp_hint

Once you have multiple IdPs configured, you can route users automatically based on their email domain. The kc_idp_hint parameter forces Keycloak to skip its login page and redirect directly to a specific IdP:

https://your-realm.skycloak.io/realms/your-realm/protocol/openid-connect/auth
  ?client_id=your-app
  &redirect_uri=https://app.example.com/callback
  &response_type=code
  &scope=openid
  &kc_idp_hint=entra-id

Implementing domain routing in your application

1. Capture the user’s email address before redirecting to Keycloak.
2. Parse the email domain (user@example.com -> example.com).
3. Look up the domain in your mapping table:

4. Append &kc_idp_hint=<alias> to the authorization URL.

This pattern is covered in detail in Use kc_idp_hint to Choose Identity Provider in Keycloak.

For B2B multitenancy where each customer organization has its own IdP and domain, see Multitenancy in Keycloak Using the Organizations Feature, which automates domain routing natively.

When not to use federated SSO

Federated SSO adds a hop and a layer of indirection. Skip it when:

• You have one user population from one IdP. If everyone authenticates with Google Workspace, integrate your apps directly with Google. No need for a hub.
• Your IdP is stable and never changes. If you use Auth0 and will always use Auth0, federated SSO just adds latency.
• You control the identity source. If users exist only in your own database, you do not need federation, you are the IdP.

Frequently asked questions

What is the difference between federated SSO and regular SSO?

Regular SSO means one identity provider authenticates users for multiple applications (users log in once, access many apps). Federated SSO means one identity hub brokers authentication to multiple external identity providers, so users from different organizations (each with their own IdP) can access the same applications without the apps knowing about each IdP.

Can I mix SAML and OIDC identity providers in one realm?

Yes. Keycloak handles the protocol translation internally. You can have SAML IdPs (Entra ID, Okta) and OIDC IdPs (Google, GitHub) in the same realm, and your applications see a single OIDC or SAML endpoint regardless of the upstream protocol.

How do I route users to the correct IdP automatically?

Use kc_idp_hint to force a specific IdP based on the user’s email domain, or use the Organizations feature in Keycloak 25+ to configure domain-based routing natively. See the domain routing section above and Multitenancy in Keycloak Using the Organizations Feature.

What happens when a user’s IdP changes?

From your application’s perspective, nothing. The hub (Keycloak or Skycloak) handles the upstream IdP change. You update the identity provider configuration in Keycloak (swap the metadata, update client credentials, etc.) and existing users continue to authenticate. Your applications are insulated from the change.

Do I need separate Keycloak realms for each customer?

Usually no. One realm with multiple identity providers and domain routing works for most B2B SaaS. Use separate realms only when customers require hard isolation of configuration, branding, or administration. See Multitenancy in Keycloak Using the Organizations Feature for the single-realm approach.

Conclusion

Federated SSO with an identity hub makes sense when you have multiple user populations, enterprise customers with their own IdPs, or the need to swap identity sources without touching application code. Keycloak and Skycloak handle the protocol translation, attribute mapping, and domain routing so your applications integrate once and authenticate everyone.

If you are adding your first external IdP (OIDC or SAML), follow the Skycloak setup steps above. If you are architecting B2B multitenancy with per-customer IdPs, see the Organizations feature guide. If you need a canonical recipe for adding any IdP to Skycloak, see the Skycloak Identity Providers Recipe.

For managed Keycloak hosting with identity provider support built in, see Skycloak’s Identity Providers feature or start with the Skycloak docs.