Single Sign-On (SSO)

Single sign-on (SSO) lets a person sign in once and use several connected apps without a new login for each one. Each person still has their own account. SSO does not mean that staff share a password.

How single sign-on works

In a common setup, an app sends the user to a trusted sign-in service called an identity provider. That service checks who the person is. It sends proof back to the app, which checks that proof and starts a session. Standards such as SAML and OpenID Connect support this exchange.

For example, a clinic might connect its staff website and a records app to the same sign-in service. A nurse can move between those apps with fewer login prompts. The records app must still check which patients and tasks that nurse is allowed to access.

How it differs from MFA and access control

Multi-factor authentication (MFA) checks identity with more than one type of proof. SSO lets connected apps use a common sign-in. They solve different problems and can work together.

Authentication checks who someone is. Access control limits what they can do. Signing in through SSO does not grant access to every record or make an app compliant on its own.

What HIPAA requires

HIPAA does not mention single sign-on. Two rules in the Security Rule still shape how it is set up. Under 45 CFR § 164.312(a)(2)(i), each user needs a unique name or number, so activity can be traced to one person. SSO fits this when every staff member has their own account at the identity provider. Under 45 CFR § 164.312(d), the system must verify that a person seeking access is who they claim to be. The identity provider does that check for every connected app, so its own sign-in policy, including MFA, carries the weight for all of them. Write the identity provider into your risk analysis as a system that controls access to ePHI, and confirm whether the provider needs a business associate agreement.

What healthcare teams should check

• Keep accounts separate. Give each staff member a unique account and only the app access their role needs.
• Protect the sign-in service. Use MFA and review sign-in activity. A stolen session can put more than one connected app at risk.
• Test staff removal. Check how disabling an account affects connected apps and sessions that are already open. App sessions can end at different times.
• Set session limits. Check each app's timeout and logout behavior. SSO does not replace an automatic logoff policy.

Where this comes up

Our Payload CMS guide and Strapi guide discuss SSO as part of staff access planning. Confirm the app's supported sign-in method and plan before choosing an integration.

Sources: Microsoft's SSO overview, NIST SP 800-63C federation guidance, and 45 CFR § 164.312.