Single Sign-On Integration: How It Works and How to Do It

Single sign-on (SSO) is not a product you install. It is an integration between a central identity provider and each application your team uses. The identity provider checks who the user is, and every connected app trusts that decision. Doing it well comes down to four things: choosing the right protocol (SAML or OpenID Connect), agreeing on the identity data each app receives, handling account creation and removal, and testing before you enforce it. We build and connect business systems for a living, and this guide walks through the whole path.

TL;DR

• SSO is an integration: one identity provider verifies the user, and each application (the service provider) relies on that verdict.
• Use SAML 2.0 for traditional enterprise web apps and OpenID Connect (OIDC) for modern web apps, mobile apps and APIs.
• SSO handles sign-in only. Add SCIM if you want accounts created and deactivated automatically when people join or leave.
• Plan in order: inventory apps, define attributes and roles, pilot with low-risk apps, test, then enforce and monitor.
• In Switzerland, you stay responsible for the legal basis, processors, foreign disclosures, logging and deletion even when a cloud provider runs the login.

Is single sign-on an integration?

Yes. Microsoft defines SSO as signing in once with one set of credentials and then reaching your assigned applications without signing in again. Behind that experience, a central identity provider verifies the user and confirms the identity to each app.

That is why “single sign-on integration” is the phrase people search for. Turning SSO on means wiring two sides together:

• The identity provider (IdP): the central authority, for example Microsoft Entra ID or Okta.
• The service provider (SP): your CRM, your ERP, your customer portal, your internal tools. Okta describes the IdP as the central authentication authority and the apps as service providers that rely on its federated identity decision.

The related question, “what is API vs SSO?”, has a short answer. An API lets one system call another to exchange data or trigger actions. SSO lets a person prove who they are once. They often meet: OIDC, for instance, also serves APIs that need both authentication and authorization.

How the login flow works

In the common service-provider-initiated flow, the sequence is simple:

1. The user opens an application.
2. The app redirects them to the identity provider.
3. The IdP verifies the user’s work credentials and confirms their identity.
4. The app grants access.

Microsoft Entra describes this exact sequence. It also supports identity-provider-initiated flows for SAML apps, where the user starts from a portal (Microsoft calls it My Apps) and clicks an app tile. Service-provider-initiated flows work for both SAML and OIDC.

Once you see the flow, you see where integrations break: redirect addresses that do not match, certificates that expire, and attributes that arrive empty or named differently than the app expects.

SAML, OpenID Connect and OAuth: which one to use

The protocol decides how identity information is packaged and delivered to your app. According to Microsoft, SAML 2.0 is an XML-based standard used widely in enterprises and suits traditional web apps and detailed user attributes. OIDC is built on OAuth 2.0, uses JSON-based tokens, and suits modern web apps, mobile apps and APIs that need both authentication and authorization.

	SAML 2.0	OpenID Connect
Format	XML assertions	JSON-based tokens (ID token)
Typical fit	Traditional enterprise web apps, rich user attributes	Modern web apps, mobile apps, APIs
Built on	Its own standard	OAuth 2.0
Typical setup items	Entity ID, reply URL, signing certificate or metadata	Issuer, client ID, client secret, redirect URIs

One distinction trips up many teams. OAuth 2.0 is an authorization framework for delegated access to protected resources. OpenID Connect adds standardized user authentication and identity claims on top. If you need to know who the user is, you need OIDC (or SAML), not OAuth alone.

Neither protocol changes who makes the authentication decision. Per Microsoft’s SSO model, they only change how the identity is delivered. So choose by what your application supports and what you need next: if a vendor’s app offers only SAML, use SAML. If you are building a new product with a mobile client, OIDC is the natural fit.

Plan the integration before touching settings

Most failed rollouts skip planning. Three things belong on paper first.

Inventory your applications

The US Enterprise SSO Playbook makes an application inventory the first integration-planning step. For each app, record the supported protocols, the user communities, the required attributes, how accounts are provisioned and how critical the app is. That last column decides your rollout order.

