OAuth vs SAML: Which One Should You Use?

OAuth and SAML solve different problems, and that is why comparing them head to head is slightly misleading. SAML signs a person into an application through a central identity provider, mostly in enterprise single sign-on. OAuth 2.0 lets one application get limited access to another service’s API on a user’s behalf. The protocol most people actually mean when they say “OAuth login” is OpenID Connect (OIDC), a thin identity layer on top of OAuth. So the real choice for most teams is SAML or OIDC for login, and OAuth for API access.

Below we cover what each one does, how they differ in practice, how to decide, and what changes when your users and data sit in Switzerland.

TL;DR

• OAuth 2.0 is about authorization: it answers “may this app call that API, and with what scope?” It does not tell you who the user is.
• SAML 2.0 is about federated login: an XML-based standard for browser SSO, still the default in many large corporate and legacy environments.
• OIDC is OAuth plus identity: it adds an ID token so you get standardized authentication. It is usually the better pick for new web, mobile and API-driven products.
• Support both if your customers are enterprises or authorities: Swiss federal identity services accept both OIDC and SAML 2.0.
• The protocol does not settle your legal duties: under the Swiss Data Protection Act (DSG), what you do with personal data after login still has to be justified.

What each protocol actually does

The quickest way to separate the three names is by the question each one answers. One practical comparison frames it well: OAuth answers whether an application may call an API, OIDC answers who signed in, and SAML handles federated login between an identity provider and an application.

OAuth 2.0: delegated access

OAuth 2.0 is defined in RFC 6749. Its job is to let an application obtain limited access to a protected resource, either for a user or on its own behalf. Think of a scheduling tool that reads your calendar, or a back-end service that calls another company’s API. The user never hands their password to the third party. Instead the app receives an access token with a defined scope and lifetime.

The important point: an access token is a permission slip, not an identity card. If you treat “I have a valid token” as “I know who this is,” you will eventually ship a security bug. That mistake is common, and it is exactly why OIDC exists.

The standard is also still moving. The IETF’s OAuth 2.1 draft is described as replacing and obsoleting RFC 6749 and the bearer token usage document, though it was still an Internet-Draft in the version we checked. The practical advice is the same today: use the authorization code flow with PKCE and skip the legacy flows.

OpenID Connect: OAuth with a login

OIDC reuses OAuth 2.0 flows and adds a standard ID token, a signed JSON Web Token that carries claims about who authenticated and how. It uses JSON and plain REST-style calls, which fits single-page apps, native mobile apps and API-centric systems. When a developer says “we use OAuth to log in with Google,” they almost always mean OIDC.

SAML 2.0: the enterprise SSO workhorse

SAML 2.0 is an XML-based standard. An identity provider (IdP) issues a signed assertion about the user, and the service provider (SP), your application, trusts it. The exchange runs through browser redirects and POST bindings. It predates the mobile era, and it shows: SAML is built around a browser and a session, not around a native app or a machine calling an API.

It is also deeply entrenched. Corporate directories, HR systems and many legacy SaaS products still speak SAML, and enterprise IT teams often ask for it by name.

OAuth vs SAML at a glance

	OAuth 2.0	OIDC	SAML 2.0
Main purpose	Authorization (API access)	Authentication on top of OAuth	Authentication and SSO
Data format	JSON, opaque or JWT tokens	JSON, JWT ID token	XML assertions
Typical clients	APIs, mobile, SPAs, services	Web, mobile, SPAs	Browser-based web apps
Tells you who the user is?	Not by itself	Yes	Yes
Mobile and API fit	Strong	Strong	Weak
Where you meet it	Third-party integrations	Modern login, consumer and B2B	Corporate SSO, legacy suites
Implementation effort	Moderate	Moderate	Higher, XML signing and metadata

The row to remember is the fourth one. OAuth alone does not authenticate. SAML and OIDC do.

How to choose: a decision path

Stop asking “which is better” and ask what you are building and who connects to it.

