Single sign-on (SSO)

The applications that trust it are called service providers or, in OpenID terminology, relying parties.

For users this means: one log-in in the morning, then access to email, time recording, the ERP system and the shop back end. For IT and management it means: one place where accounts are created, secured and blocked when someone leaves. It is precisely this central control that is the real benefit in a business environment, not the saved password entry.

How single sign-on works

The basic principle is the same for all common procedures. If a user calls up an application without being logged in, it redirects them to the identity provider. The IdP verifies the identity, for example by password and second factor, and sends a signed confirmation back to the application. The application trusts the signature, creates its own session and lets the user in. With the next service, the IdP recognises the existing session and issues the confirmation without the user having to enter anything again.

The application never sees the user's password. It only receives a statement from the identity provider about who has logged in, often together with attributes such as email address, name, department or group membership. This is a gain in security, because credentials are only held in one place and can be protected professionally there.

The most important protocols

SAML 2.0 is the classic in the business sector. The identity provider issues a digitally signed XML assertion and passes it to the application via the browser. The procedure is mature and widespread but seems heavyweight by comparison, because XML signatures and metadata exchange require care.

OpenID Connect is an identity layer on top of OAuth 2.0. OAuth 2.0 itself (RFC 6749) governs authorisation, i.e. delegated access to resources. OIDC therefore adds an ID token in JWT format that states who the user is. For web applications, the authorisation code flow is usual, and for public clients such as apps and single-page applications it is combined with PKCE. OIDC is considered easier to implement than SAML and has largely become established for new projects.

Distinction: SSO, authentication, authorisation

Three terms are frequently mixed up in everyday use. Authentication clarifies who someone is. Authorisation clarifies what this person may do. Single sign-on is a procedure with which authentication can be bundled for several applications. SSO says nothing yet about what rights the user has in the respective application. This assignment is usually handled by a role-based permission model that maps groups or roles from the identity provider to application rights.

SSO must also be distinguished from a password manager. A password manager stores many sets of credentials and fills them in, but the applications still check their own passwords. With genuine SSO, there is only one log-in, and the applications no longer know any password. Social login ("Sign in with Google") is also technically an SSO procedure, usually via OIDC, with the difference that the identity provider is a consumer service and not a company directory.

Why SSO is relevant in companies and in e-commerce

An online retailer or manufacturer typically works with a dozen systems: shop back end, ERP, PIM, CRM, ticket system, analytics, email marketing, payment provider portal. Without a central log-in, each system maintains its own accounts with their own passwords. This creates predictable problems.

• Offboarding gaps: if someone leaves the company, twelve accounts have to be blocked individually. Forgotten accounts remain open as a gateway.
• Password fatigue: anyone who needs twelve passwords chooses weak ones or reuses them. The result is credential stuffing attacks, in which stolen credentials from one service are tried out on others.
• Inconsistent security: not every application offers multi-factor authentication. With SSO, the second factor is enforced once at the identity provider and applies to everything behind it.
• Lack of traceability: log-ins at a central point can be logged and evaluated instead of disappearing into twelve separate logs.
• Support effort: password resets are among the most frequent helpdesk requests. A central log-in reduces them.

This is also relevant for regulation and certification. Requirements from ISO/IEC 27001, from the NIS2 Directive or from customer audits essentially come down to demonstrable access control. An identity provider with enforced multi-factor authentication and central blocking provides the evidence for this in a form that auditors can follow.

SSO in the shop back end

Commerce back ends have to fit into this picture. Anyone introducing a shop system in a mid-sized company usually raises the question of company log-in in the requirements specification: do employees log in with their company account? Is the account blocked automatically when they leave? Can groups from the directory service be mapped to roles in the shop?

The answers differ greatly between platforms. With some, SSO is part of the standard installation or available via extensions; with others, only in commercial editions. A current example is MedusaJS: according to the ENTERPRISE-LICENSE.md in the repository, the connection to corporate identity management via the OIDC auth provider has fallen under the enterprise licence since August 2026, while generic authentication and normal user management remain under MIT. You can find the context in the entry on MedusaJS and in the entry on the open-core model.

An example: log-in via OpenID Connect

A typical OIDC flow with the authorisation code flow can be described in a few steps:

