Guides · Data and access

Single sign-on: one login, and one place to take it away

Every internal tool with its own password is a list of people somebody has to remember to update. Single sign-on replaces all of those lists with the one you already keep.

7 min readUpdated 5 October 2026Softeria, Ålesund

The short version

Single sign-on means the tool holds no password. It asks your company directory who the person is, and believes the answer.
The real benefit is not convenience. It is that switching off one account in one place ends access everywhere.
Let the groups you already maintain decide who reaches what, so there is no second list of people to keep in step with the first.
Ask before you buy: which standard, whether password login can be turned off, how long a session outlives the account, and whether single sign-on costs extra.

Count the internal tools in your organisation that have their own login screen: the booking system, the supplier register, the form a department built, the reporting tool somebody bought on a card. Each one keeps its own list of users and its own passwords, and each of those lists has to be updated by hand every time somebody joins, changes role or leaves.

Most of those lists are wrong right now. Not badly wrong, just slightly: a contractor from last spring, a colleague who moved to another department and kept what they had. Single sign-on is the way to stop keeping the lists at all.

What single sign-on actually is

With single sign-on, the tool never sees a password. When someone opens it, they are sent to the company’s identity provider — Microsoft Entra ID, Google, Okta or similar — which checks who they are in whatever way the company has decided, and sends them back with a signed statement: this is Kari, she is in these groups. The tool trusts that statement and lets her in.

Two standards do almost all of this work. OpenID Connect is the newer one and what most modern tools use; SAML is older and still common in large enterprise software. Either is fine. What matters is that it is one of them, rather than something a vendor invented.

It is not a password manager. A password manager remembers many passwords for you. Single sign-on means there is only one, and only your directory holds it.
It is not “the same password everywhere”. Syncing one password into ten systems puts ten copies of it in ten places. Single sign-on puts it in none of them.
It is not a personal “Sign in with Google”. A private Gmail account signing in to a work tool is still a personal account. It has to be the company’s directory, or the company cannot switch it off.

What separate passwords cost

The case for single sign-on is usually made as convenience — one login instead of twelve — and convenience is the weakest part of it. The costs of separate passwords are elsewhere.

Leavers keep access. Offboarding switches off the company account. It does not reach the tool with its own user list, unless somebody remembers that tool exists and has the rights to change it.
Your security rules stop at the door. Two-factor sign-in, blocked countries, managed devices only — whatever your directory enforces, a tool with its own password skips all of it.
Passwords get reused. People do not invent a strong new password for the canteen booking system. They use one they already have, which is now only as safe as the least careful site they used it on.
Nobody can say who has access. When an auditor or a customer asks who can reach a system, the answer is spread across a dozen admin screens, and some of them belong to people who have left.

The day someone leaves

This is the moment single sign-on is really for. Disable one account in the directory, and the next time that person tries to open any connected tool, the identity provider says no. There is no list to work through, so there is nothing on it to forget.

It is worth being precise about the gaps, because there are some, and they are where the checking should go.

Sessions already open. A person who signed in this morning may stay signed in until their session runs out, even after the account is disabled. Find out how long that is in each tool — minutes and hours are fine, weeks are not.
Logins that go round the side. Many tools keep a password login alongside single sign-on, for the first administrator or out of habit. An account created there is outside your directory and survives everything above.
Keys and tokens. Integration keys and personal access tokens are often created by a person and outlive them. They should belong to a service, with a named owner, not to whoever set it up.

Groups, not lists

Single sign-on answers “who is this”. The next question is “what may they do”, and the tempting answer is to give each tool its own list again: Kari is an editor here, an administrator there. That rebuilds the problem single sign-on just removed.

The better pattern is to let the groups you already maintain decide. The finance group can approve invoices; the warehouse group can register deliveries. When Kari moves from finance to the warehouse, somebody changes her groups in the directory — which they were going to do anyway — and every tool follows without being touched.

Groups decide which doors a person may open. They do not decide which records are theirs once inside: that is a separate question, answered at the data, and the guide on row-level security covers it.

What to ask before a tool gets users

These are the questions worth asking of any tool, bought or built, before anybody is allowed to sign in to it. Each has a short answer if the vendor has thought about it.

Which standard? OpenID Connect or SAML, and does it work with the identity provider you actually run? “We support Microsoft” is not an answer until you know which part of Microsoft.
Is it included? Single sign-on is often kept for the most expensive plan. Find out before the pilot, not at renewal, because the cheap plan with separate passwords is the one people will quietly keep using.
Can password login be switched off? If it cannot, single sign-on is an option, not a rule, and the side door stays open.
Are groups read at sign-in? Does access follow the groups in your directory as they are today, or are they copied once and left to drift?
How long does a session outlive the account? The honest number, and whether an administrator can end a session early.
Where are sign-ins recorded? Your identity provider records that someone signed in. The tool should record what they did once they had — and you should be able to read it.

How this works on our platform

Since you may be reading this on the site of a company that sells a platform: what gets built with Softeria signs people in with the accounts they already have — Microsoft Entra ID, Google Cloud Identity, or any standards-compliant OpenID Connect provider, such as Okta, Auth0 or Keycloak. We issue no new passwords, the groups you already maintain decide who reaches what, and when someone leaves your directory their access ends.

The part worth keeping whatever you use: a tool that keeps its own list of people is a tool somebody will forget on the day it matters. Make the directory the only list, and offboarding becomes one step instead of a hunt.