Implementing Single Sign-On (SSO): SAML, OIDC and Practical Guidance

Why SSO is more than convenience

Every employee in an average company uses between 20 and 40 different applications. Without single sign-on, that means 20 to 40 different passwords that violate every password policy, need to be memorised, entered and regularly changed. The result is predictable: passwords are reused, written on sticky notes or stored in insecure documents. Each of these passwords is a potential attack vector.

Single sign-on solves this problem by having employees sign in only once and then receiving access to all connected applications. The identity provider (IdP) handles authentication centrally, and the individual applications (service providers, SPs) trust its confirmation. It sounds like a simple concept, but implementation requires careful planning.

The security benefit of SSO goes far beyond reducing passwords. When an employee leaves the company, you deactivate a single account in the identity provider and access to all connected applications is immediately revoked -- a central building block of user lifecycle management. Without SSO, the IT department must manually deactivate each individual account, which can take days and in practice often remains incomplete. According to a study by Osterman Research, 25 per cent of former employees still have access to at least one company system weeks after their departure.

From a regulatory standpoint, SSO is not an explicit requirement of ISO 27001 or NIS2, but it is a central building block for implementing several requirements. ISO 27001 Annex A.8.5 (secure authentication) requires appropriate authentication mechanisms. Annex A.5.18 (access rights) demands a controlled procedure for granting and revoking access rights. Both are significantly facilitated by SSO.

The two protocols: SAML and OIDC

Two dominant protocols are available for the technical implementation of SSO: SAML 2.0 and OpenID Connect (OIDC). Both achieve the same goal through different means, and the choice between them has practical consequences for your company.

SAML 2.0: the enterprise veteran

SAML (Security Assertion Markup Language) was standardised by OASIS in 2005 and has since been the de facto standard for SSO in the enterprise space. The protocol is based on XML and defines three roles: the identity provider (IdP), which confirms identity, the service provider (SP), which provides the application, and the principal -- the user.

The SAML flow for an SP-initiated login works as follows: the user accesses the application. The application recognises that no valid session exists and creates a SAML authentication request. This request is redirected via the browser to the identity provider. The IdP authenticates the user (e.g. via username, password and MFA). After successful authentication, the IdP creates a SAML assertion -- an XML document containing the user's identity and attributes. This assertion is digitally signed and redirected via the browser back to the service provider. The SP verifies the signature, extracts the user information and creates a local session.

SAML's strengths lie in its widespread adoption in the enterprise space. Virtually every major SaaS application supports SAML: Salesforce, ServiceNow, Jira/Confluence, Slack, Zoom and hundreds more. The XML-based assertions enable the transmission of extensive attribute information, and signature verification provides strong cryptographic protection.

SAML's weaknesses show when dealing with modern application architectures. The protocol was designed for classic web applications with server-side rendering. Single page applications (SPAs), mobile apps and API-based microservices are cumbersome to connect. XML processing is complex and error-prone, and SAML assertions can be several kilobytes in size, which matters on mobile connections.

OpenID Connect: the modern standard

OpenID Connect (OIDC) was published in 2014 as an extension of OAuth 2.0 and addresses precisely SAML's weaknesses. While OAuth 2.0 only handles authorisation (who may do what), OIDC adds an authentication layer (who are you). The protocol uses JSON Web Tokens (JWTs) instead of XML and is therefore lighter and simpler to implement.

The OIDC flow for an Authorization Code Flow looks like this: the user accesses the application. The application redirects the browser to the identity provider's authorisation endpoint. The IdP authenticates the user. After successful authentication, the IdP redirects the browser back to the application with an authorisation code. The application exchanges this code at the IdP's token endpoint for an ID token (a JWT containing user information) and an access token. The application validates the ID token and creates a session.

OIDC's strengths are its native support for modern architectures. SPAs can use the implicit flow or the authorisation code flow with PKCE, mobile apps use the authorisation code flow with custom URI schemes, and microservices validate access tokens independently without contacting the IdP for every request. JWTs are compact, easy to parse and can contain additional claims used for authorisation.

The weaknesses: OIDC is less widespread in the enterprise space than SAML, although adoption is growing rapidly. Older enterprise applications often support only SAML. And the protocol's flexibility means different IdPs deliver slightly different implementations, which sometimes complicates integration.

SAML or OIDC: a decision guide

The decision between SAML and OIDC is rarely a pure either-or question in practice. Most identity providers support both protocols, and you will probably use both, depending on which protocol the respective application supports.

As a rule of thumb: if you primarily connect SaaS applications in the enterprise space (Salesforce, ServiceNow, SAP), you will predominantly use SAML because these applications have supported SAML for years and integration is well documented. If you connect modern web applications, SPAs, mobile apps or your own microservices, OIDC is the better choice because it was designed for these architectures.

