Single Sign-On and Federation: SAML, OAuth, OpenID Connect, Tokens, and Trust

 

Single sign-on reduces the number of times users must authenticate, while federation allows separate security domains to trust identity information from one another. Modern enterprise access often combines both: a central identity provider authenticates the user, then applications rely on signed assertions or tokens instead of maintaining independent passwords.

SSO is an experience; federation is a trust relationship

Single sign-on describes the user outcome: authenticate once and reach multiple applications without repeated credential prompts. Federation describes how separate systems establish enough trust to make that possible.

An organization can provide SSO across applications it owns, federate with a partner, or use a SaaS identity provider for both. The architecture matters because compromise or misconfiguration in the identity provider can affect every relying application.

SAML is common in enterprise web federation

SAML uses signed XML assertions to communicate identity and attributes from an identity provider to a service provider. It remains common for enterprise SaaS applications and browser-based workforce SSO.

The trust configuration includes issuer identifiers, endpoints, certificates, audience restrictions, and attribute mappings. A successful SAML login does not automatically mean the user should receive every application role; authorization still needs a separate policy decision.

OAuth focuses on delegated access

OAuth lets a client obtain an access token to call a protected resource on behalf of a user or itself, depending on the flow. The token carries or represents limited authority rather than giving the client the user’s password.

Scopes, audiences, client registration, redirect URIs, token lifetime, and consent are important security boundaries. OAuth is an authorization framework, not by itself a complete user-authentication protocol.

OpenID Connect adds identity to OAuth-based flows

OpenID Connect layers identity concepts on top of OAuth and introduces an ID token that tells the client about the authenticated user. This is common in modern web and mobile applications because one standards family can support sign-in and API access without using the same token for both purposes.

Application registrations, identities, permissions, and governance all meet around federation protocols; the SC-300 preparation guide shows that wider administration boundary.

Tokens must be validated, not merely decoded

A token that looks syntactically correct is not automatically trustworthy. Validate the signature, issuer, audience, lifetime, and any application-specific claims required for the decision. Reject tokens intended for a different API or tenant.

Key rotation also matters. Applications need a safe way to discover current signing keys and handle changes without disabling validation.

Federation reduces passwords but concentrates trust

Centralized identity simplifies lifecycle control and user experience, but it also creates a high-value dependency. Protect administrative access, monitor configuration changes, use strong authentication, and maintain recovery procedures for the identity provider.

Federation authenticates an identity but does not eliminate later authorization decisions; Zero Trust security reinforces explicit verification and least privilege after sign-in.

Legacy authentication may coexist with modern federation

Enterprise environments rarely migrate all applications at once. Kerberos may serve domain-integrated systems while SAML or OpenID Connect serves cloud applications. Proxies or identity bridges may connect older and newer models.

Kerberos authentication helps contrast ticket-based Windows authentication with browser token federation: both solve identity trust, but through different mechanisms and boundaries.

Transport encryption does not replace token validation

TLS protects assertions and tokens as they move across networks, but an application still needs to validate who issued them and what they authorize. Conversely, a correctly signed token should not be sent across an insecure channel.

Federation relies on several layers of trust working together, and SSL encryption and authentication keeps transport encryption and identity authentication conceptually separate.

Cloud authorization still applies after federation

A federated user may authenticate through a corporate identity provider and receive a cloud role or permission set. The federation proves identity; the cloud platform’s policies determine what resources that identity can use.

Trusted identity and resource authorization remain separate decisions; AWS identity and access management provides a cloud example through users, roles, policies, and resources.

Lifecycle and deprovisioning are critical

SSO improves account control only if employee departure, role change, contractor expiry, and application access reviews propagate correctly. Remove unnecessary local accounts, automate provisioning where reliable, and verify that disabling the authoritative identity actually blocks downstream access.

Federation is only one part of identity lifecycle management, a broader operating responsibility reflected in the SC-300 identity security path.

Start with the trust map

When designing or troubleshooting SSO, draw the actors: user, browser or client, identity provider, application, API, token issuer, and resource. Mark who trusts whom, what artifact carries that trust, which keys verify it, and where authorization occurs.

The SC-900 identity fundamentals provides a Microsoft-specific orientation, after which the same federation principles can be mapped to other clouds and SaaS platforms.