Glossary
SSO
By Emil Björk · Microsoft ecosystem consultant, Gothenburg
Single sign-on — authenticate once to an identity provider, get access to many apps without re-prompting.
Single sign-on (SSO) is the authentication pattern where users authenticate once with an identity provider — Microsoft Entra ID — and access many connected applications without re-entering credentials. In Microsoft 365, SSO is built in across Microsoft apps; for third-party SaaS, SSO is configured per app using SAML 2.0 or OpenID Connect (OIDC) with Entra ID as the IdP. From the user's experience: sign in once in the morning, every connected app works automatically. From IT's: one place to enforce MFA, Conditional Access, and access governance. SSO is the foundation of identity-led enterprise architecture and a prerequisite for zero-trust controls.
Worked example
An employee signs into their laptop with a work account in the morning, opens Outlook, Teams, and a third-party expense-reporting SaaS app across the day, and is never prompted for a password again — because each app is configured to trust Entra ID as its identity provider via SAML or OIDC, and the initial sign-in already satisfied Entra ID's Conditional Access requirements (MFA included). When that employee leaves the company, disabling their single Entra ID account immediately locks them out of every one of those connected apps at once, rather than IT needing to separately revoke access in each app's own admin console.
Common pitfalls
Assuming SSO automatically means an app is secure is a common overreach — SSO controls authentication (proving who you are), not authorisation within the app itself, so a misconfigured app can still expose more than it should to a correctly-authenticated user. Configuring an app's SSO integration once and never revisiting it is another common gap — a certificate used to sign SAML assertions expires on a schedule, and an expired signing certificate breaks sign-in for every user of that app simultaneously, usually with a confusing error message. And treating "the user can log in" as proof SSO is fully working glosses over the more common failure mode: SSO working for authentication while a broken attribute mapping (wrong email, missing group claim) causes the app itself to behave incorrectly once the user is inside it.