Auth Protocols

OAuth 2.0 + PKCE

RFC 6749 + RFC 7636 · Delegated Authorization

AuthZ Only Baseline Standard ▼

Authorization Code + PKCE Flow

01

User/Browser → App (Client)

login request

02

App (Client) → Auth Server

redirect + code_challenge

03

Auth Server → App (Client)

auth code

04

App (Client) → Auth Server

code + verifier

05

Auth Server → App (Client)

access token (bearer)

06

App (Client) → Resource API

bearer token

Key Facts

What it does

→Grants a client app scoped access to a resource on behalf of a user — without the user sharing their password with the app.

→PKCE binds authorization-code redemption to a verifier held by the client, mitigating authorization-code interception. Current OAuth security guidance applies PKCE broadly, including public clients such as SPAs and native apps.

AuthN vs AuthZ

!OAuth 2.0 does not define end-user authentication. Do not treat an access token as proof that a user authenticated to the client. Use OpenID Connect when standardized end-user authentication is required.

AI Relevance

✓Appropriate for user-facing applications where a user delegates access to a client.

✗Not designed for agent-to-agent flows where there is no user present.

Limitations

!OAuth access tokens are commonly bearer tokens unless a sender-constraining mechanism such as DPoP or mTLS is required and validated.

AuthZ Verdict

OAuth 2.0 grants permissions, not identity. If your system needs to know "who is this user," layer OpenID Connect on top. Using OAuth alone and treating the access token as identity proof is a common and dangerous mistake.

OpenID Connect 1.0

Built on OAuth 2.0 · Authentication + Authorization

AuthN + AuthZ Standardized User AuthN ▼

OIDC Flow (Adds ID Token Layer)

01

User → App (Relying Party)

login

02

App → IdP / Auth Server

OIDC auth request

03

IdP → App

authorization code

04

App → Token Endpoint

code + verifier → ID token + access token

05

App → Resource API

access token; API validates its token profile

Key Facts

What it adds over OAuth 2.0

→An ID Token that carries authentication claims for the client. The client must validate its issuer, audience, signature, nonce where applicable, time claims, and flow-specific requirements.

→The ID token includes required claims such as iss, sub, aud, exp, and iat. Other identity or session claims are optional or request-dependent.

AuthN vs AuthZ

✓OIDC standardizes the authentication result for the client. The accompanying OAuth access token authorizes calls to its intended resource; the resource still applies its own policy.

AI Relevance

✓Appropriate when an AI application needs standardized end-user sign-in, session correlation, or authenticated user context at the client.

!Do not forward the ID token as a general-purpose downstream API credential. Pass a resource-specific access token or exchange it through an approved delegation design.

Limitations

!ID token is proof of auth at issuance, not continuous verification. Access token is still bearer-based without DPoP/mTLS binding.

AuthN + AuthZ Verdict

Use OIDC when a client needs standardized end-user authentication. Use the OAuth access token, not the ID token, at resource APIs, and apply resource authorization separately from the login decision.

SAML 2.0

OASIS Standard · Enterprise SSO / Browser Federation

AuthN + AuthZ Browser SSO Focus ▼

SP-Initiated SSO Flow

01

User/Browser → Service Provider (SP)

access protected resource

02

SP → Identity Provider (IdP)

redirect + SAMLRequest (XML)

03

IdP → Browser

authenticate user

04

Browser → SP

POST SAMLResponse (signed XML)

05

SP → Browser

session granted

Key Facts

What it does

→Browser-mediated SSO using signed XML assertions. The IdP vouches for the user to the SP via the browser as a relay.

→The assertion can carry authentication and attribute statements. Roles or groups are inputs to the service provider's authorization policy, not authorization decisions by themselves.

AuthN vs AuthZ

✓AuthN: a correctly validated assertion communicates the IdP's authentication result. AuthZ: attribute statements can inform access control, but the SP must validate the assertion and enforce its own policy.

AI Relevance

✓Acceptable for enterprise AI SaaS login (user SSO into Copilot, Einstein, etc.) where browser federation is the entry point.

✗Not a practical choice for API-level or agent calls — it is browser-bound by design. A non-browser profile (ECP) exists but is rare and not worth adopting for new work.

Limitations

!XML complexity creates real attack surface: XXE injection, signature wrapping attacks. Mature but not simple.

!Existing non-browser profiles can be an interoperability constraint, but SAML is not recommended for new M2M or agent API designs.

AuthN + AuthZ Verdict

SAML is mature and widely supported for enterprise browser SSO. Existing non-browser profiles should be assessed as legacy interoperability requirements; new programmatic or agentic API access should normally use an OAuth-based design.

OAuth 2.0 — Client Credentials

RFC 6749 §4.4 · Machine-to-Machine Authorization

AuthZ Only M2M Standard ▼

Client Credentials Flow

01

Service / Agent

has client identity + authentication method

02

Service → Auth Server

POST client authentication + scope

03

Auth Server → Service

access token

04

Service → Resource API

bearer token in request

05

Resource API → Service

200 OK