1. You need users to log in to your own new product. Use OIDC. Pair it with an identity provider or library you trust rather than writing token handling yourself.
2. You need your app to call someone else’s API on behalf of users. Use OAuth 2.0 with authorization code and PKCE, and request the narrowest scopes you can.
3. A customer’s IT department says “we use SAML.” Offer SAML 2.0 as an enterprise SSO option. Many B2B products start with OIDC and add SAML when the first large customer asks.
4. You connect services to each other with no user present. Use OAuth 2.0 client credentials, not SAML.
5. You must integrate with a government or federal identity service. Check what it supports and read its specification first. More on that below.

Is OAuth 2.0 obsolete?

No. OAuth 2.0 is still the base of modern API authorization, and OAuth 2.1 consolidates best practice rather than replacing the idea. What is obsolete is a set of older patterns: the implicit flow and the password grant. If a tutorial tells you to use them, find a newer tutorial.

Is SAML dying?

Not soon. It is a mature standard that works, and replacing it inside large organizations is expensive with little visible payoff. For new builds, OIDC is the easier path. For anyone selling into enterprises, SAML support remains a sales requirement, not a legacy curiosity.

A common architecture mistake: stuffing permissions into the login

Identity and access are two jobs. Authentication says who you are. Access management decides what you may do inside a specific application. Teams get into trouble when they try to push every role and permission through the identity protocol.

Swiss federal services make the split explicit. AGOV, the authentication service for Swiss authorities, provides identities and authentication via OIDC or SAML, but it does not handle roles or permissions. The application that connects has to implement its own access management. That is good design for any product: receive a verified identity, then map it to roles and permissions in your own system, where you can change them without touching your identity provider.

A practical pattern:

• Take a stable user identifier and a small set of attributes from the ID token or SAML assertion.
• Look up or create the user in your own database.
• Assign roles locally, and keep the audit trail for them locally too.
• Treat group claims from the identity provider as hints, not as the permission system.

Switzerland: what changes for your integration

Both protocols are first-class citizens

If you build for the public sector or sell to it, you will meet federal identity services. The AGOV documentation on cloud, SaaS and hyperscaler architectures states that target applications can connect to AGOV via OIDC or SAML 2.0, directly or through an existing identity and access management layer. The same page describes support for OIDC with the authorization code flow and PKCE. So in this setting the answer to “OAuth vs SAML” is often “both are accepted, pick what your stack and your customer’s IAM team handle best.”

Do not treat it as a generic OIDC or SAML setup

Supporting a standard is not the same as accepting any implementation of it. Federal identity services publish their own profile requirements, redirect procedures and attribute mappings. Read the official integration specification before you design anything, and budget time for it. Teams that skip this step tend to discover mismatches late, when changing them means rework.

The protocol choice is not the legal question

Switzerland’s Federal Data Protection and Information Commissioner (FDPIC) is clear that cloud processing is its own matter. In its cloud computing guidance, the FDPIC explains that a cloud provider generally acts as a processor for the customer under Art. 9 of the Data Protection Act, and that the customer remains the party responsible. A secure SSO handshake does not change that.

In practice, if you connect a SaaS product to your users’ identities, ask:

• Which personal data flows to the provider once the user is logged in, and where is it stored?
• Is a data protection impact assessment needed? The DSG provides for one where processing is likely to result in a high risk to the person concerned; the text of the Act on Fedlex is the place to check the conditions.
• Do you have a processing agreement with the provider, and do you know about transfers abroad?

These questions apply equally to SAML and OIDC. Talk to your data protection officer or a lawyer before you go live with sensitive data, particularly when a provider is US-based.

Prefer open standards over proprietary login

Swiss public and education sectors increasingly rely on shared identities such as AGOV or SWITCH edu-ID. The sensible lesson for a private product is the same: lean on SAML and OIDC rather than a proprietary login mechanism. Open standards keep you able to change identity providers later, and they keep your customers’ IT teams happy.

Practical pitfalls we see in real projects

