Securing Everything: Mapping the Right Identity and Access Protocol (OIDC, OAuth2, and SAML) to the Right Identity

Overview

Identity and access security is built on two fundamental requirements:

• Authentication (AuthN) — who you are, and
• Authorization (AuthZ) — what you are allowed to do.

Every secure system must answer both questions clearly and consistently. In modern architecture, these questions are posed to two primary categories of actors trying to access applications:

• human — Challenged to provide direct credentials or to delegate their authority to another application
• machines — Challenged to prove their own programmatic identity and permissions.

Spanning these requirements and actors, the vast majority of Identity and access patterns align to four common workflows.

Machine

• Machine-to-Machine (OAuth2 Client Credentials)

Human

• Human User Authentication (OIDC)
• Delegated Third-Party Applications (OAuth2 Authorization Code)
• Enterprise SSO Federation (SAML 2.0).

Together, these four workflow models account for nearly all modern enterprise application access patterns.

Some Key Terms — Quick Reference

Before we go into the Identity workflows, lets go over some key terms to get familiar with the Identity and Access jargon.

Core Concepts

AuthN (Authentication) — Establishes identity; verifies who the actor (human or machine) is.

AuthZ (Authorization) — Defines permissions; determines what actions the actor is allowed to perform.

Protocols

OAuth 2.0 — Authorization framework that issues access tokens so applications can securely access APIs on their own behalf or on behalf of a user.

OIDC (OpenID Connect) — Authentication layer built on OAuth 2.0 that introduces ID tokens and standardized identity claims.

SAML (Security Assertion Markup Language) — XML-based federation protocol used primarily for enterprise single sign-on across organizational domains.

FIDO2 / WebAuthn — Modern authentication standard enabling phishing-resistant, passwordless login using asymmetric cryptography and hardware-backed credentials.

OAuth Flows

3LO (Three-Legged OAuth) — User + Client + Authorization Server; used when user identity and consent are involved.

2LO (Two-Legged OAuth) — Client + Authorization Server; used for machine-to-machine communication without human interaction.

Key Roles

IdP (Identity Provider) — System that authenticates identities and issues tokens.

Client — Application, service, or AI agent requesting access to protected resources.

Resource Server — API or system that validates tokens and enforces fine-grained access control.

Resource Owner — Human user whose data or permissions are being accessed.

RP (Relying Party) / SP (Service Provider) — Application that relies on the IdP to authenticate the actor (RP in OIDC, SP in SAML).

Tokens & Security Plumbing

ID Token — Identity token intended for the client to confirm who the user is. To use an analogy, the equivalent of an ID Token is the passport that contains your ID claims.

Access Token — Authorization token sent to APIs to grant specific permissions. Have short-lived TTLs. To use an analogy, the equivalent of an Access Token is the visa that contains your access claims.

Access Token — Authorization token sent to APIs to grant specific permissions. Have short-lived TTLs

Refresh Token — Long-lived credential used to obtain new access tokens without re-authentication.

JWT (JSON Web Token) — Digitally signed JSON token containing identity and authorization claims. ID Tokens are JWTs. Access Tokens could be JWT or opaque

Authorization Controls

Claims — Assertions inside a token (user ID, roles, audience, expiration, etc.).

Scopes — Permission boundaries defining what a client can access. Typically these are claims in tokens

Below is a diagram that illustrates some of the terms above:

Machine-to-Machine (M2M) Authentication

Machine-to-Machine authentication is designed for non-interactive clients — such as microservices, daemons, background jobs, and AI Agents that need to access APIs with their own established identity and permissions.. Unlike human flows, there is no browser and no “user” to provide a second factor. The system must ask the machine to prove its identity programmatically.

The recommended standard for the M2M authentication is the OAuth 2.0 Client Credentials Grant to obtain an Access Token.

M2M Auth is a 2LO flow.

Key Characteristics of M2M

• Identity Verified: The machine/application itself (e.g., a billing service or search agent).
• Token Issued:Access Token only. (No ID Token is issued, as there is no human identity involved).
• Goal: To verify which machine is making the request and grant it permissions to perform tasks independently.

While the OAuth 2.0 Client Credentials flow is the standard, the method of authentication determines the strength of the security posture. There are 4 methods of authentication and as we move from shared secrets to cryptographic binding, we increase the assurance level.

Human User Authentication (OIDC)

This is the standard consumer login where a person is present and interacting with a client application. Direct human authentication is designed for interactive users accessing an application via a browser or mobile device. In this model, the application doesn’t just need permission to act; it needs to know who the user is.

The recommended standard for human user authentication is OpenID Connect (OIDC) built as an identity layer on top of OAuth 2.0. OIDC allows the system to ask the user for proof of identity through a trusted Identity Provider (IdP). Thus,

OIDC = OAuth 2.0 (Authorization — Access Token) + Identity Layer (Authentication — ID Token)

OIDC is a 3LO flow.

Key Characteristics of OIDC

