Federated identity, SSO and the role of the identity provider

The federation pattern

Federation has three actors. The user is the human or service account trying to reach an application. The relying party (RP), called the service provider (SP) in SAML's older language, is the application. The identity provider (IdP) is the system the RP has agreed to trust for authentication.

The trust is asymmetric. The RP trusts the IdP to vouch for users; the IdP does not, in general, need to trust the RP beyond returning an assertion to a registered callback. The RP holds the IdP's public key, or the metadata that names it, and uses that key to verify that any assertion presented to it was actually signed by the IdP.

The handoff is the same shape everywhere. A user lands at the RP with no valid session. The RP redirects the browser to the IdP. The user authenticates there, which may be a password, an MFA prompt, a passkey, or recognition of an existing IdP session. The IdP issues a signed assertion describing the user. The browser carries it back to the RP. The RP validates the signature, reads the claims, creates a local session, and the user is in. Whether the assertion is dressed in SAML XML or OIDC JSON, the choreography is identical: redirect to the IdP, prove identity, return with an assertion. Chapters 10 and 11 take the two protocols apart.

The motivations are economic, security and administrative. No one wants to issue and revoke a hundred passwords per employee. If each application enforced MFA separately, it would be enforced weakly and inconsistently; with federation, MFA is enforced once at the IdP and every RP inherits the result. And when a staff member is offboarded, disabling the IdP account stops new sign-ins everywhere at once.

Single sign-on and the IdP session

Single sign-on is what users feel when federation works: they sign in once and click into Outlook, Teams, ServiceNow and the intranet without being asked again. SSO is not a protocol; it is the result of layering federation over a session at the IdP. The IdP session is a state that says "this user has authenticated; treat new requests from this browser as authenticated". When the user reaches a new federated application and is redirected to the IdP, the IdP recognises the session and issues a fresh assertion without prompting.

The IdP session lifetime is a usability and security trade-off. Longer sessions mean fewer prompts; shorter sessions limit the dwell time of a stolen session cookie. Most enterprise IdPs default to a few hours of idle timeout and a longer absolute lifetime, but defaults vary by IdP and tenant. (medium; tenant defaults move with vendor releases) A subtlety worth surfacing: the IdP session and the per-application session are different. Signing out of an application usually ends only that application's session; the IdP session persists, and the next sign-in still gets through silently. Single sign-out, the protocol-defined way to end every RP's session at once, is supported unevenly and is the source of more than one offboarding surprise.

The identity provider as a system

An IdP does five things, to varying depth. It stores user identities, or syncs them; in Australian enterprises the dominant pattern is syncing from on-premises Active Directory into Entra using Entra Connect, though some organisations are now cloud-first. It authenticates the user, which is where passwords, MFA factors and passkeys live. It issues identity assertions to relying parties in the protocols they speak, and modern IdPs speak both SAML and OIDC. It maintains the IdP session and runs the policy engine that decides whether to issue an assertion, Conditional Access being the canonical example. And it logs every sign-in. The IdP sign-in log is one of the highest-value telemetry streams a defender has, because it captures every federated authentication attempt and the policy decision attached to it.

The dominant IdPs in Australian enterprise environments in 2026 are Microsoft Entra ID, by a wide margin because of M365 E5 economics in higher education and government, then Google Workspace identity, Okta, and Auth0. Each speaks the same federation protocols; the differences are in the policy engine, the audit-log shape, and the integrations with the rest of the stack.

The relying party

An application becomes a relying party by being federated. On the IdP side, the application is registered with a name, an identifier, a callback URL and the signing key it will use to validate assertions. On the RP side, the IdP's federation metadata is loaded. Either side can revoke the relationship by removing the registration.

Federation can start from either end. SP-initiated sign-in is what users get when they navigate to the application directly and are redirected to the IdP. IdP-initiated sign-in is what they get when they start at the IdP's 'My Apps' portal and click a tile. When an organisation federates to multiple IdPs, home realm discovery asks "which IdP do you belong to?" and routes accordingly, usually by email domain. Just-in-time provisioning lets an RP create a user record from the assertion on first sign-in. The SCIM protocol takes this further, letting the IdP push create, update and deactivate events to the RP automatically, so an offboarded user is removed without manual cleanup. SCIM support is uneven: enterprise-grade applications support it, many consumer-grade tools do not.

The shadow AI lens

Federation pulls every identity decision into one place, which is also the place to write policy about which AI tools staff may use under their corporate identity. An organisation that has fully federated its SaaS estate has one place to enforce identity policy; one that has not, has many.

Conditional Access lives at the IdP and bites at the federation handoff. When a user is redirected from the AI tool to Entra, Conditional Access evaluates the request and either issues an assertion or denies the sign-in. It can refuse specific applications, whole categories, specific devices, specific networks, or sessions above a risk threshold, and the Entra catalogue recognises generative AI as a category, so a defender can target AI tools with one policy rather than a maintained list of names. (medium; the category name and membership are revised periodically)

What federation reaches and what it does not is the shape of the problem. Federation reaches any sign-in to a federated AI tool using the corporate identity, and the IdP's policy engine and audit log apply. It does not reach four things: sign-ins to the same AI tools using personal accounts, which authenticate against a different IdP; AI tools that were never federated and use local accounts only; 'Continue with email' fallback flows that bypass federation by design; and SaaS the organisation has not yet federated, where users hold local accounts.

The 'sign in with Microsoft' button deserves a second look here. From Chapter 8, clicking it triggers an OAuth grant and creates an enterprise app registration. From the federation view, the same click establishes a federation trust relationship the administrator did not pre-approve; the user has federated a third-party application to the corporate IdP on the organisation's behalf. This is why a tenant audit so often surfaces dozens of unfamiliar enterprise applications, each the residue of a federation initiated from outside, one click at a time. The mitigations are the consent settings of Chapter 8, plus periodic review of the enterprise-applications list.

Offboarding shows the seams. When a staff member leaves, the IdP disables the account. Applications that check the IdP on every sign-in stop letting them in immediately. Applications holding long-lived sessions keep them in until the session expires. Applications holding refresh tokens keep getting new access tokens until something revokes them at the IdP or the AI vendor's token lifecycle ends. A 'sign in with Microsoft' relationship to an AI tool can outlive the corporate account by days or weeks unless OAuth grants are explicitly revoked, and most offboarding playbooks, written before the shadow AI era, do not include this step. Cross-tenant guest access through Entra B2B adds a further wrinkle: a guest using AI tools under their guest identity is partly under the resource tenant's governance and partly under their home tenant's, and the boundaries are not always crisp.

Last updated 9 August 2026