Agree on identity data

Swiss federal AGOV guidance lists the interoperability points a trust configuration should define: claims and attributes, stable person identifiers, roles and group mappings, and signing or encryption procedures. A stable identifier matters most. If apps match users by email address and someone changes their name, you get duplicate or orphaned accounts. Decide on one immutable identifier per person and use it everywhere.

Role mapping deserves the same care. Decide which IdP group becomes which role in each app, and write it down. Otherwise “admin” in one system quietly means something different in another.

Decide the rollout order

The same playbook, along with other guidance it summarizes, recommends a staged approach: begin with lower-risk applications, use pilot feedback before full release, then monitor usage, performance, security logs and unusual login activity. Put your internal wiki or a project tool in the pilot, not your accounting system.

Step-by-step: connecting an application

The steps differ slightly by protocol. The shape is the same.

Step 1: Register the application in the identity provider

For an OIDC connection, the registration produces an issuer, a client ID and a client secret. Your application is configured with redirect URIs and must validate the provider’s ID token. Guard.ch’s setup guide describes these fields and validation steps in practice.

For a SAML connection, the registration normally needs the entity ID, the assertion consumer service (reply) URL, a signing certificate or federation metadata, claims mapping, user assignment and a test account, as listed in this Entra integration guide.

Where it goes wrong: a trailing slash in a redirect URI, a certificate pasted with line breaks lost, or a client secret that expires without anyone owning the renewal. Put the expiry dates in a shared calendar on day one.

Step 2: Map claims and roles

Send only the attributes the app needs: a stable identifier, an email address, name, and group or role. Fewer attributes mean less personal data moving around, which also helps with the Swiss data-protection points below.

Step 3: Assign users

Start with a small named group. In SAML setups, assigning users to the app in the IdP is part of the registration, and forgetting it produces a confusing “access denied” for people who are otherwise valid.

Step 4: Test with a real account

Testing is covered in its own section below. Do not enforce SSO until a full sign-in works end to end.

Step 5: Enforce, then monitor

Only after a successful pilot do you require SSO for everyone and disable password login. Keep at least one emergency administrator path documented, so a misconfigured IdP does not lock the whole company out.

Provisioning: SSO does not remove accounts

This is the part most guides skim. SSO authenticates; it does not manage the account lifecycle. As one Entra integration guide states, SAML or OIDC authenticates the user, while SCIM provisions and deprovisions application accounts, and it recommends both for the full lifecycle.

The difference shows at offboarding. SAML just-in-time provisioning creates an account at first login but cannot deprovision it. SCIM can create accounts before first login and deactivate them when someone leaves. If a former employee’s IdP account is disabled but their app account lingers, any token or session still valid may keep working.

When you build SCIM support into your own application, treat active=false as immediate access revocation. The SCIM guide notes that Okta commonly sends a PATCH setting active to false rather than a DELETE, so an app that waits for a delete will never revoke access.

Testing and maintaining the integration

A good test flow checks more than “did I get in”. Guard.ch’s flow runs a provider sign-in without actually signing the user in, displays the received address and claims, and requires a successful test after connection changes before SSO can be enforced. That pattern is worth copying: see exactly what the IdP sent before you trust it.

For provisioning, Bynder’s support guide suggests using a real test user, verifying required attributes and permissions, and inspecting the provisioning logs.

A short test list:

• A new user signs in for the first time and lands with the right role.
• A user in the wrong group is refused.
• A disabled user can no longer sign in and their app account is deactivated.
• A user who changes department gets the new role.
• After any change to the connection (new certificate, new secret), the test passes again before enforcement.

Maintenance is mostly calendar work: certificate and secret renewals, review of group mappings when teams reorganize, and a periodic read of the sign-in logs.

Security: what SSO concentrates