For new in-house developments, you should use OIDC by default. The protocol is simpler to implement, JWT libraries are mature in all common programming languages, and debugging is easier because you can simply decode and inspect JWTs, whereas SAML assertions as Base64-encoded XML are significantly harder to read.

Choosing the right identity provider

The identity provider is the heart of your SSO infrastructure. It stores user identities, performs authentication, manages MFA and issues the tokens or assertions. The IdP choice has long-term consequences because a later migration is costly.

Microsoft Entra ID (formerly Azure AD)

Entra ID is the obvious choice if your company already uses Microsoft 365. The user accounts already exist, integration with Office applications is seamless, and many features are included in existing licences. Entra ID supports both SAML and OIDC, offers Conditional Access policies that control access based on device state, location and risk assessment, and integrates with on-premises Active Directory via Entra Connect (formerly Azure AD Connect).

For SSO with third-party applications, Entra ID offers an Enterprise Application Gallery with preconfigured integrations for thousands of applications. Setup often reduces to a few clicks: select the application from the gallery, exchange SAML metadata and configure attribute mapping.

Licensing is an important factor, however. Basic SSO features are included in Microsoft 365 Business Basic. Conditional Access, risk-based sign-in and advanced reporting require Entra ID P1 or P2, which means additional per-user monthly costs.

Okta

Okta is a specialised identity provider that operates independently of any particular ecosystem. This is an advantage if you have a heterogeneous infrastructure that is not primarily Microsoft-based. Okta offers an extensive integration catalogue, powerful lifecycle management features and a developer-friendly API.

The disadvantage is cost. Okta charges per user per month, and prices rise quickly with advanced features like Adaptive MFA and Lifecycle Management. For a company with 200 employees, annual costs can reach five figures.

Keycloak (open source)

Keycloak is an open-source solution from Red Hat that you can self-host. This offers maximum control over your identity data, no ongoing licence costs and the ability to customise the IdP to your specific requirements.

The downside: you are responsible for operations, maintenance, updates and high availability. Keycloak is a complex system requiring expertise in Java, Docker/Kubernetes and database administration. For companies without a dedicated DevOps team, operational effort can quickly exceed the saved licence costs.

Google Workspace

If your company uses Google Workspace, Google offers an integrated SSO solution supporting both SAML and OIDC. Integration with Google services is naturally seamless, and the integration catalogue covers the common SaaS applications. For companies with a primarily Google-based infrastructure, this is the logical choice.

Planning and implementing the SSO rollout

The technical setup of SSO is in most cases less demanding than the organisational preparation. Success depends on how thoroughly you inventory the application landscape, how wisely you choose the migration sequence and how well you prepare employees.

Phase 1: Inventory applications

The first step is a complete inventory of all applications used in your company. This includes not only officially procured SaaS services but also shadow IT -- applications that departments have adopted independently.

For each application, document the following: name and purpose, number of users, current authentication method, support for SAML and/or OIDC, criticality for business operations and the responsible contact person. This information forms the basis for prioritisation.

Typical sources for the inventory are IT asset management, accounting (SaaS invoices), browser plugins for capturing visited domains, CASB solutions (if available) and interviews with department heads.

Phase 2: Prioritise

Not all applications need to be migrated simultaneously. A sensible prioritisation considers three factors: risk, user count and integration effort.

Applications with high risk and large user counts where SSO integration is straightforward go first. These are typically the major SaaS platforms like Microsoft 365, Google Workspace, Salesforce or Slack. These applications offer well-documented SSO integrations, and migration has the greatest security impact because it eliminates the most local passwords.

The second wave includes applications with medium risk or smaller user counts. These may be project management tools, HR systems or development platforms.

Last come applications that do not support SSO or whose integration is particularly complex. For these cases, you need a transitional strategy, described further below.

Phase 3: Technical integration

The technical setup follows a uniform pattern regardless of whether you use SAML or OIDC.

On the identity provider side, you create the application, configure the redirect URLs, attribute mapping (which user information is transmitted to the application) and access permissions (which user groups may use the application). On the application side, you enter the IdP's metadata: the entity ID, the SSO URL and the certificate (for SAML) or the client ID, client secret and issuer (for OIDC).

For SAML integrations, attribute mapping is a common stumbling block. The application expects specific attributes in the SAML assertion (e.g. email address, first name, last name, group membership), and these must exactly match the attributes the IdP delivers. Different spellings, different name formats or missing attributes are the most common cause of integration problems.

