You're probably dealing with this already. Staff sign in to Microsoft 365, then a booking tool, then HR, then a line-of-business app, then the corporate WiFi, often with a different method for each one. A hotel group has one set of systems at head office and another on property. A hospital has clinical apps, shared workstations, and segmented wireless access. A retail operator has staff moving between stores, tablets, POS, and back-office dashboards.
That mix creates friction fast. Users forget passwords, IT teams reset accounts, and shared WiFi credentials linger long after they should have been removed. The result isn't only annoyance. It's weaker control over who can access what, from which device, and for how long.
That's where single sign-on, or SSO, becomes useful. If you're searching for what is single sign on, the short answer is simple: it lets a user authenticate once and then access multiple approved systems without entering credentials again and again. The more useful answer is operational. SSO gives IT one identity layer for access to apps, and in the right design, it can also support how people and devices join secure networks.
The End of Password Chaos
Most enterprise environments didn't become messy on purpose. They grew that way. One cloud app became five. One office became many sites. One wireless network for IT became separate SSIDs for staff, guests, contractors, and devices.
That's how password sprawl starts. A member of staff may need email, HR, scheduling, file access, internal dashboards, and network access, all before they can do any real work. IBM describes SSO as a scheme where users log in once with a single set of credentials and access multiple applications during the same session, enabled by a trust relationship between service providers and an identity provider. IBM's overview of single sign-on maps closely to what UK organisations needed as cloud adoption and remote work accelerated.
What password sprawl does to operations
When every application asks for its own login, users start taking shortcuts. They reuse passwords. They save them in browsers. They ask colleagues for the “ staff WiFi password” because it's quicker than waiting for IT.
For an enterprise IT manager, control is the paramount concern. Separate logins create separate islands of access, and those islands are harder to govern when people move roles, leave the business, or work across multiple locations.
Password chaos is rarely one big failure. It's usually a hundred small access decisions that nobody can manage consistently.
Why SSO changes the picture
SSO reduces the number of passwords users need to manage, which improves the login experience and supports stronger security when paired with central policy and MFA. It also fits the reality of distributed organisations where staff need one login across email, HR, booking tools, POS, internal apps, and site services.
That same logic is now shaping network access. If you're already moving towards identity-led access for applications, it makes sense to look at passwordless WiFi as part of the same design approach, not as a separate problem.
Understanding the Core SSO Concept
SSO shifts authentication away from each individual application and places it with one trusted identity system. The user signs in once, that identity is verified, and connected services accept that result instead of asking for another password.
That sounds simple, but the value is architectural. You are changing where trust lives.
The three parties in every SSO flow
Every SSO design has three participants, and each has a different job:
- The user wants access to an application, service, or network resource.
- The Identity Provider or IdP verifies identity and applies sign-in policy. Common examples in UK organisations include Microsoft Entra ID and Okta.
- The Service Provider or SP is the system the user is trying to reach, such as Salesforce, a booking platform, an intranet, or another business system.
The point that often causes confusion is trust. The application does not need to collect and check the password itself. It relies on the IdP to do that job correctly, then accepts the result.
What the trust relationship really means
Auth0 explains SSO clearly in enterprise terms: the IdP authenticates the user once, then issues a session artifact or token that trusted service providers validate for later access. In practice, the user is redirected to the IdP, authenticated there, and returned to each app without repeated credential prompts. Auth0's guide to how single sign-on works is especially relevant in UK environments using Entra ID across SaaS and internal systems.
A practical way to read that is this:
- A user opens an application.
- The application checks whether a trusted IdP has already authenticated that user.
- If no active session exists, the user signs in with the IdP.
- The IdP confirms identity and returns proof that the application can validate.
- Other connected systems can accept that same proof during the session.
Practical rule: SSO does not turn every system into one platform. It gives multiple systems one place to verify identity.
Why this matters outside web apps
This is also where SSO becomes more than a SaaS convenience. Once identity is centralised, the same model can be used for more than browser sessions. It can also shape how you control access to internal services and, in the right design, how users join the corporate wireless network.
That matters for IT operations. A finance app, a VPN session, and an employee WiFi connection may be different services, but they all start with the same question: who is this user, and should they be allowed in? When Entra ID or Okta answers that question consistently, access policy becomes easier to manage across both applications and network entry points.
For teams still running staff WiFi with a shared password, this is a major shift. Instead of authenticating a device with a password everyone knows, you authenticate a person or a managed device against a trusted identity source. That gives you tighter control, clearer audit trails, and a cleaner way to remove access when roles change or employment ends.
How SSO Works The Core Protocols
The user experience looks simple. Underneath, SSO depends on standard protocols that let an application trust an identity decision made somewhere else.
For an enterprise IT manager, the practical question is not just "what is SSO?" It is "how does one system accept proof from another system without asking the user to log in again?" The answer depends on a small set of protocols that move identity data between the application, the identity provider, and sometimes the device itself.
That matters beyond browser logins. The same trust model used to open a SaaS app can also influence how users connect to VPNs, wired networks, and corporate WiFi when those access decisions are tied back to Entra ID, Okta, or another central identity source.
SAML in plain English
SAML 2.0 is still common in enterprise SSO, especially for established SaaS platforms and line-of-business systems.
SAML works by passing trusted identity statements between the application and the identity provider. A user tries to open an application. The application redirects them to the IdP. The IdP authenticates the user and sends back a digitally signed assertion. The application checks that signature, accepts the identity claim, and creates a session.
That flow suits environments where the browser is doing most of the work and the application expects a formal, standards-based exchange.
SAML is often a strong fit for:
- Enterprise SaaS such as HR, finance, or legacy business applications
- Browser-based workflows where users access systems through a web session
- Central policy enforcement when IT wants one place to govern authentication
OAuth and OIDC in plain English
OAuth 2.0 started as a way to grant limited access to a resource without sharing a full set of credentials. By itself, it is about authorisation.
OpenID Connect, or OIDC, adds identity on top of OAuth 2.0. That gives modern applications a standard way to confirm who the user is while still using token-based access patterns. If SAML often fits older browser-centric SaaS, OIDC usually fits newer web apps, mobile apps, and API-driven services.
In practice, OIDC tends to feel lighter for modern development teams because tokens work well across front-end apps, back-end services, and mobile clients. For IT, that means fewer awkward workarounds when the application is not a traditional browser session.
OIDC tends to fit:
- Modern cloud applications
- Mobile and single-page apps
- API-heavy environments where tokens are already part of the design
A quick note on Kerberos
You may also hear about Kerberos in SSO discussions. Kerberos is closely tied to traditional Active Directory environments and on-premise Windows authentication. It remains relevant in internal enterprise estates, especially where domain-joined devices and legacy applications are still common.
That said, many current SSO projects focus on federated identity across cloud and hybrid services. In those cases, SAML and OIDC usually get more attention because they connect more naturally to SaaS platforms and externally accessible services.
SAML vs OIDC At a Glance
| Feature | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| Primary role | Authentication for enterprise web applications | Authorisation with identity added through OIDC |
| Common use case | Established SaaS and browser-based enterprise apps | Modern web apps, mobile apps, APIs |
| Format | XML-based assertions | Token-based flows |
| Typical flow | Redirect to IdP, authenticate, return signed assertion | Redirect or token flow, then app uses tokens for identity and access |
| Best fit | Traditional enterprise SSO integrations | Newer cloud-native and app-centric architectures |
What matters for an IT manager
Protocol names matter less than design choices. You need clear answers to four operational questions:
- Which apps support SAML or OIDC
- Which IdP will act as your central control plane
- How session timeout, MFA, and conditional access will be enforced
- Whether network access, including staff WiFi, should also validate identity against that same source
That last point is where SSO becomes especially useful for infrastructure teams. If your wireless platform can use the same identity layer as your SaaS estate, access policy becomes more consistent from the login page to the network edge. That is one reason many teams reviewing the benefits of single sign-on for access control and operations also start looking at identity-backed WiFi authentication, not just web app logins.
Weighing the Benefits and Security Trade-offs
SSO is often sold as a user convenience feature. That undersells it. Done properly, it's an access control model that can improve the user experience and tighten operational security at the same time.
Okta notes that the technical advantage of SSO isn't just convenience. It reduces password sprawl and repeated login events that increase help-desk load and user friction. Okta's overview of single sign-on security also highlights a point architects care about: if the IdP session is invalidated, connected applications can deny access on the next token check.
Where the business value shows up
The first benefit is simpler access. Users log in once, get to work sooner, and stop treating authentication as a daily obstacle.
The second is stronger central control. IT can apply MFA, conditional access, session policies, and revocation from one identity layer instead of chasing settings inside each application.
A third benefit is cleaner joiner, mover, leaver handling. When identity sits centrally, onboarding and offboarding become more consistent. That's one reason teams exploring single sign-on benefits often connect SSO projects with wider identity governance work.
The trade-offs you should take seriously
There is a real “keys to the kingdom” concern. If an attacker compromises the user's primary sign-in, the blast radius can be larger because one account may provide access to many systems.
There's also resilience risk. If the IdP is unavailable, access to connected services may be disrupted. And integration isn't always clean. Older apps, niche systems, and local network services don't always fit neatly into a modern SSO model.
The right question isn't whether SSO has trade-offs. It's whether you'd rather manage those trade-offs centrally or keep managing dozens of disconnected ones.
Common mitigations
Use a layered approach:
- Protect the IdP heavily with MFA, conditional access, device trust, and strong admin controls.
- Plan resilience so that an IdP issue doesn't become an organisation-wide standstill.
- Roll out in phases starting with high-value apps and clear user groups.
- Review access regularly so stale entitlements don't survive long after they're needed.
A weak SSO rollout can centralise problems. A strong one centralises control.
SSO Beyond Web Apps Network and WiFi Access
Most articles stop at SaaS. That's useful, but incomplete. In real environments, staff don't just need app access. They need secure network access when they arrive on site, connect a managed laptop, open a tablet in a branch, or roam between properties.
That's where the SSO conversation gets more interesting. The same identity provider that handles access to Microsoft 365, HR systems, or internal dashboards can also become the source of truth for wireless authentication policies.
Optimal IdM reports that 52% of IT professionals in North America use SSO for identity management in its discussion of single sign-on adoption . For UK organisations with multiple venues or properties, that maturity matters because staff often need secure access to shared systems without repeated logins.
App SSO and network identity are related, not identical
A common point of confusion for readers is that SSO for applications and identity-based network access are connected ideas, but they are not the same mechanism.
App SSO usually means the user authenticates once with an IdP and receives a token or session accepted by connected applications. Network access often uses different controls, such as device certificates, wireless authentication methods, directory-backed policy, and posture or trust checks.
What links them is the identity source. If Entra ID or Okta already knows who the user is, what group they belong to, and whether their device is managed, you can use that identity context to decide whether they should join the staff network.
What this looks like on corporate WiFi
In a mature design, staff don't type a shared WiFi password at all. Their organisation-managed device is enrolled, trusted, and associated with their identity. When they enter the building, the device connects to the appropriate secure SSID using certificate-based or equivalent enterprise authentication.
That changes a lot operationally:
- Shared passwords disappear, so one leaked credential doesn't affect the whole workforce network.
- Access becomes role-aware, because policy can follow identity groups.
- Revocation gets faster, because when directory access changes, network access can change with it.
- Roaming gets easier, especially across multi-site estates where users expect the same experience everywhere.
Why this matters in hospitality, retail, and healthcare
These sectors are full of edge cases. You have shift workers, shared devices, agency staff, roaming teams, and a constant mix of corporate, semi-corporate, and guest access needs.
A hotel group may want one staff identity to govern PMS access, back-office apps, and secure internal WiFi across properties. A retail chain may want managed handhelds to connect automatically to store WiFi while guest traffic stays isolated. A healthcare provider may want stronger separation between clinical users, visitors, and connected devices.
This is also where network access control solutions enter the discussion. They help extend identity policy from the application layer into the network layer.
Where Purple fits
One practical option is Purple, which supports identity-based networking for staff and multi-tenant environments, including integrations with Entra ID, Google Workspace, and Okta for secure access without relying on shared passwords. That kind of approach is useful when you want app identity and network identity to work from the same source of truth.
SSO in Your Industry Practical Use Cases
The easiest way to see the value of SSO is to look at daily work, not architecture diagrams.
Hospitality
A hotel operations manager starts the day at one property and finishes it at another. They need access to scheduling, a property management system, shared documents, and internal WiFi in both locations.
With SSO, that identity follows them. They sign in once, and approved systems recognise that session. If the organisation also ties network access to the same identity source, their managed device joins staff WiFi without someone texting the latest password to the duty manager.
Retail
A regional manager walks into a store carrying a tablet. They need sales dashboards, stock tools, and internal communication apps straight away.
In a fragmented setup, each stop can mean another login prompt, another expired password, or another call to support. In an identity-led model, the tablet authenticates cleanly, access reflects the user's role, and store staff don't have to share local credentials to get work done.
Good SSO doesn't make access invisible. It makes legitimate access predictable.
Healthcare
A clinician starts a shift and needs fast, controlled access to core systems. They may move between workstations, shared devices, and restricted network segments during the day.
Here, SSO helps reduce repeated sign-ins to approved applications, while identity-based network controls help ensure the right users and devices connect to the right wireless environments. That separation matters. Clinical access, guest access, and device access shouldn't all be governed the same way.
Multi-tenant properties and campuses
In student housing, business centres, and mixed-use properties, staff and residents often coexist on the same physical infrastructure but should never share the same access model.
Staff may need building systems, support tools, and internal administration apps. Residents or tenants need reliable connectivity, but not access to operational platforms. In this context, identity design matters most. SSO can support workforce access, while separate network identity policies keep tenant and guest traffic isolated.
SSO Implementation and Best Practices
A successful SSO project starts with one decision: choose the identity provider that will act as your control plane. For many organisations that's Microsoft Entra ID or Okta, because those platforms already sit close to user lifecycle, MFA, and device policy.
Rollout should be phased. Start with the applications that matter most and the user groups most likely to benefit. Clean up duplicate accounts, define role groups properly, and test session behaviour before you widen scope.
The controls that matter most
A few practices make the difference between a neat demo and a durable deployment:
- Require MFA at the primary sign-in point. If one login can provide access to many resources, that login needs stronger protection.
- Build leaver processes around immediate revocation. Central identity only helps if account changes flow through quickly.
- Review access by role. SSO can make over-entitlement easier to miss if nobody checks who still has access.
- Plan for IdP disruption. Know what happens if your identity service is unavailable and which systems need fallback handling.
Know when SSO isn't the right tool
This point gets missed in many generic explainers. OneLogin notes a growing distinction between workforce SSO and guest or device access in real-world deployments, and asks a useful buyer question in its explanation of how single sign-on works : when is SSO the wrong tool, and when should identity be applied to network access instead of app login?
That matters in WiFi design. Staff should often use identity-linked, policy-driven access. Guests usually need something lighter, simpler, and separate. Trying to force every access problem through workforce SSO creates friction where it isn't needed.
If you're reviewing SSO as part of a wider access strategy, include apps, staff WiFi, guest onboarding, shared devices, and revocation workflows in the same conversation. That's usually where the biggest operational gains appear.
If you're rethinking access across apps, staff WiFi, guest onboarding, or multi-tenant networks, Purple is worth a look. It provides identity-based networking that can work with platforms such as Entra ID, Okta, and Google Workspace, helping teams replace shared passwords and clunky captive portals with controlled access for staff, guests, and residents.