SSO removes password sprawl, but it centralizes risk. Auth0 explains that risk consolidates in tokens and application sessions. Its mitigations are concrete: validate token signatures, expiry, issuer and audience; use PKCE, secure token storage, short-lived access tokens and refresh-token rotation; apply session timeouts and step-up authentication for high-risk actions.

NIST’s token-security material stresses that signing keys are the root of trust and that assertions and tokens should be scoped, validated and time-bound. In practice, that means restricting who can touch signing keys and rotating them on a schedule.

For critical services, add layers instead of relying on the login alone. A security analysis by Doyensec argues you should not assume the identity provider will always stay secure, and lists additional MFA, least-privilege access requests, short-lived certificates and continuous monitoring. Require a second factor at the identity provider; a multi-factor authentication setup guide shows how that layer is typically configured for accounts such as email.

Swiss data-protection points

If your users or customers are in Switzerland, the login system is not outside data protection. The AGOV guidance on cloud and SaaS architectures says the organization remains responsible for the legal basis, purpose and proportionality, the choice of cloud or SaaS provider, access rights and information security. It also names processors and subprocessors, foreign disclosures, retention and deletion, logging, continuity and exit, and information to data subjects.

Translate that into project tasks:

• Record which provider runs the identity service and where data is processed.
• Limit the claims sent to each app to what that app needs.
• Set retention for sign-in logs and define who may read them.
• Plan an exit: if you leave the IdP, how do users and apps move?
• Tell users what is processed.

For questions about your specific legal basis, speak to your data-protection adviser or legal counsel.

Where a studio helps

The protocol work is standard. The hard part is the surrounding system: legacy apps that speak neither SAML nor OIDC, a custom portal that needs SCIM endpoints, shop, CRM and ERP connections that all need to agree on one user identity. Ampersand is a Zurich studio where senior engineers lead each project from first contact to handover, and we do system integrations and API connectivity for shops, CRM and ERP, as well as replatforming and migration of legacy systems. Our pricing page lists the integration options, from a single connection to an integration suite, and a Run & monitor plan at 750 CHF per month for ongoing support.

FAQ

Is SSO the same as OAuth?

No. OAuth 2.0 is a framework for delegated access to resources. SSO is the outcome of signing in once, which SAML or OpenID Connect delivers. OpenID Connect sits on top of OAuth 2.0 and adds standardized identity claims.

How do I integrate single sign-on into an existing app?

Register the app in your identity provider, choose SAML or OIDC based on what the app supports, map the claims and roles, and assign a small test group. Run a full sign-in test, then enforce SSO and monitor logs. Add SCIM if you want automatic account deactivation.

Does SSO replace user provisioning?

No. SSO verifies identity at login. Creating and deactivating accounts is the job of provisioning, usually SCIM. Without it, accounts can remain active after someone leaves.

Is single sign-on secure?

It can be, when tokens are validated, sessions are time-limited, a second factor is required and sign-in activity is monitored. SSO concentrates risk in the identity provider and tokens, so those need the most protection.

Which protocol should a new web app use?

OpenID Connect suits modern web apps, mobile apps and APIs. SAML 2.0 is the choice when your customers’ enterprise systems or a vendor’s app require it. Many products support both.

Sources

• What is single sign-on in Microsoft Entra ID?
• Understand Microsoft’s SSO model
• Single Sign-On overview, Okta Developer
• SAML vs. OpenID vs. OAuth vs. LDAP
• AGOV in cloud, SaaS and Hyperscaler architectures
• Enterprise Single Sign-On Playbook
• Single sign-on setup, Guard.ch
• Microsoft Entra ID SAML integration for SaaS apps
• Microsoft Entra ID SAML integration for SaaS apps, Part 2
• SCIM 2.0 explained
• How To Enable And Use Azure SCIM With Bynder
• What is Single Sign-On (SSO) and How Does it Work?, Auth0
• Teleport Security Whitepaper, Doyensec
• Hands off my Tokens, NIST