"We want one login for everything" is one of the most common requests IT teams hear. It usually means two different things at once. Sometimes it means "stop making people remember twelve passwords." Sometimes it means "stop making people look in twelve places." The first is an identity problem, and single sign-on solves it well. The second is a data problem, and no login system can solve it, because the work is still in twelve places after everyone signs in.
This guide separates the two. It explains what SSO does, what it leaves untouched, how one platform differs, and why most companies of any size end up wanting both.
What does single sign-on actually solve?
Single sign-on moves authentication to one place, your identity provider. When someone opens an app, the app hands the login to the identity provider, which checks who they are and sends back a signed statement saying so. The app trusts that statement instead of keeping its own password. We explain the mechanics in what single sign-on is.
The gains are real. People have one password and one second factor to protect. IT can enforce sign-in policy in one place. When someone leaves, disabling their identity provider account blocks sign-in to every connected app at once. Paired with SCIM provisioning, accounts are created and removed as your directory changes, instead of by hand in each tool.
What does SSO leave unsolved?
Everything that happens after sign-in. With SSO across twelve apps, a person still has twelve places where work lives, and each one keeps its own copy of the facts. The customer name is typed into the CRM, the tracker, the wiki, and the signing tool. When it changes in one, the others drift.
Permissions are still separate too. SSO says who someone is. Each app still decides on its own what that person may see and do, with its own roles and its own sharing settings. A person moved from sales to support needs their access changed in every app, and a reviewer asking "who can see this customer's contract?" gets a different answer from each tool.
Search is still split. Each app searches only itself. And the record of who did what is split across twelve audit logs in twelve formats, if each app keeps one at all. SSO tells you that someone signed in. It cannot tell you what they did next across tools.
How is one platform different from one login?
One platform puts the work itself in one system, so the login, the records, the permissions, and the record of activity are all shared. The table sets the two side by side.
| Question | SSO across many apps | One platform (with SSO) |
|---|---|---|
| How many logins? | One, through the identity provider | One, through the identity provider |
| How many copies of a customer record? | One per app that needs it | One, linked to deals, tasks, and contracts |
| Where are permissions set? | Separately in each app | One role model across every module |
| What does search cover? | One app at a time | Every module in one query, filtered by permissions |
| Where is the audit record? | Split across each app, in different formats | One workspace audit log |
| Can an AI assistant see the whole picture? | Only through connectors, one app at a time | Yes, within the asker's permissions |
| Offboarding | Blocks sign-in everywhere; data stays scattered | Blocks sign-in; the person's work is already in one place to reassign |
The first row is the same in both columns, which is the point. SSO is not the thing that differs. It is the foundation both approaches stand on.
Do you still need SSO if you use one platform?
Yes, in almost every company. Even a company that runs most of its work on one platform still has other systems: email, payroll, accounting, code hosting. SSO keeps sign-in to all of them under one policy. A work platform should therefore plug into your identity provider rather than replace it. In Atlas that means SAML single sign-on and SCIM provisioning, including groups, on paid plans, with directory groups mapped to roles. Atlas does not support OIDC for single sign-on. People can also sign in with Google or GitHub, and two-factor sign-in is available on every plan.
So the honest framing is not SSO versus one platform. It is SSO alone versus SSO plus one platform for the work that crosses teams.
How do you decide which problem you have?
- Count the complaints. If people mostly complain about passwords and sign-in prompts, you have an identity problem. If they complain about not finding things, retyping things, or asking colleagues for status, you have a data problem.
- Trace one customer. Follow a single customer from first contact to delivery and count how many tools hold a copy of their details. More than two usually means a data problem.
- Ask an access question. Ask "who can see this contract?" and time how long the answer takes. If it requires checking several admin consoles, permissions are fragmented.
- Try an offboarding. Walk through what happens to a leaver's open deals, tasks, and documents. If they sit in several tools with no single owner to hand them to, SSO has done its part and the rest is still manual.
- Fix identity first, then data. Put SSO and provisioning in place regardless. Then move the cross-team work onto one platform, one workflow at a time.
What Atlas does and does not do here
Atlas puts tasks, projects, docs, a CRM, an inbox, meetings, contracts, forms, search, analytics, and an assistant on one platform with one identity and one permission model. Role-based access covers all 16 modules, you can define custom roles, Search respects those roles at query time, and actions by people and by the Assistant land in one workspace audit log on paid plans. You can see the enterprise controls on the enterprise page.
The limits: single sign-on is SAML only, not OIDC. Audit events do not stream to a SIEM today. Of the 27 listed connectors, only Gmail, Google Calendar, and Google Drive can be connected now, three are in beta, and 21 are in development, so Atlas will not yet pull every other app's data into one view. And wrxstack holds no SOC 2 or ISO 27001 report.
Who one platform is not for
If your teams rarely share work and the only complaint is password fatigue, SSO alone is the right fix and a new platform adds change without much gain. If your identity provider only speaks OIDC, Atlas single sign-on will not connect to it today. And if a regulator requires each system to hold a specific certification, check that requirement before moving any work.
Is single sign-on the same as having one platform?
No. Single sign-on gives one login to many separate apps, each with its own data and permissions. One platform puts the work in one system, so records, permissions, search, and the audit log are shared as well as the login.
Does SSO give us one place to search?
No. SSO only handles who signs in. Each app still searches only its own data unless the work lives in one platform or you add a separate search layer.
Do we need SSO if most work runs on one platform?
Yes. Email, payroll, accounting, and code hosting usually stay in other systems, and SSO keeps sign-in to all of them under one policy. The platform should connect to your identity provider, not replace it.
Which single sign-on standard does Atlas support?
SAML. Atlas does not support OIDC for single sign-on. SCIM provisioning, including groups, is available on paid plans, and people can also sign in with Google or GitHub.
Does one platform make offboarding easier?
Yes, beyond what SSO does. SSO blocks the leaver's sign-in everywhere, and one platform also keeps their open tasks, deals, and documents in one place so they can be reassigned in one pass.
Where this lives in wrxstack: security at wrxstack and the Trust Center.