Key Facts

What it does

→No user involved. The service authenticates as itself using its own credentials and gets a scoped access token for M2M calls.

AuthN vs AuthZ

→The authorization server authenticates the client using its configured method, then issues an access token representing authorization for the target resource. This grant does not represent an end user.

AI Relevance

✓Appropriate for a service, workload, or agent acting on its own behalf with no resource owner in the grant.

✓Prefer asymmetric client authentication such as private_key_jwt (RFC 7523) or tls_client_auth (RFC 8705) when the authorization server and deployment support it.

✓Use mTLS or DPoP separately when access tokens also need sender constraint. Client authentication at the token endpoint does not automatically bind the resulting token.

Limitations

!If a shared client secret is used, store and rotate it through an approved runtime secret mechanism. Do not commit it or bake it into images.

!A bearer access token remains replayable after theft. Choose lifetime and sender constraint from the threat model; IP allowlists are only a secondary signal.

AuthZ Verdict

Client Credentials is the OAuth grant for a client acting on its own behalf. No user or browser is involved. Use a strong client-authentication method, narrowly scoped access, an explicit audience, and a token-lifecycle policy appropriate to the service.

mTLS — Mutual TLS

RFC 8705 · Service-to-Service / Agent-to-Agent

AuthN Primary High-Assurance M2M ▼

mTLS Handshake + OAuth Token Binding

01

Agent / Service A → Agent / Service B

client cert (TLS handshake)

02

Service B → Service A

server cert (TLS handshake)

03

Both sides verified → Auth Server

cert-bound token request

04

Auth Server → Service A

token bound to cert thumbprint

05

Service A → Resource API

bound token + cert

Key Facts

What it does

→Both client and server present certificates. The TLS peers validate certificate chains and identity under configured trust policies. With RFC 8705 certificate-bound tokens, a stolen token alone is insufficient if the resource server enforces the binding.

AuthN vs AuthZ

✓Strong AuthN at the transport layer via PKI certs. When combined with OAuth, the token binding makes it sender-constrained, adding AuthZ scope.

AI Relevance

✓Useful for workload authentication, LLM orchestration service calls, and agentic pipeline inter-service calls. It is not a substitute for the MCP HTTP authorization flow.

✓Used by FAPI 2.0 as one sender-constraining option. Certificate-bound access tokens reduce reuse of a stolen token because the caller must also prove possession of the private key.

Limitations

!Cert lifecycle management is operationally heavy. Requires PKI infrastructure. Not suited for user-facing browser flows.

AuthN Verdict

mTLS provides high-assurance mutual authentication when certificate issuance, private-key protection, identity mapping, rotation, and revocation are operated correctly. Certificate-bound access tokens add proof of possession, but resource authorization remains a separate decision.

DPoP — Proof of Possession

RFC 9449 · Token Binding Without mTLS

AuthZ + Binding RFC 9449 ▼

DPoP Flow

01

Client / Agent

generate or load a protected keypair

02

Client → Auth Server

token request + DPoP proof JWT

03

Auth Server → Client

token bound to public key

04

Client → Resource API

token + fresh DPoP proof

05

API

verify proof matches token → granted

Key Facts

What it does

→Binds an access token to a client's public key. Each request carries a signed proof, so a stolen token cannot be used without the corresponding private key and an acceptable proof.

vs mTLS

→DPoP works at the application layer without client-certificate infrastructure. Its replay, proxy, key-storage, and deployment properties differ from mTLS; neither mechanism is universally stronger for every threat model.

AI Relevance

✓Useful where bearer-token theft is a material risk and the client can protect the bound private key. It does not protect against compromise of both the token and that key.

Limitations

!Requires compatible authorization-server, client, and resource-server implementations. Proof replay, URI normalization, proxy handling, nonce use, clock skew, and private-key storage need explicit design and tests.

AuthZ + Token Binding Verdict

DPoP is an application-layer sender-constraining option when certificate-bound tokens are unsuitable. Validate proof method, URI, key binding, time, nonce where used, and replay identifiers according to RFC 9449.

FAPI 2.0

Financial-Grade API Profile · High-Assurance OAuth

AuthN + AuthZ High-Security Profile ▼

FAPI 2.0 authorization-code flow

01

Client → Auth Server

PAR: push auth request (back-channel)

02

Auth Server → Client

request_uri (short-lived ref)

03

Client → Auth Server

redirect with client_id + request_uri

04

Auth Server → Client

mTLS or DPoP bound token

05

Client → Protected Resource

bound token + proof

Key Facts

What it is

→A final security profile based on OAuth 2.0 (RFC 6749) and the OAuth Security BCP (RFC 9700). It requires sender-constrained access tokens using mTLS or DPoP. Authorization-endpoint flows additionally require PAR and PKCE.

→PAR sends the authorization request parameters to the authorization server over a back channel, then uses a request URI at the browser-facing authorization endpoint.

AuthN vs AuthZ

✓Strong client and token-holder assurance comes from client authentication and sender-constrained tokens. Resource authorization still depends on scopes, grants, and resource-server policy.

