Häufig gestellte Fragen
What is single sign-on (SSO) in simple terms?
Single sign-on is an authentication method in which a user logs in once centrally and can then access multiple connected applications without re-entering a password. Instead of maintaining separate credentials for ERP, CRM, e-mail and the document archive, a central identity service verifies the identity once and issues a signed proof of it to the connected services. The individual applications trust this confirmation, so that ideally the password exists in only one place. SSO is not a single product but an architectural principle built on established standard protocols.
How do SAML, OAuth 2.0 and OpenID Connect differ?
The three standards serve different purposes and are often used in parallel in mature environments. SAML 2.0 is an established, XML-based method that is widespread above all in classic corporate and regulated environments for authentication and SSO. OAuth 2.0, by contrast, is a framework for authorisation, i.e. for granting access rights to resources, and is not primarily intended for identity verification. OpenID Connect (OIDC) builds on OAuth 2.0, adds an authentication layer with JSON-based tokens (JWT) and is considered the more modern variant, better suited to web, mobile and API applications.
Is SSO worthwhile for the mid-market?
With a growing number of cloud applications, SSO is becoming increasingly relevant for mid-sized businesses as well, often from a mid-double-digit number of users and several services used in parallel. Advantages include simplified onboarding and offboarding, less effort for password resets in IT support and centrally controllable, audit-proof management of access. In addition, regulatory requirements such as the BSI IT-Grundschutz or the NIS 2 Directive are tightening the demands on authentication and access control. Whether and from what size an introduction actually pays off depends on the number of systems, the IT resources and the compliance obligations of the individual company.
How secure is SSO and why should it be combined with MFA?
SSO is fundamentally only as secure as the central identity service where the login takes place. Since a single login opens access to all connected applications, a stolen password without further safeguards would endanger all systems. For this reason, combining SSO with multi-factor authentication (MFA) is considered best practice, adding a second factor to the single login. The German implementation of the NIS 2 Directive (NIS2UmsuCG), which came into force on 6 December 2025, explicitly names multi-factor authentication or continuous authentication as one of the mandatory risk management measures for affected entities.
What happens with SSO if the identity provider fails?
Because SSO concentrates login at one central point, it creates a so-called single point of failure: if the identity service goes down, employees may no longer be able to reach any of the connected applications. Documented outages at major providers have shown that such an interruption can paralyse numerous business processes simultaneously. Countermeasures include an identity provider with high availability, an emergency and recovery plan and separately secured emergency access, often referred to as break-glass accounts. When selecting an ERP system, it should therefore be considered how the application behaves if the identity provider fails.
Which SSO integration should an ERP system support?
When evaluating an ERP system, it is worth checking which SSO protocols it supports natively, with SAML 2.0 and OpenID Connect considered standard, while proprietary special solutions make integration harder. It is also important how authorisations from the central directory service can be mapped to the ERP's internal roles, since SSO only establishes identity and does not grant the actual access rights. On the market, such central identity services are provided by Microsoft Entra ID, Okta or the open-source Keycloak, named here purely for illustration and without endorsement. Also to be clarified are the handling of technical accounts, the behaviour if the service fails and the question of whether an additional login can be enforced for particularly sensitive operations.