Single sign-on and federation: SAML, OAuth 2.0 and OpenID Connect
In short: Single sign-on lets people log in once to a trusted identity provider and reach many applications without new passwords. Federation is the trust that makes this work across organisations. SAML and OpenID Connect handle sign-in; OAuth 2.0 handles delegated access to APIs.
Single sign-on and federation
Single sign-on (SSO) means a user authenticates once and then reaches many applications without signing in again. Federation is the trust relationship behind it: an application (the service provider or relying party) agrees to accept proof of identity issued by an identity provider (IdP). The two sides exchange metadata and signing keys in advance, so the application can verify that a token really came from the IdP and has not been altered.
The security benefits are significant. Users have one strong credential instead of dozens of weak ones, MFA is enforced in one place, and disabling a leaver in the IdP cuts off every connected application at once.
SAML 2.0
Security Assertion Markup Language (SAML) 2.0 is an XML-based standard that has been the backbone of enterprise SSO for many years. After the user signs in, the IdP sends a digitally signed assertion to the application, usually through the browser. The assertion states who the user is and can carry attributes such as email address, department or group membership. SAML is common for connecting a company directory to SaaS tools such as HR, payroll and ticketing systems.
OAuth 2.0 and OpenID Connect
OAuth 2.0 is about authorisation, not login. It lets a user allow one application to act on their behalf against an API, without handing over their password. The result is an access token with a limited scope (for example, read calendar only) and a short lifetime. Think of a hotel key card: it opens certain doors for a set period, but it says little about who you are.
OpenID Connect (OIDC) adds an identity layer on top of OAuth 2.0. As well as an access token, the application receives an ID token, a signed JSON Web Token (JWT) describing the user. OIDC is the usual choice for modern web and mobile apps and for cloud consoles. For browser and mobile apps the recommended flow is the authorisation code flow with PKCE (Proof Key for Code Exchange), which protects the code from being intercepted and reused.
| Feature | SAML 2.0 | OAuth 2.0 | OpenID Connect |
|---|---|---|---|
| Main purpose | Sign-in (SSO) | Delegated API access | Sign-in (SSO) |
| Token format | XML assertion | Access token (often JWT) | ID token (JWT) plus access token |
| Typical use | Enterprise SaaS | Apps calling APIs | Web, mobile, cloud consoles |
Risks and good practice
- The IdP becomes a crown jewel. Protect its admin accounts with phishing-resistant MFA and watch for changes to federation trusts and signing certificates.
- Validate tokens properly. Check the signature, issuer, audience and expiry. Never accept unsigned tokens.
- Consent phishing. Attackers trick users into granting a malicious OAuth app broad scopes. Restrict which apps users can approve and review granted permissions.
- Token theft. Stolen session tokens can bypass MFA. Keep token lifetimes short and use conditional access to bind sessions to managed devices where possible.
Tip: a handy exam line is "OAuth is for authorisation, OIDC is for authentication, SAML is the older XML way to do SSO".
Practice
Your company wants staff to sign in to a SaaS HR system with their corporate account. Which protocols could do this?
Why is OAuth 2.0 on its own not a login protocol?
What does PKCE protect against?
Key takeaways
- SSO means one sign-in for many apps; federation is the trust that enables it.
- SAML uses signed XML assertions and is common for enterprise SaaS.
- OAuth 2.0 delegates API access with scoped, short-lived tokens.
- OpenID Connect adds an ID token to OAuth and is the modern sign-in choice.
- Protect the IdP, validate tokens fully and control OAuth app consent.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.