Table of Contents

Abstract 04
Infographics

2-Legged vs. 3-Legged OAuth: Which Flow Do You Need?

TL;DR: The correct OAuth flow depends on who authorizes access. Use 3-legged OAuth when a separate resource owner must approve the request and 2-legged OAuth when the client acts without separate approval. In either case, restrict permissions, keep tokens short-lived, audit issuance and eliminate static secrets where possible.

Aembit Team

Product & Research

Published Aug 2026

Updated Sep 2026

50:1

Non-human to human identities

18

Agent threat classes mapped

0

Long-lived secrets required

2-Legged vs. 3-Legged OAuth
No form · instant

Download the pdf

Free PDF · no email required

Table of Contents

When AI agents start taking real action inside enterprise systems – calling APIs, accessing data, chaining tools – the question of what they’re allowed to do becomes tantamount. This graphic maps the full risk surface so security teams and builders can see it clearly, all at once.

Every known agent threat – 18 of them across five domains – maps into a single tree, with tiers that escalate by blast radius and one root that connects them all: the agent’s identity.

Inside, you will find:

FAQs

You Have Questions? We Have Answers.

What is the difference between 2-legged and 3-legged OAuth?

The distinction concerns who authorizes access. In 3-legged OAuth, a resource owner, usually a user, grants permission to the client. In 2-legged OAuth, the client authenticates directly without a separate user approval step.

Use 3-legged OAuth when an application needs permission to access resources on behalf of a user. The authorization code flow allows the user to grant explicit permission before the application exchanges the authorization code for a short-lived access token.

Use 2-legged OAuth for machine-to-machine access when no separate resource owner needs to approve the request. The client credentials flow is commonly used when a workload, service, application or AI agent accesses another system under its own identity.

PKCE strengthens the authorization code flow by requiring the client that begins the authorization request to prove that it is also completing the token exchange. It is especially important for mobile applications, single-page applications and other clients that cannot safely retain a secret.

An AI agent may use 3-legged OAuth when it accesses resources with a user’s authorization or 2-legged OAuth when it acts under its own application or workload identity. The appropriate flow depends on who authorizes access and whose identity must remain visible throughout the interaction.

Continue Exploring

Our learning center features all the latest resources to deepen your understanding of securing workload access, including how-to guides, videos, webinars, and more.

Workload Identity Federation Resource

What is Workload Identity Federation?

A secret can grant access. It cannot prove which workload is presenting it. Trace how federation changes the equation at scale.
Aembit and CrowdStrike AIDR data sheet for AI agent identity, access control, and content inspection share image

Aembit + CrowdStrike AIDR for AI Agent Security

Aembit and CrowdStrike AIDR combine AI agent identity and MCP access controls with real-time content inspection and enforcement.
Auditing and Governance for Workload and AI Agent Identity

Auditing and Governance in Modern Identity

Aembit turns workload and AI agent access activity into detailed audit trails, policy insights, and operational visibility.