Blog

Polarising Website

OpenID Connect vs OAuth 2.0: What Each Does and When

Architect comparing two token flow diagrams

OAuth 2.0 and OpenID Connect (OIDC) are not rivals. OAuth 2.0 is a framework for authorisation: it lets an application act on a user’s behalf with limited, scoped access. OIDC is an authentication layer built on top of it: it tells the application who the user is. If you need people to log in, you want OIDC. If you need one system to call another API with defined permissions, you want OAuth 2.0. In most enterprise estates you need both at once, which is why the two names get confused.

This guide is written for CTOs, integration managers and the executives who sign off identity and API decisions. It explains the split, the tokens involved, how SAML fits in, and what to do when AI agents and legacy systems enter the picture.

Polarising
Build Identity Into Your Integrations
Polarising integrates AI systems into business processes with governance and accountability, helping enterprises address complex identity and integration challenges.

Explore AI engineering

Key takeaways

  • OAuth 2.0 answers “what is this application allowed to do?”. OIDC answers “who is this user?”. OIDC is an identity layer on top of OAuth 2.0, so you do not choose one over the other.
  • Using plain OAuth 2.0 as a login mechanism is a common and risky mistake. Use the ID token for identity and the access token for resource access.
  • You rarely have to rip out SAML. Protocol mediation lets modern OIDC applications, including AI systems, sit in front of older SAML identity providers.
  • Treat AI agents as authenticated clients with their own scoped tokens, so every action is traceable and auditable.

Table of Contents

The short version: authorisation versus authentication

The OAuth.net FAQ puts it plainly: OAuth is an authorisation protocol that grants an application access to resources on a user’s behalf, and it says nothing about who the user is. OIDC adds that missing piece.

A useful way to hold the difference:

  • OAuth 2.0 is a valet key. It lets a party park the car without handing over the whole set of keys. It does not record who the driver is.
  • OpenID Connect is the ID check at the desk before the key is issued, plus a signed record of the result.

The formal wording from the OpenID Foundation is that OIDC 1.0 enables clients to verify the identity of the end-user based on authentication performed by an authorisation server, and to obtain basic profile information about them.

OpenID Connect vs OAuth 2.0 side by side

Aspect OAuth 2.0 OpenID Connect
Core purpose Delegated authorisation (access) Authentication (identity), plus access
Main question What can this client do? Who is this user?
Key token Access token (and refresh token) ID token, plus access and refresh tokens
Token format Not defined by the framework: opaque or structured ID token is always a JSON Web Token (JWT)
User information None by default Standard claims and a UserInfo endpoint
Typical use API access, service-to-service calls Single sign-on, “sign in with” buttons, workforce and customer login
Discovery Optional extensions Standard discovery document at /.well-known/openid-configuration

Two points in that table cause most of the confusion in practice. First, OAuth 2.0 does not say what an access token must look like, so an API cannot assume it contains user details. Second, the ID token is meant for the client application, not for the API. Sending an ID token to a backend as proof of permission is a frequent design error.

How the two work together in one flow

When a user signs in to an application using OIDC, the sequence is the familiar OAuth 2.0 authorisation code flow with one addition: the application asks for the openid scope.

  1. The application redirects the user to the authorisation server (your identity provider).
  2. The user authenticates, perhaps with multi-factor authentication, and may be asked to consent to the requested scopes.
  3. The application receives an authorisation code and exchanges it, with a PKCE verifier, for tokens.
  4. For an OIDC authorisation code flow, the response normally contains an ID token (who the user is) and an access token (what the application may call).
  5. The application validates the ID token’s signature, issuer, audience and expiry, and any applicable nonce and authentication-context requirements before creating a session. It uses the access token to call APIs.

The Microsoft identity platform documentation describes the same four roles in both protocols: the authorisation server, the resource owner, the client and the resource server. OIDC changes what the authorisation server returns, not who takes part.

Why OAuth 2.0 alone is not a login system

The pitfall integration managers meet most often is treating a valid access token as proof of identity. An access token represents an authorisation issued to a client for a particular resource or set of resources. It does not prove that the person now using the application is that someone, and it carries no standard way to find out who they are.

The OAuth.net FAQ warns that using OAuth alone as a login mechanism is a common mistake. The fix is to layer OIDC on top: validate the ID token for identity, use the access token only for calling resources. If your team has built a homegrown “login” on raw OAuth, that is the first thing to review.

OAuth access and OIDC identity token roles

Is OAuth 2.0 obsolete? OAuth 2.1 and current best practice