• Using OAuth access tokens as proof of login. If you need identity, validate an OIDC ID token, check the issuer, audience, signature and expiry.
• Skipping PKCE. It is cheap protection for public clients such as SPAs and mobile apps, and the authorization code flow with PKCE is the baseline modern guidance.
• Wide scopes. Ask for what the feature needs now. Users and security reviewers both notice.
• Weak SAML validation. Verify signatures on the assertion, check audience restrictions and time windows, and never trust unsigned assertions. Use a maintained library, not a hand-rolled XML parser.
• Metadata drift. SAML certificates expire. Put the renewal date in a calendar or, better, monitor it.
• No offboarding path. Decide what happens to a user’s data and sessions when the identity provider says they are gone.
• Mixing authentication with roles. Covered above, and worth repeating because it is the most expensive mistake to undo.

When your product talks to other systems

Login is only one part of the picture. Integrations such as mailboxes, CRMs and shops usually need OAuth for delegated access or API tokens for service accounts. For a concrete look at how automated clients obtain tokens and register themselves, see this walkthrough of API tokens and self-registration for automated mailboxes. Whatever the system, keep the same discipline: short-lived tokens, narrow scopes, and a clear owner for each credential.

What this means for a startup or SME in Switzerland

A short, opinionated summary:

• Building a new web or mobile product? Start with OIDC through a reputable identity layer.
• Selling to larger companies or authorities? Plan for SAML 2.0 as well, and design your user model so that identity provider, user and role are separate concepts.
• Connecting to third-party APIs? Use OAuth 2.0 with PKCE and least-privilege scopes.
• Handling personal data of Swiss residents? Document what data goes where, and get the DSG questions answered in parallel with the technical work, not after.

The cost of getting this wrong is rarely a dramatic breach. More often it is a rewrite when the first enterprise customer asks for SSO and your user model cannot support it.

How Ampersand can help

We are a small Zurich studio, and senior engineers stay on a project from the first conversation to handover. That matters for authentication work, where early decisions about user models and integrations are costly to reverse. We build websites, web applications and platforms, handle system integrations and API connectivity, and offer senior-led technical consulting, audits and part-time CTO support. If you are deciding between SAML, OIDC and OAuth for a product, or need an existing login setup reviewed, see our services and plans. Our Guidance plan is listed at 799 CHF per month and Run & monitor at 750 CHF per month; other offers are scoped per project. You can also look at our work to see the kind of systems we deliver.

FAQ

What is the main difference between OAuth and SAML?

OAuth 2.0 is an authorization framework: it lets an app access an API with limited permissions. SAML 2.0 is an authentication standard that signs users into applications via an identity provider. They overlap only loosely, which is why OIDC, built on OAuth, is the closer match to SAML for login.

Should I use SAML or OIDC for a new application?

For most new products, OIDC is the simpler choice, since it works well for web, mobile and APIs and uses JSON. Add SAML when a customer’s IT environment requires it. If you sell mainly to large organizations, plan for SAML from the start.

Does OAuth handle authentication?

Not by itself. An OAuth access token says an app may do something, not who the user is. For authentication, use OpenID Connect, which adds a signed ID token.

Do Swiss government services support both protocols?

Yes. AGOV documents OIDC and SAML 2.0 as supported ways to connect applications. It provides authentication but not roles or permissions, so your application handles access management. Check the official integration specification before you build.

Does using SSO make my cloud setup compliant with the DSG?

No. The login protocol is a technical choice, while the DSG concerns how personal data is processed and who is responsible. The data protection commissioner’s cloud guidance says the customer stays responsible when a provider processes data for them, so assess the risk and put the right agreements in place.

Sources

• OAuth 2.0 vs OpenID Connect vs SAML: What’s the Difference? (GoLinuxCloud)
• The OAuth 2.1 Authorization Framework, Internet-Draft (IETF)
• AGOV in Cloud-, SaaS- und Hyperscaler-Architekturen
• Informationen für Behörden (AGOV)
• Cloud-Computing (FDPIC)
• Bundesgesetz über den Datenschutz, AS 2022 491 (Fedlex)