One Login, and Why It Matters More Than It Sounds

Single sign-on is usually sold on convenience: fewer passwords, less friction, fewer support requests about forgotten credentials. All true, and all minor compared with what it actually changes.

The significant effects are structural, and they are about what becomes possible rather than what becomes easier.

Effect one: leaving becomes a single action

In a business with a dozen separate systems, removing someone's access is a dozen tasks performed from memory. Nobody has the complete list. The systems adopted recently are remembered; the one used twice a year is not.

The result is that former staff retain access to something, almost always, and nobody discovers it because nothing about the situation generates an alert. It is found later, during an unrelated review, or not at all.

With one identity behind the tools, offboarding becomes a single revocation. This is the strongest argument for consolidating logins and it is rarely the one made, because it concerns a moment nobody is thinking about during a purchase.

Effect two: the audit trail becomes possible

Attributing actions to people requires people to be distinguishable, and separate credentials per system make that unreliable in a specific way: the same human is a different identity in each place, and correlating them is manual.

When the identity is shared across systems, a question like "what did this person do last Thursday" becomes answerable across all of them rather than within one. That is the difference between an audit trail and a set of unrelated logs.

Effect three: security effort concentrates where it works

Protecting a dozen separate credentials means a dozen places to enforce a second factor, a dozen password policies, and a dozen opportunities for one weak link.

With one identity, effort concentrates. A second factor on that identity protects everything behind it. Detecting an unusual sign-in becomes one problem rather than twelve, and most businesses can only really solve it once.

This is also where a common piece of received wisdom should be dropped. Current guidance is explicit that verifiers "SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)" while stating equally plainly that they "SHALL force a change if there is evidence of compromise of the authenticator" [2]. Scheduled rotation across many systems is an enormous amount of effort producing weaker passwords. One strong credential, a second factor, and the ability to force a change immediately when something happens is both less work and more protection.

How the "sign in with" buttons actually work

The mechanism behind most of this is delegated authorisation, designed so an application can "obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf" [1].

Two words in that are worth dwelling on.

Limited. The access has a defined scope. A well-built integration asks for the narrowest thing that does its job. A poorly-built one asks for everything available because it was simpler, and the permission screen is where a proportion of users stop.

On behalf of. The application is acting as you, with your permission, which can be withdrawn. That is the property that makes this better than sharing a password: revocation does not require changing anything for anyone else.

The corresponding responsibility, for anyone building or configuring these, is to ask for as little as the task requires. It is the access equivalent of not collecting data speculatively "in case it is useful later" [3], and the reasoning is identical — a permission held without a current use is a liability with no return.

The risks, stated plainly

One credential is one target. A compromised central identity is worse than one compromised account among twelve. This is a real trade-off and the mitigation is not subtle: a second factor is not optional on an identity that opens everything.

Availability becomes concentrated. If the identity provider is unreachable, everything behind it is too. Worth knowing the recovery path before it is needed, particularly for whoever administers it.

Convenience obscures scope. Because signing in is one click, people click. The permissions being granted get less scrutiny than they would if the process were more effortful, and applications accumulate access nobody reviews.

The accounts that are not people

One category sits outside all of this and causes a disproportionate share of trouble: the accounts that do not belong to a person.

Every business accumulates them. The address that receives invoices. The account that owns the domain registration. The login for the payment provider, created by whoever set it up years ago. The identity an automation runs under.

These are frequently tied to one individual's personal credential, or to a shared mailbox with a password several people know, and they sit outside whatever identity arrangement covers the staff. When the person who created them leaves, or the shared password is changed by someone unaware of what depends on it, things break in ways that are difficult to diagnose because nobody knew the dependency existed.

The remedy is to inventory them and give each one a named human owner — not a shared owner, a specific person responsible for knowing what it is for and what depends on it. Where the platform supports it, they should sit behind the same identity and second factor as everything else.

It is an unglamorous afternoon. It also prevents the specific failure where a business cannot renew its own domain because the only address that receives the reminder belonged to somebody who left two years ago.

A reasonable position

Consolidate identity where you can, put a strong second factor on it, and stop rotating passwords on a schedule. Review connected applications occasionally and remove what is not in use. Keep a written recovery path for the identity itself, held by more than one person.

None of that is a project. It is an afternoon, and it removes the single most common gap in small-business security, which is not a sophisticated attack but a former colleague who still has a key nobody remembered to take back.