Identity federation and SSO
Understand identity-provider trust, validated assertions, relying-party audiences, and the application permissions that remain after single sign-on.
The idea
Federation allows one identity system to provide authentication information to another service under a trust arrangement. Single sign-on reduces repeated login interactions across applications. Protocols such as SAML and OpenID Connect serve defined identity roles; OAuth is primarily an authorization framework. Secure configuration needs correct issuers, audiences, redirect handling, key validation, and lifecycle management. A central identity compromise can affect many connected services.
In practice
A user signs in through an organization’s identity provider, while the application separately determines their permission to access a particular record.
A common misunderstanding
OAuth authorization is not automatically proof of user authentication, and SSO does not remove application-level authorization.
Check your understanding
Why review federation trust relationships?
Think it through: A misconfigured or overly broad trust can let the wrong issuer, token, or audience be accepted.
A relying service accepts a defined claim
Imagine a fictional academy lets staff sign in to a reporting application through a central identity provider. The reporting service relies on authentication information under a configured trust relationship. It must validate the appropriate issuer, audience, protocol state, and other required fields rather than accepting any signed-looking message.
A cryptographic signature protects relevant integrity properties only when the receiver uses the correct trusted keys and validation rules. It does not automatically make a token intended for another service acceptable here.
Single sign-on and authorization differ
Suppose two staff members both complete central sign-in. One may view aggregate course statistics while the other may administer reports. The reporting application still needs its own permission decision for the requested operation and resource.
Do not use an arbitrary forwarded role value as a replacement for an agreed, validated attribute model. Document how attributes are supplied, interpreted, refreshed, and revoked when responsibilities change.
Centralization changes failure impact
A central provider can improve consistency and reduce repeated authentication, but it becomes an important dependency. Availability failures, account compromise, or configuration mistakes can affect several relying applications at once.
For the academy, identify how existing application sessions behave during provider outages and after account revocation. Disabling central login may prevent new sign-ins while leaving separate application sessions active according to their own lifecycle.
For a safe exercise, draw an identity provider and two applications. Label the audience expected by each and the permissions decided locally. Describe why an assertion intended for one should not be accepted by the other. Then add a staff departure and state how central credentials, existing sessions, and delegated access are addressed. The useful understanding is the specific trust arrangement and its lifecycle, not simply that users type a password fewer times.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
NIST: Zero Trust ArchitectureNIST: Digital Identity Guidelines — Federation and Assertions