Published: Last updated:

Identity and Single Sign-on

One central identity opens and closes every access

Identity and access management consolidates every login onto a single, centrally managed identity. Single sign-on turns that into the one login which opens all connected applications, and a single point at which access can be granted and revoked.

Anyone who does not govern identity centrally scatters it uncontrolled: every system keeps its own accounts, every person memorises their own passwords, and when someone leaves it is unclear which access remains open. This page orders the field from the central identity, through the protocols that carry it, to the decision of whether the identity provider runs in-house or as an external service. The individual providers are each described on their own catalogue page and linked in place.

Anti-Patterns: Scattered identity as an attack surface

  • Password sprawl: Every application demands its own password. What follows is the reuse of weak passwords across system boundaries, and with it the single greatest weakness in access.
  • An account per application: Every system maintains its own user base. One person exists dozens of times over, and no single place knows the sum of their access.
  • No central offboarding: When someone leaves, accounts are deactivated one by one and by hand. Forgotten access stays active and is a classic point of entry.
  • Shared logins: A common account for a team makes every action anonymous. Who did what can no longer be traced.

One identity as the shared basis for all access

Identity and access management separates two questions that, without centralisation, stay inseparably entangled: who are you (authentication) and what may you do (authorisation). The answer to both sits in one place, the identity provider. It holds the identities, checks the login, enforces a second factor and decides which application a person may reach.

Single sign-on is the visible side of this consolidation. Instead of logging in again at every application, a person authenticates once at the identity provider; the connected applications trust its verdict and grant access without ever seeing the password themselves. The gain is threefold: fewer passwords and therefore less attack surface, a single place for strong authentication, and a single switch that closes all access at once when someone leaves. Instant offboarding is the most underrated benefit: a deactivated identity locks every connected application in one step.

Four protocols carry the central identity

The consolidation works only because applications and identity providers speak the same language through vendor-independent protocols. Four of them cover the bulk of practice.

  1. OIDC. OpenID Connect is the modern protocol for web and mobile applications. It builds on the OAuth 2.0 authorisation standard and adds the identity layer. For new connections, OIDC is the default.
  2. SAML. The older, XML-based standard is widespread in the world of classic enterprise and SaaS applications. Many established services speak SAML, which keeps it relevant despite its age.
  3. LDAP. The directory protocol is the backbone for authentication against a central user base, especially for legacy systems and internal services. It supplies the identities on which OIDC and SAML build.
  4. SCIM. Where OIDC and SAML govern the login, SCIM automates provisioning: it creates accounts in connected applications automatically, keeps them current and removes them when someone leaves. Only SCIM makes central offboarding complete across system boundaries.

Self-host against external as the central decision

The identity provider is the heart of the matter, and choosing it is the same fundamental decision as for any critical component: bring it in-house or buy it as a service.

A self-hosted identity provider runs on the organisation's own infrastructure. Authentik and Keycloak are the established open-source representatives. The identities and every login stay within the organisation's own network, the configuration is entirely in-house, and no ongoing dependence on an external provider arises. The price is the organisation's own operating discipline: availability, updating and securing of the identity provider sit within the organisation's remit, and an outage locks the login to every connected application at once.

A SaaS identity provider such as Okta delivers the same function as a managed service. It is quickly available, operations sit with the provider, and availability is contractually assured. In return the identities leave the organisation's own house, control over the heart of access sits with an external provider, and exactly the dependence arises that a sovereign IT seeks to avoid elsewhere. The trade-off thus follows the general make-or-buy question, sharpened to the most sensitive component of access control.

flowchart TD
    SSO["Introduce single sign-on"]
    SSO --> P{"Which protocol for which application"}
    P --> OIDC["OIDC<br/>web and mobile, new connections"]
    P --> SAML["SAML<br/>classic enterprise and SaaS applications"]
    P --> LDAP["LDAP<br/>directory and legacy systems"]
    P --> SCIM["SCIM<br/>provision and revoke accounts automatically"]
    SSO --> H{"Run the identity provider"}
    H --> SELF["Self-hosted<br/>Authentik, Keycloak"]
    H --> SAAS["SaaS<br/>Okta"]
    SELF --> CTRL["data residency and full control<br/>own operations"]
    SAAS --> MAN["quickly available and managed<br/>external dependency"]

The diagram shows the two decisions that every connection carries: which protocol suits the respective application, and which operating model carries the identity provider. Both paths lead to the same central identity; they differ in who runs the provider and where the identities reside.

Identity as the load-bearing element of Zero Trust

When the network perimeter has outlived its use as a line of defence, identity becomes the new boundary. This is exactly the principle Zero Trust turns into an architecture: every access is checked individually, independent of location, and the basis of every check is a reliable, centrally managed identity. Without single sign-on and an identity provider there is no point at which this check can be enforced. Identity and access management is therefore no isolated topic but the control plane on which a security strategy anchors its access decisions.

Practical Example: Leaving in a single day

An employee leaves the company. Without a central identity, every place would have to remember to deactivate her account in each system individually, from the email service through the project tool to the code repository. In practice, one access regularly stays open. With an identity provider, a single step suffices: the central identity is deactivated, and through OIDC and SAML all connected applications immediately lose trust, while SCIM removes the corresponding accounts in the target systems. An error-prone checklist becomes one traceable action.

FAQ

Is a single login not a single point of failure?

The concern is legitimate, but it inverts. A central login means strong authentication need only be enforced in one place, instead of relying on the weakest of dozens of app logins. The identity provider is the right place to make a second factor mandatory. Scattered accounts with reused passwords are the markedly larger attack surface.

Do we need all four protocols?

No. Which protocols come into play is determined by the applications to be connected. New web applications mostly speak OIDC, established enterprise services often SAML, internal legacy systems LDAP. SCIM is added as soon as the automatic provisioning and revocation of accounts is required. A good identity provider masters all four and mediates between them.

Are self-hosted and SaaS mutually exclusive?

Not necessarily. An organisation can secure sensitive internal applications through a self-hosted provider and connect uncritical services to a SaaS provider. What matters is that the choice falls deliberately along the sensitivity of the respective identities, rather than drifting into an external dependency out of convenience.

References

Related topics

  • Zero Trust, the architecture in which identity becomes the new boundary.
  • Security Strategy, the overarching frame in which access control is anchored.
  • Authentik, a self-hostable open-source identity provider.
  • Keycloak, an established open-source identity provider.
  • Okta, an identity provider as a managed SaaS service.
  • Public Code, the strategic basis of the make-or-buy decision on the identity provider.

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.