Introduction
As enterprises increasingly deploy AI agents to automate complex workflows, a fundamental question arises: how do these autonomous software entities prove who they are and what they are allowed to do? Unlike human users who can type passwords and approve consent screens, AI agents must authenticate and authorize themselves through purely programmatic means.
The answer lies in the same foundational protocols that have secured the web for over a decade — OAuth 2.1 and OpenID Connect (OIDC). These standards provide a robust, well-understood framework for issuing, validating, and managing the tokens that serve as an agent's digital credentials. This article, the first in our five-part series on Architecting Identity for Agentic AI, lays the groundwork by exploring these protocols through the lens of machine identity.
What You Will Learn
- How OAuth 2.1 provides delegated authorization for AI agents through time-limited, scoped tokens
- The role of OpenID Connect in adding an identity layer on top of OAuth, and when agents do (and do not) receive ID tokens
- The two primary grant types — Authorization Code with PKCE and Client Credentials — and when to use each
- The critical distinction between access tokens (authorization) and ID tokens (authentication)
- How human identity flows differ from AI agent flows in interaction model, credential types, consent, and token issuance
Identity for AI Agents in the Enterprise
In the modern enterprise, AI agents are no longer simple chatbots responding to user queries. They are autonomous software entities that call protected APIs, orchestrate multi-step workflows, access sensitive data stores, and make decisions — all without a human sitting at the keyboard. This introduces identity challenges that go far beyond traditional application security.
Authentication
Verifying the agent's identity without any user involvement. The system must confirm that the agent is who (or what) it claims to be using cryptographic credentials rather than interactive login flows.
Authorization
Ensuring agents access only the resources they are explicitly permitted to use. The principle of least privilege is critical when autonomous agents can act at machine speed across many systems simultaneously.
Audit & Lifecycle
Treating agent identities as manageable entities with full lifecycle support — provisioning, credential rotation, activity logging, deprovisioning. Every action an agent takes must be attributable and auditable.
In practice, enterprises represent AI agents in their identity infrastructure using service accounts or registered OAuth clients. A service account is a non-human account in an identity provider that represents the agent, while a registered OAuth client is an application registration that gives the agent a client ID and credentials to use in OAuth flows. Both approaches integrate agents into existing identity governance frameworks so they can be managed alongside human identities.
The Digital Employee Mindset
OAuth 2.1 Fundamentals for Secure Access
OAuth 2.1 is the industry standard protocol for delegated authorization. Rather than sharing credentials directly, it enables a client (the AI agent) to obtain time-limited, scoped access tokens from an authorization server. These tokens act as permission slips that grant access to specific resources for a limited duration.
Core OAuth Roles
Client (AI Agent)
Resource Server (API)
Authorization Server / IdP
Resource Owner
Two Primary Grant Types
OAuth 2.1 consolidates and simplifies the grant types from OAuth 2.0. For AI agent scenarios, two grant types dominate:
Authorization Code + PKCE
Interactive / DelegatedUsed when an agent acts on behalf of a user. The user authenticates in a browser and grants consent. The agent receives tokens representing both the user's identity and the granted permissions. PKCE (Proof Key for Code Exchange) protects against authorization code interception attacks.
Client Credentials
Machine-to-MachineUsed when an agent operates autonomously without any human user in the loop. The agent authenticates directly with its own credentials (client ID + secret or certificate) and receives an access token for its own permissions. No user login, no consent screen, no ID token.
Scopes: Defining the Permission Boundary
Scopes are strings that specify the exact permissions an access token carries. They define what the agent can do with the token and are the primary mechanism for enforcing least privilege. Examples include read:orders, write:inventory, or admin:users.
In human flows, users typically approve scopes via a consent screen. In machine-to-machine flows, scopes are pre-approved by an administrator during client registration. The authorization server will only issue tokens with scopes that the client has been explicitly authorized to request.
OpenID Connect and Identity Tokens
While OAuth 2.1 handles authorization (what can be accessed), it does not inherently answer the question of identity (who is making the request). This is where OpenID Connect (OIDC) enters the picture. OIDC is a thin identity layer built on top of OAuth 2.0/2.1 that introduces the concept of an ID token — a standardized way to communicate the authenticated identity of a user.
What Is an ID Token?
An ID token is a JSON Web Token (JWT) issued by the authorization server that encodes the authenticated user's identity. It contains claims such as the user's unique identifier (sub), name, email, authentication time, and issuer. Crucially, the ID token is intended for the client application only — it should never be sent to APIs as an authorization credential.
Do AI Agents Get ID Tokens?
It depends on the flow. Autonomous agents using Client Credentials typically do not receive ID tokens because there is no user identity to represent. However, agents acting on behalf of users using the Authorization Code flow will receive both an ID token (representing the user) and an access token (representing the granted permissions).
ID Token vs. Access Token: The Key Distinction
The ID token answers: "Who authenticated?" — It is consumed by the client to understand the user's identity.
The access token answers: "What is permitted?" — It is presented to resource servers to gain access to protected resources.
Authorization Code Flow with PKCE
The Authorization Code flow with PKCE is the recommended OAuth 2.1 flow for scenarios where an AI agent needs to act on behalf of a human user. The user authenticates through their browser, grants consent, and the agent receives tokens that represent the delegated authority. PKCE (Proof Key for Code Exchange) adds a cryptographic challenge-response mechanism that prevents authorization code interception attacks, even for confidential clients.
Authorization Code Flow with PKCE
Interactive flow for agents acting on behalf of users
Authorization Request + PKCE Challenge
The client generates a random code_verifier and derives a code_challenge (SHA-256 hash). It redirects the user to the authorization endpoint with the code_challenge, response_type=code, client_id, redirect_uri, scope, and state.
User Authentication & Consent
The authorization server authenticates the user (login prompt) and presents a consent screen listing the scopes requested. The user approves or denies access.
Authorization Code Issuance
Upon user consent, the authorization server redirects back to the client's redirect_uri with a short-lived authorization code and the original state parameter for CSRF protection.
Code-to-Token Exchange + PKCE Verifier
The client sends the authorization code along with the original code_verifier to the token endpoint. The server hashes the verifier and compares it to the stored code_challenge to prove the same client is exchanging the code.
Tokens Issued (ID Token + Access Token)
Upon successful verification, the authorization server returns an access token (for API access), an ID token (for identity), and optionally a refresh token. The ID token is a signed JWT containing the user's identity claims.
Resource Access with Access Token
The client presents the access token in the Authorization header (Bearer token) when calling protected APIs. The resource server validates the token (signature, expiration, audience, scopes) before granting access.
Security Guarantee
Client Credentials Flow (Machine-to-Machine)
The Client Credentials flow is the workhorse for autonomous AI agent operations. When an agent needs to access an API on its own behalf — with no user involved — it authenticates directly with its own credentials and receives an access token. This is the simplest and most common flow for machine-to-machine communication.
Client Credentials Flow (Machine-to-Machine)
Autonomous agent flow with no user interaction
Direct Token Request with Client Credentials
The confidential client sends a POST request to the token endpoint with grant_type=client_credentials, its client_id, client_secret (or certificate), and the desired scope and audience parameters.
Client Authentication
The authorization server verifies the client's credentials. Only confidential clients (those that can securely store secrets) are allowed to use this flow. The server checks the client_id and client_secret against its registry.
Scopes & Audience Validation
The server validates the requested scopes against what the client is authorized to request (pre-configured by an admin). It also validates the audience parameter to ensure the token will be bound to a specific resource server.
Access Token Issued (No ID Token)
The server returns an access token with the approved scopes. No ID token is issued because there is no user identity involved — this is pure machine-to-machine authentication. The token is short-lived (typically 15-60 minutes).
Resource Access with Access Token
The agent uses the access token as a Bearer token in the Authorization header to call protected API endpoints. The resource server validates the token's signature, expiration, audience, and scopes before responding.
Access tokens are typically valid for 15 to 60 minutes. The agent requests a new token when the current one expires, limiting exposure from any single compromised token.
Each token carries only the specific scopes the agent needs for its immediate task. Administrators pre-configure the maximum allowed scopes during client registration.
Only clients that can securely store secrets (server-side applications) may use this flow. The client secret must be protected with the same rigor as any other sensitive credential.
Access Tokens vs. ID Tokens
Understanding the distinction between access tokens and ID tokens is one of the most important concepts in OAuth and OIDC. Despite both being tokens issued by the authorization server, they serve fundamentally different purposes, have different audiences, and should never be used interchangeably.
Access Token
Authorization: What can be done
Typical Claims
isssubaudexpiatscopeclient_idjtiCharacteristics
- Represents authorization — the permissions granted to the client
- Audience is the resource server (API) — this is who should validate it
- Contains scopes and permissions that define what actions are allowed
- Short-lived: typically 15 minutes to 1 hour
- May be a JWT or an opaque reference token (implementation varies)
- Sent to APIs in the Authorization header as a Bearer token
- Issued in both Authorization Code and Client Credentials flows
ID Token
Authentication: Who is this
Typical Claims
isssubaudexpiatauth_timenoncenameemailCharacteristics
- Represents authentication — proof of the user's identity
- Audience is the client application — only the client should consume it
- Always a JWT, signed by the identity provider's private key
- Contains identity claims: name, email, unique subject identifier
- Should NEVER be sent to APIs as an authorization credential
- Only issued in Authorization Code flow (when a user is involved)
- NOT issued in Client Credentials flow (no user identity to represent)
Access Token Purpose
Grants access to specific resources. The token tells the API: 'This client has been authorized to perform these actions.'
ID Token Purpose
Proves user identity to the client. The token tells the app: 'This user has authenticated and here is their identity.'
Audience Matters
Access tokens are for resource servers. ID tokens are for clients. Mixing these up creates security vulnerabilities.
Lifecycle Differences
Access tokens are short-lived and frequently refreshed. ID tokens are consumed once at login and typically cached by the client.
Audience Restriction and Token Audience
The aud (audience) claim is a critical security mechanism in both access tokens and ID tokens. It specifies the intended recipient(s) of the token, creating a binding between the token and the service it was meant for.
Why Audience Restriction Matters
Without audience restriction, a token obtained for one API could be reused against a completely different API — a confused deputy attack. For example, if an agent receives a token for the Inventory API and that token has no audience restriction, a malicious service receiving that token could replay it against the Payments API.
// Correct: Token with "aud": "https://api.inventory.example.com"
// This token is ONLY valid at the Inventory API.
// The Payments API would reject it because it is not the intended audience.
- Access tokens: The 'aud' claim identifies the resource server (API) the token is intended for. The resource server MUST verify that its own identifier appears in the audience before accepting the token.
- ID tokens: The 'aud' claim identifies the client application that requested authentication. The client MUST verify the audience matches its own client_id.
- Scope restrictions complement audience: Even within the intended audience, scopes further limit what specific operations the token allows.
- Multiple audiences: A token can be issued for multiple audiences, but this should be used sparingly as it expands the blast radius of a compromised token.
Human Identity Flows vs. AI Agent Flows
While the underlying protocol machinery is shared, the way OAuth and OIDC are used differs significantly between human users and AI agents. Understanding these distinctions is essential for architects designing identity infrastructure that must support both.
Interactive — user present in the browser to log in, approve consent, and perform MFA challenges.
Automated — no user present. The agent operates autonomously using pre-configured credentials.
Authorization Code Grant with PKCE — redirects the user through a browser-based login experience.
Client Credentials Grant — direct server-to-server token request with client ID and secret.
Identity + Authorization — establishes who the user is and what they are permitted to do.
Service Authorization — confirms the client (agent) itself is allowed to access the resource.
Passwords, biometrics, passkeys, MFA tokens — credentials the user knows, has, or is.
Client secrets, mTLS certificates, private keys — cryptographic credentials stored securely.
User consent — the user actively reviews and approves what the application can access.
Admin pre-approval — an administrator configures allowed scopes during client registration.
ID Token + Access Token (+ optional Refresh Token) — identity and authorization combined.
Access Token only — no ID token since there is no user identity to represent.
"Who is the user and are they allowed?"
"Is this client (agent) itself allowed?"
Human flows answer "Who is the user and are they allowed?" whereas machine flows answer "Is this client (agent) itself allowed?"
Hybrid Scenarios
Conclusion
OAuth 2.1 and OpenID Connect provide the foundational building blocks for integrating AI agents into enterprise identity infrastructure. The key takeaways from this first article in our series:
Agents Are Digital Employees
Treat AI agents with the same identity rigor as human users — authentication, authorization, audit, and lifecycle management.
OAuth 2.1 Is the Foundation
Delegated authorization through time-limited, scoped tokens gives agents secure access without credential sharing.
Two Flows, Two Purposes
Authorization Code + PKCE for delegated user access; Client Credentials for autonomous machine-to-machine operations.
Tokens Have Distinct Roles
Access tokens authorize actions at APIs. ID tokens prove identity to clients. Never confuse or interchange them.
Scope and Audience Containment
Enforce least privilege through narrow scopes and audience-restricted tokens to limit blast radius.
Standards-Based Approach
Building on proven, widely-adopted standards means leveraging existing tooling, expertise, and security audits.
With these fundamentals in place, the next article in this series — Part 2: Wiring MCP to Your IdP — shows how to connect Model Context Protocol servers to your enterprise Identity Provider using OAuth 2.1, maintaining clean role separation between the authorization server and resource server.
Continue Reading This Series
Explore Related SecureAuth Solutions
Ready to transform your identity security?
See how SecureAuth's Continuous Authority platform can protect your organization.
About SecureAuth
SecureAuth provides identity and access management solutions that enable enterprises to implement customized, resilient authentication infrastructure. Through Continuous Authority, flexible deployment options, and deep composable capabilities, SecureAuth helps organizations defend against modern identity threats while maintaining usability and operational efficiency.