An employer can let employees enter a benefits provider without creating separate provider-managed credentials. The employer authenticates the employee, then exchanges an agreed authentication result and selected identity attributes with the provider. This arrangement is federated identity integration: an identity provider (IdP) manages accounts and authentication, while a relying party (RP) depends on the IdP through a federation protocol. section 2.5.2
Federation makes identity services portable across organizational boundaries, but it does not eliminate governance. Trust frameworks or equivalent agreements define which data the RP may use and which guarantees the IdP provides. Enterprise relationships commonly use bespoke contracts and SAML; online sign-on commonly uses OAuth or OpenID Connect (OIDC) under a shared click-through license. section 2.5.2
Tenant authentication with OIDC
A multi-tenant service can let each enterprise tenant connect its own IdP while keeping the service’s internal identity system separate. A smaller tenant can instead use a hosted OIDC instance. Both paths can issue tokens containing stable claims such as subject, issuer, audience, and tenant identifier. The policy enforcement point maps those claims to an internal user entity, while current entitlements, support status, group expansion, or account state remain in policy information points rather than becoming stale token data. section 13.3.2 section 13.3.2
Federation is useful when a partner operates a suitable identity provider, especially for people an organization does not employ or manage. It becomes harder when no established partner relationship exists or when a decision requires claims from several independent authorities. Shared protocols, attribute mappings, and trust arrangements must still be established and maintained. section 16.1