• Identity Verified: The End-User (e.g., a customer logging into a portal).
• Tokens Issued: ID Token (contains user profile info) + Access Token (to call APIs).
• Goal: To establish a secure session and obtain a verifiable “passport” (the ID Token) containing claims like name, email, and subject ID.

The strength of an OIDC implementation is defined by the Authentication Method. As we move up this ladder, we shift from simple knowledge-based proof to cryptographic, phishing-resistant protocols.

Delegated Third-Party Authorization (Third-Party Access)

Delegated authorization is the process of granting a third-party application (an external client) scoped, limited access to a user’s resources without exposing the user’s credentials. This workflow covers scenarios where an application needs limited permission to access a user’s resources, but the application is not the owner of those resources (e.g., a photo printing service accessing your Google Photos, or a calendar app reading your Outlook events, or chatGpt agent needing to access your Confluence pages).

The recommended standard for this workflow is the OAuth 2.0 Authorization Code Flow. It is functionally identical to the OIDC flow, with one critical distinction: the ID Token is not returned (the openid scope is omitted from OIDC request). The user first authenticates with the Identity Provider (IdP) and then explicitly approves the specific permissions requested by the third-party client (e.g., photos.read). The application receives an Access Token representing only those approved permissions, allowing it to act on the user's behalf within those strict boundaries.

The Delegated Authorization flow uses state parameter and PKCE, but not nonce which is used only in OIDC flow (nonce protects ID Token which is not returned in OAuth 2.0 Authorization Code Flow). Nonce is only used when an ID Token is involved, and delegated OAuth 2.0 flows do not return an ID Token. (Refer my OIDC blog to understand state, PKCE and nonce)

Thus, OAuth 2.0 Authorization Code Flow = OIDC without ID Token request

This workflow is a 3LO flow.

Key Characteristics of Delegated Access

• Identity Verified: Technically, the user authenticates with the Resource Server, but the focus is on the user given Consent to the third-party app.
• Token Issued: Access Token. No ID Token is issued.
• Goal: To grant “scoped” access to specific resources without sharing the user’s actual credentials or identity profile.

Enterprise SSO Federation via SAML 2.0 (Human-to-Service SSO)

SAML (Security Assertion Markup Language) is the established XML-based veteran standard for Enterprise Federation. It allows a corporate user to authenticate once with their central Identity Provider (IdP) — such as Ping, or Azure AD — and gain seamless access to external SaaS applications (Salesforce, AWS, Slack) or internal tools without re-entering credentials.

Many enterprise applications — especially heavyweights like AWS Console, Salesforce, ServiceNow, and SAP — rely on SAML 2.0. In this model, when a user attempts to access a Service Provider (SP), such as Atlassian Confluence, the SP redirects the user to the IdP. The IdP then issues a SAML assertion containing user attributes which the SP trusts to verify the user. This is the technology behind the familiar “Tile” experience where enterprise apps appear as “tiles” in your IdP portal.. Because the IdP assigns users to specific applications and exchanges assertions , these apps appear as ready-to-use icons in a corporate portal.

Key Characteristics of SAML

• Identity Verified: The Corporate Identity (Employee/Contractor).
• Token Issued: SAML Assertion (an XML document containing the user’s identity and attributes/roles).
• Goal: To establish a “Circle of Trust” between an Identity Provider (IdP) and a Service Provider (SP) enabling Enterprise SSO for corporate users.

Why SAML Persists in the Enterprise

SAML is older than OIDC but remains widely used because many enterprise platforms were built before modern OAuth/OIDC standards existed. While OIDC is lighter, SAML persists in the enterprise because it is deeply embedded in legacy SaaS integrations and enterprise identity providers, with mature federation trust models already in place. Despite newer protocols like OIDC, its broad vendor support, stability, and long-standing interoperability keep it operationally entrenched. However, it is fundamentally browser-based and XML-driven, relying on front-channel redirects and verbose assertion exchanges that reflect an earlier web architecture. As applications modernize toward API-first, mobile, and SPA-native models, many are gradually migrating to OIDC and OAuth 2.0 for lighter-weight tokens, JSON-based claims, and better support for modern client patterns.

Conclusion: The Right Key for the Right Door

Remember:

• OAuth2 = authorization only
• OIDC = authentication + authorization (OAuth2)
• SAML = Authentication + (attribute sharing which the client can use for determining Authorization)

The selection of the correct identity protocol is not merely a technical detail but a foundational architectural security decision. By mapping each identity type — Human User (OIDC), Machine-to-Machine (OAuth2 Client Credentials), Delegated Third-Party Access (OAuth2 Authorization Code), and Enterprise SSO (SAML 2.0) — to its appropriate protocol, and by standardizing all API-bound access into a single, validated JWT Access Token at the API Gateway, architects create a scalable and trustworthy end-to-end security model. The rise of agentic AI frameworks and protocols like the Model Context Protocol (MCP) transforms AI from passive assistants into active agents. This means robust OAuth 2.0 flows are essential for treating these agents as distinct identities, ensuring their autonomous actions are governed by strict, token-based authorization and the principle of least privilege.