1. The user calls up the shop back end. There is no session.
2. The back end redirects the browser to the identity provider, for example Microsoft Entra ID, Okta or Keycloak, and passes the client ID, redirect URI, scopes such as openid and email and a random value to protect against manipulation.
3. The identity provider authenticates the user, with a second factor if required.
4. It redirects the browser back to the back end with a one-time authorisation code.
5. The back end exchanges the code directly server-to-server for an ID token and an access token.
6. It checks the signature of the ID token, reads claims such as email or groups and creates its own session.

Step 5 is important: the code is exchanged between the server and the identity provider, not in the browser. This keeps the tokens out of reach of scripts in the browser. The widespread identity providers are Microsoft Entra ID (formerly Azure Active Directory), Okta, Keycloak as an open-source solution, Google Workspace and Auth0.

Groups and attributes: what the identity provider supplies

In addition to the pure identity, the token or assertion transports so-called claims or attributes. These include the email address as a unique identifier, the display name and often a list of groups. In practice, the quality of this mapping decides whether SSO works in everyday use. If the "Sales" group in the directory is mapped to the "Price management" role in the shop, new employees automatically get the appropriate rights the first time they log in. If the mapping remains unclear, all users land in the system with standard rights and have to be authorised manually afterwards, which cancels out the advantage of central control.

Two rules have proven themselves here. First, the unique key of an account should be a stable identifier and not an email address, which can change, for example on a change of name or a move to another domain. Second, the application should re-evaluate group memberships with every log-in and not store them once when the account is created, so that changes in the directory take effect promptly.

Risks and limits

Single point of failure. If the identity provider fails, nobody can get into the connected applications any more. Availability and emergency access (break-glass accounts) must therefore be planned deliberately.

Greater damage in the event of compromise. A stolen account potentially opens all connected systems. That is why SSO without multi-factor authentication makes little sense. The gain in convenience must not come at the expense of security.

Misconfigured trust relationships. Typical mistakes are redirect URIs that are too broad, unchecked signatures or missing validation of audience and issuer in the token. Such configuration errors are among the most common causes of security gaps in SSO integrations.

End of session is not the same as logging out. If a user logs out of one application, their session at the identity provider often remains. Complete single logout is technically demanding and is not reliably supported by all applications.

Licence costs. SSO features are often treated as a premium feature in software. This is so widespread that the term "SSO tax" has become established for the surcharge that vendors charge for company log-in. Anyone buying software should clarify this point before deciding.

Provisioning accounts: SCIM

SSO governs log-in, not the creation and deletion of accounts. For this part there is the SCIM standard (System for Cross-domain Identity Management, RFC 7643 and 7644). With it, an identity provider can automatically create, change and deactivate user accounts in connected applications. Only the combination of SSO and SCIM really solves the offboarding problem: if the account is deactivated in the directory, access disappears everywhere without anyone having to go through applications one by one.

Outlook

Passwords are losing importance. Passkeys based on FIDO2 and WebAuthn replace passwords with cryptographic key pairs managed by the user's device. Identity providers increasingly support them as a log-in method, so that SSO and passwordless authentication are growing together. At the same time, verification is moving from a one-off log-in to an ongoing assessment of device, location and behaviour, as provided for by zero-trust architectures. For applications, this means that a log-in no longer counts as a permanent free pass.

For mid-sized companies, the practical rule remains simple: as soon as more than a handful of applications and more than a handful of users come together, a central identity provider saves more effort than it costs, and it improves security measurably.

Frequently asked questions about single sign-on

What is the difference between SSO, SAML and OIDC?

SSO is the goal: one log-in for several applications. SAML and OpenID Connect are protocols with which this goal is implemented technically. SAML is based on XML and is widespread in business environments; OIDC is based on JSON and OAuth 2.0 and is usual for newer applications.

Is SSO more secure than individual passwords?

As a rule, yes, if the identity provider is well secured and enforces multi-factor authentication. Credentials are held in one place, and blocks take effect everywhere. Without a second factor, however, the risk is concentrated on a single account.

Does a small company need SSO?

With few users and systems, not necessarily. As soon as several departments, external service providers or compliance requirements come into play, introducing it pays off.

Does SSO replace permission management?

No. SSO clarifies who logs in. What the person may do in the application is governed by a separate permission model, usually based on roles.

What is social login?

Social login allows you to log in with an existing account at a large provider such as Google or Apple. Technically, it is an SSO procedure based on OIDC that is used in the consumer business and is not intended for company directories.

Further sources

The OpenID Connect specification is published by the OpenID Foundation. The underlying authorisation standard is described in RFC 6749 (OAuth 2.0). An overview of the concept is given in the Wikipedia article on single sign-on.