Single sign-on

The control it provides#

The most common access-control failure in any organisation is a leaver who still has access to a system nobody remembered to update. Single sign-on removes the possibility: authentication depends on the directory account, so disabling the account disables access everywhere at once.

That is a stronger argument than the convenience of one fewer password, and it is the one worth making to a security team.

Group-to-role mapping#

With OIDC, group membership can be carried in the token and mapped to application roles, so access rights follow directory membership. Adding someone to a group grants their access; removing them revokes it at their next sign-in.

The practical caveat is timing: roles are evaluated from the token, so a role change applies at next sign-in rather than immediately. For urgent revocation, disable the account rather than changing groups.

What it does not solve#

Provisioning. Single sign-on governs authentication, not account creation, so a new starter may still need an account created before they can sign in. SCIM addresses that separately, and large tenants usually expect both.

It also does not reduce the need for role design. Mapping groups to badly designed roles produces badly designed access, faster — and at greater scale, because the mapping applies to everyone at once rather than to whoever an administrator remembered to update.