Single sign-on (SSO) lets a person sign in once at an identity provider and reach many applications without separate passwords. Apps trust a signed assertion from the provider. It cuts password sprawl but concentrates risk: a weak provider login, a forged assertion or an unended session can expose every connected app.
How does SSO work?
NIST's digital identity guidelines on federation describe the pattern. A subscriber authenticates to an identity provider (IdP). A relying party (RP), the application, receives an assertion from the IdP that tells it who the person is, and creates its own authenticated session. NIST notes that this federation process lets the subscriber obtain services from multiple RPs without holding separate authenticators at each, and that this is sometimes known as single sign-on.
It adds that federation is generally the preferred approach when the RP and the subscriber's account are not administered in the same security domain, since it spares the RP from issuing another authenticator. It can also be used within one domain for benefits including centralized account management.
What protects an assertion?
NIST SP 800-63C defines federation assurance levels with requirements for how assertions are protected. The ones worth knowing:
- Audience restriction. The assertion targets a specific RP, and the RP can confirm that it is the intended audience. At the higher level it is restricted to a single RP.
- Replay protection. The assertion cannot be presented more than once to be accepted.
- Assertion injection protection. The RP is strongly protected from an attacker completing a federated transaction and starting an authenticated session with a forged, captured or modified assertion.
- Trust establishment and key exchange. The IdP and RP agree on rights and expectations, and exchange identifiers and key material, so signatures can be verified against the expected IdP.
Each of these exists because a known failure mode needs it. An assertion not tied to an audience can be accepted by the wrong app. One with no replay protection can be reused. Without injection protection an attacker can try to feed the RP a forged one.
What can go wrong?
The concentration of trust is the central issue. Some practical ways it shows up:
- Weak IdP sign-in. If the provider accepts a guessable password with no second factor, all connected apps inherit that weakness.
- Misconfigured RPs. An app that accepts assertions without checking the signature, issuer, audience or expiry defeats the design.
- Sessions that outlive the login. NIST states that the RP manages its sessions separately from the IdP's, that an assertion's validity window does not set the session's lifetime, and that terminating the IdP session will not necessarily terminate sessions at downstream RPs. In most cases the RP session far outlives the assertion. Disabling an account at the IdP does not always sign the person out everywhere immediately.
- Apps left outside SSO. Local accounts in an app that supports SSO still exist, with their own passwords.
- Unreviewed access. SSO makes it easy to grant access and just as easy to forget it.
A constructed example
A 50-person company connects its chat tool, ticketing system and cloud console to one IdP. Everyone is delighted. A month later a laptop is stolen. The IdP account is disabled within the hour. The ticketing system, though, keeps its session open for 30 days, and the cloud console has a local administrator account that was never moved to SSO. Disabling the IdP account closed the front door and left two side doors open. The fixes: set shorter RP session lifetimes, use any end-session signaling the apps support, and remove or lock down the local accounts. This scenario is invented.
How to check or apply this
- List every application and note whether it uses SSO, local accounts, or both.
- Require strong, phishing-resistant multi-factor authentication at the IdP. It is the front door for everything.
- For each connected app, confirm it validates signature, issuer, audience and expiry on assertions.
- Disable or restrict local accounts where SSO is available, and keep a monitored break-glass account.
- Check session lifetimes in each app and what happens there when an IdP account is disabled.
- Use group-based access and review membership on a schedule.
- Log IdP sign-ins and app sessions centrally, and alert on new locations or devices.
- Plan for IdP outage with a tested recovery path.
Quick check
Is SSO the same as using the same password everywhere?
No. With SSO you authenticate to one provider and apps receive signed assertions. They never see your password.
If I disable a user at the IdP, are they signed out everywhere?
Not necessarily. NIST notes that ending the IdP session does not automatically end sessions at downstream applications. Check each app.
Sources
Last reviewed: 18 October 2026.