No. OAuth 2.0 remains the basis of API authorisation. What is considered legacy is OAuth 1.0. The direction of travel is OAuth 2.1, which consolidates OAuth 2.0 with the security guidance published since. According to the OAuth.net FAQ, it requires PKCE for all authorisation code flows and removes the implicit and password grants.

For architects, that translates into a short checklist for any new build:

  • Use the authorisation code flow with PKCE for user-facing applications, including single-page and mobile apps.
  • Use client credentials for machine-to-machine calls, with narrow scopes.
  • Do not use the implicit or resource owner password grants in new work.
  • Match redirect URIs exactly, and keep access tokens short-lived.
  • Use OAuth 2.0 client credentials or an appropriate workload identity mechanism for service-to-service communication. Add OIDC where end-user authentication is required; it is not a prerequisite for machine-to-machine authorisation.

Check the current publication status of OAuth 2.1 before citing it as a final standard; the security practices described here can be adopted independently of that status. The practices above are already safe to adopt today.

Where SAML fits: a decision, not a war

Executives often ask the question differently: “Should we move from SAML to OIDC?” Microsoft’s decision guide for SAML and OIDC frames the trade-off by architecture. SAML is an XML-based standard suited to established enterprise federation and regulated settings such as healthcare and government. OIDC is a JSON and JWT-based protocol suited to cloud-native applications, microservices, mobile apps and single-page applications. The same guide notes that most new SaaS and cloud-native integrations now default to OIDC because of its developer experience and framework support.

Consideration SAML 2.0 OIDC (with OAuth 2.0)
Message format XML assertions JSON Web Tokens
Best fit Established enterprise federation, complex attribute needs Cloud-native apps, APIs, mobile, SPAs
API access Not designed for it Native, via access tokens
Developer effort Higher Lower
Attribute handling Strong for deep, nested attributes Simple claims, which can be a limit

The honest answer for most large organisations is both. Your existing workforce identity provider may speak SAML to older internal systems, while new applications and AI services speak OIDC.

Bridging OIDC and SAML instead of replacing SAML

The practical pattern is protocol mediation. A capable identity provider, or a gateway managed within an enterprise integration platform, presents OIDC to modern applications while handling SAML federation with the systems behind it. Nothing has to be ripped out on day one, and governance stays intact during the transition. If you are weighing how to connect systems across regulated finance estates, this overview of financial compliance software integration types shows the kinds of connections that sit behind such decisions.

One caution from the same Microsoft guidance: OIDC’s simplicity is a strength until you need granular, deeply nested attributes. If an application depends on complex attribute mapping, plan to bridge OIDC to SAML rather than expecting OIDC to reproduce SAML’s structure. Inventory your attribute requirements before choosing, not after.

API security: what the standards ask of you

Readers searching for API security best practices and authentication standards usually want a short list. These are the ones that follow directly from the protocols above:

  1. Separate authentication from authorisation. OIDC for identity, OAuth 2.0 scopes for access. Never let the two blur.
  2. Validate every token properly. Check signature, issuer, audience, expiry and, where applicable, the nonce for ID tokens. Fetch signing keys from the provider’s published metadata.
  3. Use PKCE everywhere the authorisation code flow is used, not just on public clients.
  4. Scope narrowly. A reporting service should not hold a token that can write to payments.
  5. Keep tokens short-lived and rotate refresh tokens where the provider supports it.
  6. Automate certificate and key rotation. Manual rotation across hundreds of clients is where outages and audit findings come from.
  7. Log who requested what. Auditability is a design requirement, not a reporting afterthought.

It is also worth knowing that OIDC is not a single trick: it is a suite of lightweight specifications with REST-like APIs, which is why discovery, registration and session management all have their own governance needs at scale.

AI agents: identity is part of integration

AI changes the identity question because software, not just people, now takes actions. Experts quoted in the FIDO Alliance’s enterprise federation guidance stress federation done consistently across providers. Applied to AI, the lesson is that identity and access should not be kept in separate silos.

In practice that means:

  • Register each AI agent as an OAuth 2.0 client with its own credentials, not a shared service account.
  • Issue it access tokens with the narrowest scopes needed for the business process it touches.
  • Record the agent identity, delegated user context where applicable, permissions, decisions and outcomes in tamper-resistant audit logs. Signed tokens alone do not provide a complete audit trail.
  • Revoke or rotate an agent’s credentials without touching anything else.

This is what governance and accountability from the outset looks like at the integration layer. It is also the control that regulators and auditors in finance and healthcare ask about first. For the healthcare angle, our piece on controls CIOs must verify for HIPAA compliant AI goes deeper, and four decisions that make AI system integration enterprise ready covers the wider design choices.

