The account nobody remembers to close is the argument for single sign-on.
A salesman leaves on a Friday. His email is shut the same day, because everybody remembers email. The CRM, the dealer portal, the reporting dashboard and the messaging tool each keep their own login, and each is somebody else’s job to remember.
Single sign-on turns five jobs into one. That is the real reason to do it, far more than the convenience of typing one password fewer.
Single sign-on means your applications stop keeping their own list of who works here. They ask one identity provider instead, usually Google Workspace or Microsoft 365, the same account people already open their email with. Closing that account closes every application at once, and the applications themselves never see the password.
Where it earns its place.
What it actually fixes
- One account created when somebody joins, rather than five
- One account closed when they leave, the same afternoon
- The password policy and second factor set in a single place
- A record of who signed in to what, kept in one place
- Contractors given access that runs out on a date
How it is wired in
The application trusts the identity provider to say who the person is. It still decides for itself what they may do.
- OpenID Connect against Google Workspace, Microsoft Entra or Okta
- SAML where an older enterprise system asks for it
- A first sign-in that creates the person in your system with no rights yet
- Directory groups mapped to roles inside the application
- A small number of local administrator accounts for the day the provider is unreachable
Identity and permission are two separate questions. The provider answers who this is. Your application still has to answer what they may see.
Where the argument usually happens
Not in the wiring, which is routine work. In agreeing what a directory group should mean inside the application.
- Whether a branch manager sees the other branches
- Who may approve a discount, and above what figure
- What a contractor sees, and until when
- Whether the owner’s login is treated differently from the administrator’s
- What happens to somebody who moves between departments
This takes longer than the technical work, every time, because it describes how the business is really run rather than how the chart is drawn. The meetings are worth having properly.
Customers are a different problem
Staff sign-on and customer sign-in look alike and are not the same decision.
- Staff, through the company directory, closed on the day they leave
- Customers, through Google or Apple, or a plain email and password
- Dealers and vendors, who belong to neither and need their own arrangement
Putting customers into your staff directory looks tidy on the diagram and creates a problem later. We keep the two apart.
What this does not do
- Certify you against any standard, since we are not a certification body
- Audit your identity provider on your behalf
- Make an application secure on its own
- Decide who in your business may see what
Single sign-on is one control, and a good one. The duty for who holds access to what stays with your business, and the system should make that duty easy to meet rather than harder.
When this is the right choice.
- You already pay for Google Workspace or Microsoft 365
- Staff sign in to three or more separate applications
- People join and leave often enough that closing accounts is a real task
- You want a second factor everywhere without setting it up in each system
- Somebody has asked you who has access to what, and the answer took a week
When it is not.
- A dozen people and no company directory, where you would be buying a subscription to solve a list you could keep on paper
- A customer-facing application, where signing in with Google or Apple is a different and much smaller piece of work
- A first release that is already late, because sign-on can be added afterwards without a rebuild
- An organisation that has not decided who may see what, because single sign-on will not decide it for you
Questions we are asked about it.
Do we need Google Workspace or Microsoft 365 for this?
One of them, or another identity provider such as Okta. If your staff sign in with personal Gmail addresses there is nothing central to sign in against, and the honest first step is fixing that rather than buying sign-on.
Does single sign-on make us compliant?
No. It is a control that helps with a common requirement, and it is evidence you can put in front of somebody. Whether you meet any particular standard is judged by an assessor, and that duty remains yours rather than moving to us.
What happens if Google is down?
Nobody signs in, which is the trade you are accepting. We keep a few local administrator accounts behind a second factor, so the system can still be reached during that hour.
Is this the same as role-based access?
No, and the two are often confused. Sign-on answers who you are. Role-based access answers what you may do once you are inside, and that is the part that takes longest to agree.
Can we add a second factor?
Yes, and with single sign-on you set it once in the identity provider instead of in every application separately. That is usually the argument that finally convinces people.
How long does it take to add to a system we already run?
The wiring is a known quantity. What moves the date is deciding what each group of people may see, which is a conversation with you rather than a task for us.
Services that use it.
What it sits with.
Not sure Single sign-on is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private