Integration & TechLast reviewed: 2026-07-30

Single Sign-On (SSO)

Single Sign-On (SSO) is an authentication method that lets a user log in once at a central point and then access multiple applications without re-entering a password. In an ERP context this means one identity for the ERP, shop, accounting and other systems instead of many separate logins.

Single Sign-On (SSO) is an authentication method in which a user logs in only once at a central point and can then access all connected applications without having to identify themselves again with a username and password. Instead of maintaining separate credentials for the ERP, online shop, accounting, email and project tools, a central identity service manages the login and confirms to the other systems that the user has already been verified.

The practical core of SSO is the separation of login and application: not every individual program checks the password, but a so-called identity provider handles this task for all of them. The business applications – in an ERP context, for example, the inventory management system or the connected shop system – trust the verdict of this service. This reduces the number of passwords an employee has to remember to exactly one, while IT manages access from a single place.

At a glance

  • Log in once centrally, then access many systems without logging in again
  • An identity provider (IdP) authenticates, the applications (service providers) trust it
  • Common standards: SAML 2.0, OAuth 2.0 and OpenID Connect
  • Fewer passwords, fewer password resets, centralised rights and access control
  • A security gain only with strong protection of the central login (e.g. MFA)

How Single Sign-On works

SSO is based on a trust relationship between two roles. The identity provider (IdP) is the central service that verifies and manages a user’s identity – for example a corporate directory service or a cloud login. The service provider (SP) is the actual application the user wants to use, such as the ERP or the shop. The service provider does not check the password itself but relies on the identity provider’s confirmation.

When a user calls up a protected application without already being logged in, the application redirects them to the identity provider. There they log in once. The identity provider then issues a digitally signed proof – a token or an assertion – that certifies: “This user has been verified, their name is X and they are allowed to do Y.” The application checks the signature, trusts the proof and grants access. For every further connected application this silent exchange repeats, without the user typing their password again.

The key protocols: SAML, OAuth and OpenID Connect

So that identity providers and applications work together across vendors, open standards are used. SAML 2.0 (Security Assertion Markup Language) is an established, XML-based standard used above all in the enterprise environment to exchange login confirmations. OAuth 2.0 actually governs authorisation, that is, the question of which access an application receives on the user’s behalf. OpenID Connect adds an identity layer on top of OAuth 2.0 and complements it with authentication – today it is the common standard for web- and cloud-based logins. Which protocol fits depends on the identity provider and the systems to be connected.

Why Single Sign-On matters: benefits and limits

The most obvious advantage is convenience: an employee remembers one strong password instead of many weak ones and is spared repeated logins throughout the working day. For IT, most password resets – among the most common tickets in many support departments – disappear. Above all, though, SSO creates central control: when an employee leaves the company, a single action in the identity provider blocks all access at once – a considerable security and compliance gain over scattered individual logins that are easily overlooked.

SSO does, however, have a dangerous flip side: if the central account is compromised, the attacker potentially has the entire system landscape open to them. The central login thus becomes the preferred target. That is why SSO is considered a security gain only when the central login itself is strongly protected – usually through multi-factor authentication (MFA), where in addition to the password a second factor such as a one-time code or an app confirmation is required. SSO without MFA merely shifts risk instead of reducing it.

Single Sign-On in the ERP system

An ERP rarely stands alone: around the inventory management system cluster the shop, PIM, accounting, CRM and other tools. It is precisely in this system landscape that SSO shows its value. By connecting the ERP to the central identity provider via SAML or OpenID Connect, the team works with a single identity across all applications. Roles and rights can be assigned centrally, and new employees receive the right access to multiple systems together with a single account.

Many cloud ERP systems and SaaS solutions support SSO out of the box from certain plans onwards, while on-premise or older systems sometimes require additional configuration or middleware. With multi-tenant systems it must also be clarified how identities remain separated per tenant. Technically related, but not identical, is the connection via an API or REST API: this governs the machine-to-machine data exchange between systems, while SSO concerns the login of human users. In practice, both complement each other within a clean integration.

Distinction: SSO, password manager and federation

Single Sign-On is often confused with a password manager, yet the two solve the problem differently. A password manager still stores a separate password for each application and merely fills it in automatically for convenience – the multitude of credentials remains. With true SSO, by contrast, only a single login exists, and the business applications no longer know a separate password at all but trust the central proof.

Another term is federation (federated identity). It describes SSO across organisational boundaries: a user logs in with the identity provider of their own company and still gains access to the application of a partner or cloud provider, because both organisations have agreed a trust relationship. Classic SSO works within one organisation, federation extends the same principle to several – technically both rely on the same standards as SAML or OpenID Connect.

SSO and the GDPR: data protection in the DACH region

Because SSO centrally bundles personal login data and often runs via cloud services, data protection must be considered early. If you use an external identity provider whose servers are located outside the EU, the GDPR requirements for processing on behalf and for third-country transfers apply. What needs to be clarified is a data processing agreement, the server location and the question of which user attributes are transferred to the connected applications at all – the principle of data minimisation applies here.

In everyday operations, it is advisable to transmit only the attributes that are actually needed (such as name, role, identifier) and to log login processes in an audit-proof way, so that in the event of an audit you can prove who had access and when. For regulated industries and public bodies in the DACH region, the BSI recommendations provide practical guidance on how to operate central authentication securely. This way SSO becomes not only more convenient but also compliant with data protection.

Example

Example: an onboarding day at a trading company

A mid-sized online retailer employs 60 people who, depending on their role, use the ERP, shop backend, accounting and a CRM. Previously, IT had to create four to five accounts by hand for each new person – and deactivate just as many again when they left, with one access regularly being overlooked.

Since the introduction of SSO, everything runs through a central identity provider. On the first working day, IT creates exactly one account, assigns the “customer service” role, and the new colleague immediately reaches all the systems approved for her – secured with an app-based two-factor confirmation. When someone resigns, a single click deactivates all access at the same time. Support tickets for forgotten passwords have noticeably declined.

Frequently asked questions

A password manager still stores a separate password for each application and merely fills it in automatically. With Single Sign-On, by contrast, only a single central login exists, and the business applications trust a shared proof instead of demanding their own passwords.
Only if the central login is strongly protected. SSO reduces the number of weak passwords and makes it possible to block all access in one go. But if that one account is compromised, many systems are exposed – which is why multi-factor authentication is practically mandatory.
SAML 2.0, OAuth 2.0 and OpenID Connect are common. SAML is established in the enterprise environment, OpenID Connect has become the standard for web- and cloud-based logins. Which protocol fits depends on the identity provider and the systems to be connected.
No. Many cloud and SaaS ERP systems offer SSO out of the box from certain plans onwards, while older or on-premise systems often require additional configuration or middleware. Before making a choice, you should check which protocols the system supports.

Matching ERP systems

Related services

Sources

Questions about Single Sign-On (SSO) in your ERP project?

We advise vendor-neutrally – and implement it ourselves on request.

Free consultation