SSO with SAML 2.0 and OIDC: one login for Bexio, Microsoft 365, and AI apps

What are SAML and OIDC?

Single sign-on (SSO) describes the architecture in which a user signs in once at a central identity provider and then gets access to multiple applications without re-authenticating. The two dominant protocols are SAML 2.0 and OpenID Connect (OIDC).

SAML 2.0 (Security Assertion Markup Language, version 2.0) has been standardised since 2005 and is the traditional enterprise protocol. It transports authentication statements (assertions) as signed XML documents between the identity provider (IdP) and the service provider (SP). The users browser is the transport channel (HTTP-POST or redirect binding). SAML is robust, widespread, but XML-based and clumsy in modern web/mobile stacks.

OIDC (OpenID Connect) is a layer on top of OAuth 2.0, standardised since 2014. It transports identity statements as JSON Web Tokens (JWT), which are more compact than XML. The authentication flow runs as HTTP redirect with JSON responses. OIDC is, as of May 2026, the de-facto standard protocol for new web apps, mobile apps, and single-page apps.

The most important IdPs in the Swiss fiduciary market are: Microsoft Entra ID (formerly Azure AD, over 60% market share at Swiss SMEs), Google Workspace IdP (15-25%), Keycloak (open source, for self-hosted setups), Authelia (lightweight open source). Alongside Okta (especially at Swiss subsidiaries of US corporations) and Auth0 (now Okta-owned, popular with SaaS providers).

May 2026 brings two decisive trends. First: passkeys (WebAuthn / FIDO2) are becoming standard for end-users. Instead of a password the user provides a biometric factor (fingerprint, face) or a hardware key. Phishing-resistant and user-friendly. Second: SCIM 2.0 (System for Cross-domain Identity Management) is becoming standard for user provisioning. The IdP automatically creates user accounts in connected apps, modifies them, and deactivates them upon departure.

Why it matters for Swiss fiduciary

A typical Swiss fiduciary office with 10 employees uses over 15 tools: Microsoft 365, Bexio, payroll software, a CRM, a document management system, time tracking, a banking tool, plus several AI tools (receipt recognition, client chat, dunning). Without SSO, employees must manage a separate password for each application. That practically always ends in password reuse or sticky notes on the monitor.

SSO solves this problem on three levels. First: one login. The employee signs in to Entra ID in the morning and then has access to all tools where his account is set up. That noticeably lowers daily friction.

Second: one exit switch. When an employee leaves, the admin deactivates the account in the IdP and all connected apps are locked in the same second. That is mandatory under the FADP and CO Art. 328b, but in reality often forgotten when every app has its own account system.

Third: audit-ready access logs. Every sign-in is logged in the IdP: who, when, which app, which device, which IP range. On a FADP incident you have a searchable audit trail.

Concrete example: a fiduciary office with Bexio + Microsoft 365 + custom AI app. All three are integrated as service providers in Entra ID. The employee clicks the Bexio icon in the morning, is redirected to the Entra ID login, enters a passkey, is in Bexio. No new sign-in needed when switching to the AI app.

How it works

Both protocols share the same basic choreography: the service provider redirects the user to the IdP, the IdP authenticates, the IdP returns a signed statement to the service provider.

SAML 2.0 in detail: the service provider (e.g. Bexio) recognises that the user is not signed in and sends a SAML AuthnRequest as HTTP-POST or redirect to the IdP. The IdP (e.g. Entra ID) authenticates the user (password, passkey, MFA) and issues a SAML assertion: an XML document with user attributes (email, name, roles), signed with the IdPs private X.509 key. The user is redirected back to the service provider with this assertion; the SP verifies the signature and signs the user in.

Trust between IdP and SP is established via two metadata XMLs exchanged once between the parties: the IdP provides its X.509 certificate and entity endpoint, the SP does the same. Configuration typically happens in the IdP admin centre and the SP config area.

OIDC in detail: the SP (relying party, RP) redirects the user with an authorisation request to the IdP (authorisation server). The IdP authenticates and returns a code. The SP exchanges the code at the IdPs token endpoint for an ID token (JWT with user claims like sub, email, name) and an access token (for API calls). The JWT signature is verified against the IdPs public JWK (JSON Web Key).

An example token exchange in OIDC:

```bash curl -X POST "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token" \ -d "client_id=$CLIENT_ID" \ -d "scope=openid profile email" \ -d "code=$AUTH_CODE" \ -d "grant_type=authorization_code" \ -d "redirect_uri=https://your-app.ch/callback" \ -d "client_secret=$CLIENT_SECRET" ```

The response contains id_token, access_token, and refresh_token. The SP decodes the id_token, verifies the signature against the JWKS endpoint, and creates the user session.

SCIM provisioning runs in the background: the IdP knows the SCIM endpoints of the apps and sends a REST call to the app on every user change (user created, modified, disabled).

SSO rollout in 5 steps

1. 01Choose the IdP (Entra ID for Microsoft 365 customers, Google Workspace IdP for Google customers, Keycloak for self-hosted setups).
2. 02Build the app inventory: which apps are in use, which support SAML, which OIDC, which neither?
3. 03Pick a pilot app (typically a low-critical one, e.g. the internal wiki), configure the SSO link, and pilot for 2 weeks.
4. 04Roll out to all apps with SSO support, document each step (metadata, OAuth client IDs, sign-out URL).
5. 05Introduce passkeys for new users, activate SCIM provisioning for critical apps, model the lifecycle workflow (on-/offboarding) in the IdP.

When to use SSO

As soon as three or more tools are in use, SSO is worthwhile. In Swiss fiduciary offices from 5 employees onwards, SSO is practically mandatory today; the combination of Microsoft 365 as IdP plus SAML or OIDC connection to all other tools is standard.

For new apps (AI tools, custom dashboards) choose OIDC. It is easier to implement (JSON instead of XML, JWT libraries in every language) and better suited for SPAs and mobile apps. SAML is the choice when the app only supports SAML (often with older enterprise software) or when the IT department historically standardised on SAML.

Activate passkeys for all new users from May 2026. Migrate existing users step by step. The switch from password to passkey reduces phishing success by over 90 percent according to OWASP studies.

Activate SCIM from 20 employees onwards. Below that threshold, the manual provisioning effort is acceptable.

When not to use

For a one-person office without external apps, SSO is overhead without clear benefit. A well-managed password manager is enough.

For apps used only sporadically and without sensitive data, SSO can mean disproportionate implementation effort. Example: a small marketing tool used once per quarter. Password plus password manager is cheaper here.

For multi-tenant SaaS providers selling SSO as a premium feature, the app may require an SSO add-on licence (the "SSO tax problem"). For small volumes the licence does not pay off. Check this before purchasing.

SAML 2.0 is the worse choice for completely new apps. XML processing, signature verification, and metadata exchange are prone to configuration errors. If you have a free choice, take OIDC.

Trade-offs

FAQ

Related topics

Sources

1. OASIS: SAML 2.0 Core Specification · 2026-05
2. OpenID Foundation: OpenID Connect Core 1.0 · 2026-05
3. Microsoft Entra ID: SAML and OIDC integration guide (May 2026) · 2026-05
4. FIDO Alliance: Passkeys deployment guidance 2026 · 2026-04