Test every integration thoroughly before releasing it to all users. Verify the login flow, the logout flow (single logout is often error-prone with SAML), attribute passing, session duration and the behaviour when sessions expire.

Phase 4: Migration and rollout

User migration should proceed gradually. Start with a pilot group of IT employees who can independently identify and resolve problems. Then expand to a pilot group from a business department to test the user experience from a non-technical perspective. Only when both pilot groups have been successfully migrated do you roll out SSO to all employees.

During migration, you run the application in parallel mode: both local login and SSO login work. This is important as a fallback in case problems arise. Only once SSO is running stably for all users do you deactivate local login.

Communicate the rollout early and clearly. Employees need to know what is changing, why it is changing and what they need to do. A short step-by-step guide with screenshots showing the new login flow is more valuable than a long email with technical explanations.

Applications without SSO support

Not all applications support SAML or OIDC. Older on-premise applications, specialised industry software and some smaller SaaS services offer only local authentication with username and password. For these cases, you need a strategy.

The first option is an enterprise password manager acting as an SSO bridge. Services like 1Password Business or Bitwarden Enterprise can be configured to centrally manage passwords for non-SSO-capable applications and unlock them via the identity provider. The employee signs in to the password manager via SSO and then accesses the stored credentials. This is not an ideal solution, but it at least centralises management and enables password revocation during offboarding.

The second option is an SSO gateway or reverse proxy that pre-authenticates access. Solutions like Cloudflare Access or Pomerium place an authentication layer in front of the application that verifies identity via the IdP before granting access. The application itself does not need to support SSO.

The third option is replacing the application. If a business-critical application does not support SSO and none of the bridge solutions are practical, you should evaluate whether switching to an alternative with SSO support makes sense. This decision is obviously costly, but at the next licence renewal or version upgrade, SSO capability should be a hard selection criterion.

SSO and MFA: why both belong together

SSO without MFA is a dangerous construct. If a single password opens access to all applications, then a single compromised password opens access to all applications. SSO concentrates risk on a single authentication point, and that point must be correspondingly well protected.

Therefore, implementing MFA at the identity provider is a mandatory prerequisite for SSO. Every sign-in to the IdP must be secured by a second factor, whether a TOTP code, a FIDO2 key or a push notification. Most identity providers offer integrated MFA capabilities, so you do not need a separate solution.

Conditional Access policies extend this protection with context-based decisions. You can configure MFA to be required only at first sign-in on a known device within the corporate network, but for every sign-in from an unknown device or from abroad. Or that access to particularly critical applications always requires a FIDO2 key, while a TOTP code suffices for less critical applications.

This combination of SSO and risk-based MFA provides the best balance of security and usability. Employees sign in once, the IdP assesses the risk and requests additional factors as needed, and all connected applications trust this authentication.

Single point of failure: planning for high availability

If the identity provider goes down, employees cannot sign in to a single application. This single point of failure is the downside of centralisation, and you must take measures to manage this risk.

With cloud-based identity providers like Entra ID or Okta, availability responsibility lies with the provider. Both offer SLAs of 99.99 per cent, corresponding to approximately 52 minutes of unplanned downtime per year. In practice, downtime is lower, but it does occur. In March 2023, an Entra ID outage caused sign-in problems worldwide for several hours.

The following measures reduce the risk: first, configure long session lifetimes so that already signed-in users can continue working during a brief IdP outage without needing to re-authenticate. Second, you need break-glass accounts -- local administrator accounts for critical systems that do not use SSO and are used only in emergencies. These accounts must be secured with strong passwords, stored in a sealed envelope or hardware safe, and regularly tested. Third, for particularly critical applications, maintain a fallback to local authentication that can be activated in an emergency.

With self-hosted identity providers like Keycloak, you are additionally responsible for the infrastructure. This means redundant servers, database replication, load balancing and a tested failover procedure. The operational effort is considerable, and you should assess it realistically before choosing a self-hosted solution.

Just-in-time provisioning and SCIM

SSO solves the authentication problem but not the provisioning problem. When a new employee starts, their account must be created in every application. When they change departments, their permissions must be adjusted. And when they leave the company, all accounts must be deactivated.

Just-in-time (JIT) provisioning is a partial solution. When a user signs in to an application via SSO for the first time, the application automatically creates an account based on the information from the SAML assertion or OIDC token. This saves manual account creation, but it does not solve the deprovisioning problem. When you deactivate the user in the IdP, they can no longer sign in, but their account in the application continues to exist along with all stored data.

SCIM (System for Cross-domain Identity Management) goes a step further. SCIM is a standard for automatic provisioning and deprovisioning of user accounts. The identity provider automatically synchronises user accounts, group memberships and attributes with connected applications. When an employee is deactivated in the IdP, SCIM automatically deactivates their accounts in all connected applications.