Running OIDC and OAuth 2.0 at enterprise scale

The protocols are simple on a whiteboard. The complexity becomes most apparent in operations. Large estates accumulate hundreds of registered clients, discovery documents, signing keys, claim mappings and policies. Each one needs an owner and a lifecycle.

This is where an integration platform earns its keep. Rather than configuring every API and application by hand, integration and API management capabilities can help apply consistent access controls, but enforcement differs by product and deployment. Boomi and MuleSoft offer API management capabilities; TIBCO and Solace may contribute to messaging and event-driven architectures, where broker authentication, application authorisation and event-level traceability require separate design decisions. Boomi and MuleSoft are widely used for API management and gateway policy, while TIBCO and Solace are common where event-driven messaging carries the traffic, and identity has to travel with each event as well as each API call.

Polarising discusses these integration technologies on its website, and its integration platforms page sets out how we approach each. A sound architecture centralises reusable identity policies where appropriate, while preserving resource-level authorisation checks in each API and service. A gateway cannot replace all application-specific access decisions.

Running OIDC and OAuth 2.0 at enterprise scale — overview diagram

Our perspective: identity belongs in the integration layer

After more than twenty years of engineering, a recurring enterprise challenge is coordinating identity policy across integration boundaries. A login protocol is rarely what fails. What fails is the join between a modern application, a legacy identity provider, an API gateway and an event broker, each configured by a different team.

Three convictions shape how we work:

  • Do not force a clean switch. Legacy estates carry real obligations. We would rather architect a bridge that lets modern OIDC applications coexist with SAML-based systems, and retire the old pieces when the business is ready, than promise a big-bang migration.
  • Bake in traceability. If an AI agent can act on a business process, you should be able to show who or what acted, with what permission, and under which policy. This should be designed into the integration architecture from the outset, rather than added after the first audit.
  • Find the hidden requirements early. The attribute that only one regulated system needs, or the certificate nobody owns, is what breaks a go-live. An expert assessment before design is cheaper than a rework after it.

Our senior nearshore teams in the UK and Portugal work on exactly these joins in finance, healthcare, telecommunications and logistics, where uptime and audit trails are not negotiable.

— Polarising Team

Choosing between them: a practical guide

Use this as a quick decision aid for your next project:

  • You are building a login or single sign-on for people: use OIDC (which runs on OAuth 2.0).
  • You are protecting an API that other applications call: use OAuth 2.0 access tokens with scopes. Add OIDC if the API’s callers also need to know the end user.
  • Two backend services talk to each other: OAuth 2.0 client credentials, with narrow scopes and short-lived tokens.
  • An AI agent acts on business systems: register it as a client, give it scoped tokens, and log its identity, authorisation context and actions independently of token issuance.
  • You have a SAML identity provider that must stay: keep it, and mediate to OIDC for new applications.
  • A system needs complex, nested attributes: assess early, and plan a SAML bridge if OIDC claims will not cover it.

How Polarising can help

If identity and API security are slowing a migration, an AI rollout or an integration programme, we can help you design the target architecture and deliver it. Our enterprise integration services cover API and event platform integration and legacy modernisation, and our agentic AI work covers how AI agents are connected to business systems with governance built in. If you first need to understand what is hiding in an older estate, AI-assisted legacy system analysis is the place to start.

Frequently asked questions

Is OIDC the same as OAuth 2.0?

No. OIDC is built on top of OAuth 2.0 and adds an ID token and standard user claims so that an application can verify who signed in. OAuth 2.0 on its own only grants scoped access to resources. Most modern sign-in flows use both together.

Is OAuth 2.0 obsolete?

No. OAuth 1.0 is regarded as legacy, but OAuth 2.0 is still the basis of API authorisation. OAuth 2.1 tightens it by requiring PKCE and dropping the implicit and password grants, so new builds should follow those defaults.

Which is better, SAML or OpenID Connect?

Neither is better in every case. SAML suits established enterprise federation and complex attribute needs, while OIDC suits cloud-native applications, APIs and mobile. Many organisations run both and use an identity provider or gateway to mediate between them.

Is OIDC the same as JWT?

No. A JWT is a token format. OIDC is a protocol that happens to define the ID token as a JWT. OAuth 2.0 access tokens may also be JWTs, but the framework does not require it.

Can an AI agent use OAuth 2.0 and OIDC?

Yes. OAuth 2.0 can authorise agent access to APIs, while OIDC is useful when an end user must authenticate. Give each agent a distinct workload identity, restrict permissions and retain independent audit logs. Use delegated authorisation where an agent acts for a person.

Sources