SAML and OIDC are the two main identity federation protocols behind single sign-on (SSO). The core difference in SAML vs OIDC: SAML 2.0 carries signed XML assertions through the browser and suits enterprise web apps, while OpenID Connect (OIDC) is a JSON/JWT identity layer on OAuth 2.0 that fits mobile apps, single-page apps and APIs better.
This article is for teams that have already chosen SSO and now need to pick a protocol. If you are still weighing up SSO itself, start with our guide to the benefits of single sign-on.
The decision point: two options on one settings page
You open a cloud application's admin console, find the "SSO" tab and see two choices: SAML and OpenID Connect. Your identity provider supports both, the app supports both, and nobody tells you which one to pick.
The question gets harder when you are building your own software. A web portal, a mobile app for field staff and an API used by distributors should all share one identity. Pick the wrong protocol and you end up with awkward browser workarounds on mobile and a separate set of API passwords, which defeats the point of having one identity.
The third scenario is the mixed estate. An older accounting or HR system speaks only SAML, while everything new is written against OIDC. Here the real question is not "which one" but "how do we run both consistently from a single identity provider".
What a weak identity layer costs
Protocol choice looks like a footnote, yet every gap in the identity layer is attack surface:
According to the Verizon 2026 Data Breach Investigations Report (DBIR), the use of stolen credentials held steady as an action in 36% of breaches.
The same report found that breaches involving a third party rose by 60% to reach 48% of the total, and only 23% of third-party organisations fully remediated missing or poorly secured multi-factor authentication on their cloud accounts. An estate where every SaaS app keeps its own password multiplies exactly these weak links.
Sophos' State of Identity Security 2026 survey of 5,000 IT and security leaders in 17 countries found that 71% of organisations suffered at least one identity-related breach in the past year. Only 24% continually monitor for unusual login attempts. Apps that are not federated to a central identity provider sit outside that monitoring altogether.
The Microsoft Digital Defense Report 2025 adds that more than 97% of identity attacks are password attacks. The real value of SSO is hardening passwords and MFA in one place; we compare second-factor options in our guide to multi-factor authentication for business.
How SAML and OIDC actually work
Both protocols share the same cast. An identity provider (IdP; an "OpenID Provider" in OIDC terms) authenticates the user, and an application trusts that result (a "Service Provider" in SAML, a "Relying Party" in OIDC). What differs is how the message is packaged and delivered.
SAML 2.0 was standardised by OASIS in 2005. When a user reaches the app, the browser is redirected to the identity provider, the user signs in and the provider issues a signed XML assertion. That document travels back through the browser, usually via HTTP POST, and both sides have exchanged metadata files and certificates beforehand.
OpenID Connect was published by the OpenID Foundation in 2014 and adds an identity layer on top of OAuth 2.0. The recommended pattern is the authorisation code flow with PKCE: the app receives a short-lived code and swaps it over a back channel for an ID token (a signed JWT) and, where needed, an access token. The app discovers the provider's endpoints and signing keys from a standard discovery document.
A common mix-up: OAuth 2.0 on its own is not an authentication protocol; it is an authorisation protocol. It says "this app may call that API on my behalf", not "this is who the user is". OIDC is the layer that carries identity in a standard way.
SAML vs OIDC: side-by-side comparison
| Criterion | SAML 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Foundation | Standalone XML standard | Identity layer on OAuth 2.0 |
| Data format | Signed XML assertion | JSON, signed JWT (ID token) |
| Transport | Browser redirect, HTTP POST | Redirect plus back-channel token exchange |
| Best fit | Enterprise web apps, legacy systems | Mobile, single-page apps, APIs, new builds |
| API access | No native equivalent | Native, via access tokens |
| Setup | Metadata and certificate exchange | Discovery URL, client ID (plus a secret for server-side apps) |
| Key rollover | Certificate expiry must be tracked | Keys read automatically from discovery |
| Typical mistake | Incomplete signature validation | Loosely defined redirect URIs |
Both protocols are secure when implemented properly; weaknesses usually sit in the implementation, not the specification. SAML needs the signature and audience checked on every response, while OIDC needs exact redirect URI matching plus state and nonce checks. On the OAuth side, IETF RFC 9700, the current security best practice, recommends retiring the old implicit flow.
Choosing between SAML and OIDC in six steps
- Map your applications by protocol. List what each app supports, who uses it and whether it is a web app, a mobile app or an API.
- For off-the-shelf apps, follow the vendor's strongest path. If a SaaS product supports both, choose the option its documentation leads with, especially where it also covers user provisioning.
- Start new software on OIDC. When web, mobile and API share one identity, OIDC keeps them in a single model; add SAML only when a customer or partner explicitly asks for it.
- Choose an identity provider that speaks both. In a mixed estate the risk is not the protocol but ending up with two identity sources; one provider should handle both.
- Plan the user lifecycle separately. SAML and OIDC handle sign-in, not account creation or removal; for that you need a provisioning standard such as SCIM or a dedicated integration. We cover the typical leaver gaps in our piece on offboarding email access.
- Test and keep records. Put certificate and key renewal dates in the calendar, centralise sign-in logs and have the set-up verified as part of a penetration test.
Rule of thumb: for a ready-made browser-based enterprise app, SAML is usually adequate and widely supported. For mobile apps, APIs or anything built from scratch, OIDC brings less friction and a cleaner architecture. Whichever you choose, the central identity still needs the password rules set out in our guide to business password security.
How we approach identity federation at Digital Bridge
We start identity projects with an inventory, not a settings screen. Together we map which system speaks which protocol, who can reach what, and whether accounts belonging to former staff are still active.
- Discovery and risk review: Through our cyber security consultancy we review the application inventory, the identity provider set-up and signature and redirect validation. Findings are prioritised alongside our broader SME cyber security checklist.
- Pilot: We first connect one or two apps everyone uses with the chosen protocol, then test sign-in, sign-out and account removal with real users.
- Integration: Where ERP, HR or site-specific systems must work with the central identity, we build the connection through our system integration and API integration services. The basics of token-based API access are covered in API integration explained.
- Identity designed in from day one: In the custom web software and mobile apps we build, the identity layer is planned during requirements analysis. For the wider build-or-buy question, see custom vs off-the-shelf software.
Keeping sign-in records and documenting access rights are also among the technical and administrative measures listed in the Turkish Personal Data Protection Authority's guidance under Article 12 of KVKK, Türkiye's Personal Data Protection Law No. 6698, which is broadly comparable to the GDPR. Which records to keep, and for how long, should be settled through your own assessment and legal advice. We suggest reading this alongside our KVKK compliance steps. For more articles in this category, visit our cyber security and compliance guides.
One identity for email and files with Smart360
The need for one identity is felt most in business email and file sharing, the two apps everyone opens every day. In the Smart360 family, SmartMail (business email) and SmartFiles (document management) are managed through a single identity, SmartID. Staff sign in with one password and move between products without being asked for it again.
Take a concrete case: an employee leaves an accounting practice. The administrator closes SmartMail and SmartFiles access in a single action, and when someone changes department their access updates across all products automatically. Active sessions are listed with device details and can be ended remotely, and changing a password ends every session.
Human verification on sign-in screens stops password-guessing attacks before they reach the server. SmartID is the shared identity across Smart360 products; how Smart360 fits alongside your other applications, and what identity set-up your external systems need, is something we work out together during requirements analysis.
Your next step
If you face several apps offering SAML and OIDC, a new software project or a sprawling identity set-up, let's start by mapping your applications together. Get in touch and we will review your current state and prepare a written proposal covering which app should connect with which protocol and the scope of a pilot.