What is single sign-on?
Single sign-on is exactly what it sounds like: one login, many apps. Instead of remembering separate usernames and passwords for every tool your company uses, employees sign in once — typically through their work account — and get access to everything they need.
If your organization uses Microsoft Entra ID, you have probably experienced SSO already. You sign into your Microsoft account in the morning, and then you can open Outlook, Teams, SharePoint, and any connected third-party apps without being asked to log in again. That is SSO at work.
Behind the scenes, SSO uses a trusted identity provider (like Entra ID) to vouch for the user. When you try to access an application, that app asks your identity provider: "Is this person who they say they are?" If the identity provider confirms it, the app lets you in. No separate login required.
How does SSO work technically?
SSO relies on standard protocols to pass authentication information between the identity provider and the applications. The two most common are:
SAML 2.0 (Security Assertion Markup Language) is the older, more established protocol. It works by exchanging XML-based assertions between the identity provider and the application. When you try to access an app, it redirects you to your identity provider. You authenticate there, and the identity provider sends a signed SAML assertion back to the app confirming your identity.
OpenID Connect (OIDC) is the newer, more lightweight protocol built on top of OAuth 2.0. It uses JSON Web Tokens (JWTs) instead of XML. Most modern SaaS applications support OIDC, and it is generally easier to implement.
Microsoft Entra ID supports both protocols, which means you can connect virtually any modern business application to your Entra ID tenant for SSO.
Why does SSO matter for security?
It might seem counterintuitive that logging in once is more secure than logging in many times. But the argument for SSO is strong.
Without SSO, users juggle dozens of passwords. That leads to password reuse, weak passwords, and passwords stored in sticky notes or spreadsheets. With SSO, users only need to remember one strong password (ideally combined with MFA), protected by your identity provider's full security stack.
When all authentication flows through one identity provider, IT teams have a single place to enforce security policies. You can require multi-factor authentication, block sign-ins from risky locations, and apply conditional access policies — all from Entra ID.
SSO also makes offboarding cleaner. When an employee leaves, disabling their Entra ID account immediately cuts off access to every SSO-connected application. Without SSO, IT has to remember to deactivate the user in each individual app — and inevitably some get missed.
And SSO gives you centralized sign-in logs. You can see which users accessed which applications and when, which matters for security monitoring and compliance audits.
What is the "SSO tax"?
The "SSO tax" refers to the practice of some SaaS vendors charging significantly more for SSO support. Basic plans often only support username/password authentication, while SSO integration is reserved for enterprise tiers at a much higher price.
This is a real frustration for small and mid-sized companies. SSO is fundamentally a security feature, not a luxury. Paying a premium for basic security functionality is something many in the industry agree is wrong. When evaluating SaaS tools, check whether SSO support is included in the plan you are considering.
How do you set up SSO with Microsoft Entra ID?
Setting up SSO in Entra ID involves a few steps. Go to Enterprise Applications in the Entra admin center — Microsoft maintains a gallery of thousands of pre-integrated apps where SSO is pre-configured. Add the application (gallery apps come largely pre-configured; custom apps require more setup). Configure the SSO method by choosing SAML or OIDC and exchanging metadata between Entra ID and the app. Assign users or groups to decide who should have access. Then test the connection using Entra ID's built-in test function.
For gallery apps, this process can take 15 minutes. Custom integrations take longer, especially if the app's documentation is sparse.
SSO and identity governance
SSO handles authentication — proving who you are. But it does not answer whether you should have access in the first place.
Consider this scenario: an employee moves from marketing to finance. SSO ensures they can still log in. But should they still have access to the marketing automation platform? And should they now have access to the accounting software? SSO alone does not answer these questions.
Tools like Adcyma add value here. By connecting to your Entra ID tenant, Adcyma manages the governance layer: who should have access to which SSO-connected applications, based on their role, department, and organizational policies. When someone changes roles, their application assignments update automatically.
What is the difference between SSO and password managers?
Password managers store multiple passwords so you do not have to remember them. They are useful, but fundamentally different from SSO.
With a password manager, you still have separate accounts and passwords for every application. The password manager just remembers them for you. Each app still manages its own authentication independently.
With SSO, there is only one account and one authentication event. The applications trust your identity provider to handle authentication. This gives IT much more control and visibility.
For organizations using Entra ID, SSO is the better path. Password managers still have a role for personal accounts and apps that do not support SSO, but they should not be your primary access strategy.
Does SSO replace multi-factor authentication?
No. SSO and MFA work together, not as alternatives. SSO determines how many times you need to authenticate. MFA determines how thoroughly that authentication is verified.
The best practice is to use both: SSO so users only log in once, and MFA to make sure that single login is properly secured. In Entra ID, you configure MFA through conditional access policies that apply to all SSO-connected applications.