SCIM support is growing but not yet universal. When selecting SaaS applications, you should consider SCIM support as a criterion, especially for applications with many users or sensitive data.

Creating an SSO policy

The SSO rollout should be accompanied by a policy integrated into your ISMS. This policy documents the binding rules and ensures SSO is anchored not only technically but also organisationally.

The policy should cover the following points: which applications must be connected via SSO? Which exceptions are permissible and how are they approved? Which MFA methods are configured at the identity provider and which are required for which application category? How are break-glass accounts managed, secured and tested? How does onboarding for new applications work? Who is responsible for technical integration? How is offboarding ensured, and within what timeframe must accounts be deactivated after departure?

This policy simultaneously serves as your evidence for auditors that you centrally manage and document access controls. In ISMS Lite, you can maintain the SSO policy as a versioned document and track application migration progress as an action plan. The tool covers all ISMS modules 500 Euro pro Jahr without seat licences.

Session management and logout

An often overlooked aspect of SSO is session management. When a user signs in to the IdP, they receive an IdP session. Each application they visit additionally creates a local session. These sessions have different lifetimes, and the interplay of these lifetimes determines the actual security level.

The IdP session should be configured to expire after a reasonable period of inactivity. Eight hours for the normal working day is a good benchmark. The local sessions of applications can be shorter, particularly for critical applications like HR systems or financial software.

Single logout (SLO) is the function that terminates all local sessions when signing out of the IdP. In theory, this is a clean mechanism. In practice, SLO with SAML is notoriously error-prone because it requires all service providers to process and confirm the logout request. If an application does not respond or does not correctly process the request, the local session persists.

With OIDC, the situation is somewhat better. The specification defines front-channel logout and back-channel logout, with back-channel logout being more reliable because the IdP sends the logout directly to the application without using the browser as an intermediary.

Regardless of protocol, you should test and document the logout behaviour of each integrated application. Where SLO does not work reliably, short session lifetimes are the best safeguard.

Monitoring and audit logging

SSO centralises not only authentication but also logging. The identity provider logs every sign-in, every failed sign-in attempt and every MFA challenge. These logs are a valuable data source for detecting security incidents and for audit purposes.

Configure alerts for conspicuous patterns: multiple failed sign-in attempts for the same account, sign-ins from unusual geographic regions, sign-ins outside normal working hours, or sign-ins from unknown devices. These alerts enable you to detect potential attacks early and respond.

For ISMS documentation, central logging is a major advantage. Instead of gathering sign-in logs from each individual application, you have a single data source containing all authentication-relevant events. This simplifies both regular review and evidence gathering in the event of security incidents.

Common mistakes in SSO rollouts

Most SSO projects fail not because of technology but because of preparation and communication. Here are the most common mistakes to avoid.

The first mistake is an incomplete application inventory. If you do not know half the applications in use, you cannot connect them, and employees keep their local passwords. The security benefit of SSO is only as great as the proportion of connected applications.

The second mistake is SSO without MFA. As described above, SSO concentrates risk on a single sign-in point. Without MFA, this point becomes the most attractive target for attackers.

The third mistake is neglecting offboarding. SSO significantly facilitates offboarding, but only if you have a defined process ensuring the IdP account is deactivated promptly. Without this process, SSO is no better than separate accounts when it comes to offboarding.

The fourth mistake is the absence of break-glass accounts. If the IdP goes down and you have no alternative access to critical systems, you face a complete standstill.

The fifth mistake is poor communication. Employees who suddenly see a new login flow without having been informed beforehand will be unsettled, call the helpdesk and create unnecessary overhead. A clear advance announcement with date, instructions and contact person prevents this.

The path to successful SSO

Implementing SSO is not a weekend project, but neither is it a mammoth undertaking. For a company with 100 to 500 employees and 20 to 50 applications, a timeframe of three to six months is realistic -- from inventory to complete migration.

Start with the inventory of your applications. Choose an identity provider that fits your existing infrastructure. Connect the most important applications first and work your way through the list step by step. Activate MFA at the IdP from day one. Document everything in your ISMS and take the opportunity to revise your authorisation concept at the same time.

SSO is more than a technical measure. It is an organisational change that improves the interplay between IT, HR and business departments. If you do it right, you gain not only security but also efficiency and transparency.

Further reading

• Implementing multi-factor authentication (MFA): strategy, rollout and adoption
• Creating an authorisation concept: from role models to recertification
• User lifecycle management: onboarding, role changes, offboarding
• Securing Active Directory: hardening, tiering and monitoring
• Zero trust for mid-market companies: principles, quick wins and pitfalls