How to Get Single Sign-On for Business Apps Right
Letting people sign in to an application with their existing work identity, usually through SAML or OpenID Connect.
Marcus Adeyemi
What is at stake
Business customers expect single sign-on, and it centralizes access control when employees join or leave.
The playbook
- Support a standard protocol rather than custom integrations
- Test with more than one identity provider
- Handle account linking for existing users
- Plan deprovisioning as well as sign-in
- Document setup steps for customer administrators
Where it goes wrong
Avoid:
- Custom authentication integrations per customer
- Sign-in without a deprovisioning path
- Assuming one identity provider's behavior is standard
- Ignoring account linking conflicts
The numbers behind it
| Measure | Figure |
|---|---|
| Protocols | SAML and OpenID Connect are the common standards |
| Identity providers | organizations use providers such as corporate directories |
| Just-in-time provisioning | creates accounts on first sign-in |
| Deprovisioning | removing access when people leave is the main security benefit |
Getting outside help
When to hand it over: Bring in help when selling software to larger organizations.
Where this comes from
- OWASP — Authentication Cheat Sheet
- Microsoft Learn — Single sign-on
The figures and practices above come from the sources listed.
Working on something like this?
We take on Web Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
