A nurse signs in once at 7:00 a.m. and spends her shift moving between the hospital's scheduling system, a cloud HR portal, a pharmacy vendor's ordering site and the shared drive, without typing her password again. The HR portal and the ordering site belong to other companies, and neither of them ever sees her password.
That convenience comes from federation and single sign-on. On the CompTIA Security+ SY0-801 exam they appear under objective 4.5, along with the protocols SAML, OAuth and LDAP, and questions usually describe an access situation and ask which mechanism or protocol fits. This lesson explains who trusts whom in a federated login, what each protocol actually carries, and why SSO concentrates risk as much as it reduces it.
Federation lets one organization's login work at another organization's service
Federation is a trust relationship that lets an identity managed in one place be accepted somewhere else. Every federated login has two roles:
- The identity provider (IdP) authenticates the user and vouches for them. Microsoft Entra ID, Okta, AD FS and Google Workspace are common examples.
- The service provider (SP), called the relying party (RP) in OpenID Connect terminology, is the application that accepts the IdP's word instead of authenticating the user itself.
The IdP's word takes the form of a signed message: a SAML assertion or an OpenID Connect token. The trust is configured in advance by exchanging metadata. The IdP publishes its identifier, its sign-in address and the public certificate it signs with; the SP registers its own identifier and the address where it receives assertions. From then on, the SP checks every assertion's signature against the IdP's certificate. If the signature is valid, the SP believes what the assertion says.
That makes the IdP's signing key the most valuable secret in the arrangement. An attacker who steals it can mint assertions for any user, including administrators, at every service that trusts the IdP, without ever touching a password or an MFA prompt. The technique is known as Golden SAML, and it's why IdP signing keys belong in a hardware security module or a managed key service.
Federation also works across company boundaries. A partner's employees can reach your supplier portal with their own company's login, and your staff can use theirs at a SaaS vendor. The trade-off is that you now depend on the partner's identity process. If they forget to disable a departed employee, that person can still reach your portal, so federated guest access still needs its own reviews.
SSO means one strong login, and one very valuable target
Single sign-on means a user authenticates once to the IdP and then reaches many applications without signing in again. When the nurse opens the HR portal, the portal redirects her browser to the IdP, the IdP sees she already has a session, and it issues a fresh assertion for the HR portal without asking for anything.
The security benefits are real:
- Users have one password to protect instead of twenty, so they're less likely to reuse or write them down.
- MFA, device checks and sign-in risk policies are enforced in one place, for every connected application.
- Deprovisioning is faster. Disabling one IdP account blocks new sign-ins to every connected app at once.
- Sign-in logs for every application land in one place, which makes impossible-travel and brute-force patterns visible.
The cost is blast radius. A compromised IdP account opens every application behind it, and a stolen IdP session cookie is just as broad. An IdP outage stops sign-ins everywhere, which is why emergency access accounts exist, covered in the account types lesson. Organizations that rely on SSO protect the IdP more heavily than anything else: phishing-resistant MFA for every user, especially administrators, short sessions and step-up authentication for sensitive apps, tightly limited IdP admin roles, and alerts on changes to federation settings and signing certificates.
Don't confuse SSO with synchronized passwords. If ten applications each check the same directory password, the user has one password but still types it ten times, and each application handles it. That arrangement is sometimes called same sign-on. With true SSO, the applications never see the password at all. Inside a Windows domain, SSO is provided by Kerberos on port 88, where the domain controller issues tickets after the first logon.