AI Relevance

→Project recommendation: consider FAPI 2.0 for high-value or regulated-data APIs when its attacker model and interoperability profile fit. Handling PHI or PII does not itself create a universal FAPI mandate.

Limitations

!Significant implementation and operational overhead. The authorization server, client, resource server, and key-management processes must conform to the same profile; verify interoperability before adoption.

AuthN + AuthZ Verdict

FAPI 2.0 is a strong option when an ecosystem needs its defined high-security OAuth attacker model and interoperability profile. It is not automatically required by a data classification. Adoption requires compatible authorization servers, clients, resource servers, and operational key management.

MCP HTTP Authorization

MCP 2025-11-25 · OAuth 2.1 Draft Profile · Resource-Bound Tokens

AuthZ HTTP MCP ▼

Discovery and Authorization Flow

01

MCP Client → MCP Server

request; receive 401 + resource metadata location

02

Client → Metadata

discover authorization server (RFC 9728 / 8414 or OIDC)

03

Client → Auth Server

authorization code + PKCE + resource parameter

04

Auth Server → Client

access token intended for canonical MCP URI

05

Client → MCP Server

Bearer token; server validates token + audience

Key Requirements and Scope

Applicability

→Authorization is optional for MCP implementations. When authorization is supported over an HTTP transport, implementations should conform to the MCP authorization specification. STDIO uses its host environment instead of this HTTP flow.

Discovery and Client Registration

✓MCP servers must publish Protected Resource Metadata (RFC 9728). Clients must use it and support authorization-server discovery through RFC 8414 and OpenID Connect Discovery.

→The 2025-11-25 revision says clients and authorization servers should support OAuth Client ID Metadata Documents and may support Dynamic Client Registration. These are not interchangeable requirement levels.

Token Boundary

✓Clients must use PKCE and the RFC 8707 resource parameter. Servers must accept only tokens intended for their canonical resource URI.

✗An MCP server must not pass the token it received from an MCP client to an upstream API. It acts as a separate OAuth client and obtains a separate upstream token.

!mTLS may strengthen workload identity or sender constraint, but it does not replace MCP discovery, audience validation, scopes, or the prohibition on token passthrough.

MCP Authorization Verdict

The MCP HTTP profile is an OAuth resource-server boundary, not merely transport authentication. Pin the specification revision, validate the canonical resource audience, minimize scopes, and exchange rather than forward tokens. Source: MCP Authorization 2025-11-25.

OAuth 2.0 Implicit Flow

RFC 6749 §4.2 · Not Recommended by RFC 9700

Not Recommended Legacy Only ▼

Why It Fails

01

User/Browser → Auth Server

login request

02

Auth Server → Browser

⚠ token in URL fragment

03

Token exposed in:

browser history, scripts, and fragment-processing code

Detection Signal

If you see response_type=token in an OAuth flow, that's implicit. Flag it immediately. Replace with authorization code + PKCE.

Why It Was Replaced

Core Failures

✗The access token is returned through the browser front channel, increasing exposure to browser history, malicious scripts, redirects, and other front-channel leakage paths.

✗The flow lacks the authorization-code redemption step protected by PKCE. RFC 9700 recommends authorization code with PKCE instead.

!If an existing integration uses response_type=token, treat it as migration work and replace it with authorization code plus PKCE.

Replace With

✓OAuth 2.0 Authorization Code with PKCE. The client architecture still determines whether tokens are handled in the browser, a native app, or a backend-for-frontend.

Not-Recommended Verdict

Do not select the implicit grant for a new integration. RFC 9700 says clients should not use it because access tokens in authorization responses are vulnerable to leakage and replay. Use authorization code with PKCE unless a current, reviewed specification defines another flow.

Protocol	AuthN	AuthZ	User Present	Non-user M2M	Token Binding	Browser Required	Use In AI Systems
OAuth 2.0 + PKCE	✗	✓	✓	✗	Optional mTLS / DPoP	✓	User-facing AI apps
OpenID Connect 1.0	✓	Via OAuth access token	✓	✗	Access-token dependent	✓	Identity-aware AI, audit, RBAC
SAML 2.0	✓	Attribute input only	✓	✗	None	✓ Required	Enterprise browser SSO focus
OAuth 2.0 Client Creds	Client authentication	✓	✗	✓	Optional mTLS / DPoP	✗	Agent-to-service, pipelines
mTLS	✓ Strong	Policy-dependent	Optional	✓	With RFC 8705	✗	Workload identity, high-security M2M
DPoP	✗	Token-dependent	Optional	✓	Key-bound	✗	Multi-hop agent pipelines
FAPI 2.0	✓	✓	Optional	✓	mTLS or DPoP	Optional	High-value APIs matching the FAPI attacker model
MCP HTTP Authorization	Authorization-server dependent	✓	Depends on grant	Extension-dependent	Optional extension	For user authorization flow	Remote MCP servers and agent tools
OAuth 2.0 Implicit	✗	Legacy grant	✓	✗	None	✓	Do not use