What Is OIDC for AI Agents?

AI agents already sign up for SaaS products, open support tickets, and hold accounts that look like users. Most of them do it by borrowing a human password or a shared API key. The receiving app then cannot tell which agent arrived, how many agents one person runs, or who to call when something goes wrong.

OpenID Connect was built to answer a simpler question: who is this person. That model assumes a browser, a password or passkey, and a click on Approve. Agents break those assumptions. They run without a person watching, they talk to many apps, and treating them as the owner hides the agent behind someone else's account.

OIDC for AI agents keeps the same protocol shape and changes the subject. The agent is the account. The human becomes an accountable claim the app can read when it needs to. The rest of this guide defines that idea, separates identify from authorize, walks the claims a good token carries, and shows how verification works before naming one live provider.

What is OpenID Connect, in one minute

OpenID Connect is a thin identity layer on top of OAuth 2.0. OAuth answers what a client may access. OpenID Connect answers who authenticated. The answer arrives as an id_token: a signed JSON Web Token with standard claims such as issuer, subject, audience, and expiry.

An app that already accepts Sign in with Google already speaks this shape. It redirects to an authorization endpoint, exchanges a code at a token endpoint, and checks the id_token against the issuer's published keys. The protocol is the same whether the subject is a person or an agent. What changes for agents is who that subject names and which extra claims travel with it.

Why traditional OIDC assumes a human in the loop

Classic OIDC flows were designed for people. The client opens a browser. Someone types credentials or taps a passkey. Someone reads a consent screen and clicks Approve. Session cookies and long refresh windows assume that person will come back.

Agents do not fit that loop cleanly. A headless agent has no person staring at the screen. Three agents owned by the same human look identical if they all share that human's sub. Revoking the human locks out every agent and the person at once. Rate limits keyed on a person cannot cap how many agents one owner spins up.

That is why "use OIDC unchanged" is incomplete advice for agents. The protocol works. The human-centric assumptions around login UX, subject identity, and accountability do not.

What OIDC for AI agents actually means

OIDC for AI agents means the agent is a first-class subject of an OpenID Connect issuer. The id_token's sub names the agent, not the owner. Verification still uses discovery, JWKS, audience, and expiry. Apps still add the issuer as a custom OIDC provider next to Google or GitHub.

The identity community also discusses extensions sometimes called OIDC-A: agent-specific claims, attestation, and delegation chains. Those proposals matter for research and standards work. In practice today, "OIDC for AI agents" usually means running standard OIDC with agent subjects and agent-aware claims, then verifying the tokens the way you already verify people.

Two questions separate a real agent identity from a borrowed one. Can the app tell agents apart when they share an owner? Can the app learn who is accountable without treating the owner as the login subject?

OAuth vs OpenID Connect for agents (authorize vs identify)

OAuth authorizes. It issues access tokens that let a client call an API within a scope. OpenID Connect identifies. It issues an id_token that says who authenticated for this client.

Agents need both, and mixing them up causes bad designs. An access token to a calendar API does not tell your SaaS who the agent is at signup. An id_token that names the agent does not by itself grant mailbox or database access. Identify first so the app can create an account, apply policy, and attribute actions. Authorize second for each resource the agent should touch.

If you are deciding whether OAuth alone is enough to verify an agent at your login page, start with whether OAuth is enough to verify an AI agent. This page stays on the identity half: how OpenID Connect names the agent.

Principal vs delegate: who is the subject of the token

A principal is the account the token is about. A delegate acts on behalf of someone else and carries the other party's identity as the subject.

Most "agent auth" products today put the human in sub and treat the agent as a client or vault that fetches short-lived access tokens for that human. That is the delegate model. It fits agents you build for your own users inside one tenant.

The principal model flips it. The agent's sub is the subject. The human appears as an owner claim when the app asks for it. The app can rate-limit, allowlist, and revoke per agent, and still know who stands behind the fleet. For category vocabulary around agent ID, principal, and related terms, see what an agent ID is.

Neither model is wrong. They answer different questions. OIDC for AI agents, in the sense this page uses, is the principal model expressed with standard OpenID Connect.

What a good agent id_token carries

A useful agent id_token still carries the ordinary envelope: iss, sub, aud, iat, exp, and usually jti. Beyond that, agent-aware issuers add signals apps can enforce.

Look for a claim that marks the actor as an agent, not a person. Look for a verified email or other reachable address belonging to the agent. Look for a stable sub that survives across apps for that agent's lifetime. For registered apps that need accountability, look for owner claims such as owner_sub, owner_name, or owner_email, granted only when requested and only to clients allowed to ask.

Ungranted claims should be omitted, not nulled, so apps test for presence. Owner claims must never arrive on an open client that was never approved to see them. A token that names the agent without saying it is an agent leaves your policy code guessing.

Here is the shape of a registered-client id_token from AgentID, the OpenID Connect provider for AI agents from AgentMail. Open clients never receive the owner fields; their aud is a URL they own, not an issued client id.

{  "iss": "https://auth.agentid.com",  "aud": "b7d41e0a-2c65-4f8b-9d31-0a5e7c2f4b18",  "sub": "lM9vT2aR7sK4qN8wE1xC6bY0uF3hJ5pD9gL2zV7oA4Q",  "actor_type": "agent",  "scope": "openid email profile owner_profile owner_email",  "email": "support@acme.agentmail.to",  "email_verified": true,  "name": "Acme Support",  "preferred_username": "support_acme-agentmail-to",  "owner_sub": "oW7xN2pQ4mT8vL1kR6sC9dF3gH5jB0aE2uY4zI6nP8A",  "owner_name": "Maya Chen",  "owner_email": "maya@acme.com",  "iat": 1767225000,  "exp": 1767225600,  "jti": "9f1c2a44-3e77-4c19-9a2e-6b0d5f8e1c33"}

actor_type is always the literal "agent". email is the agent's inbox, verified when the token is minted. owner_email appears only for registered apps that requested that scope.

How apps verify it (discovery, JWKS, aud, exp)

Verification is the same checklist you already run for human OIDC providers, then applied to an agent subject. Work through these checks in order:

1. Fetch the issuer's discovery document and read jwks_uri, authorize, and token endpoints.
2. Exchange the authorization code at the token endpoint (authorization code + PKCE in the usual case).
3. Validate the id_token signature against the JWKS keys for that issuer.
4. Check iss matches the expected issuer, aud matches your exact client_id, and exp is still in the future.
5. If you sent a nonce, confirm it echoes back.

AgentID publishes discovery at the standard well-known URL. The live document advertises authorization code only, response type code, PKCE method S256, and ES256 for id_tokens:

{  "issuer": "https://auth.agentid.com",  "authorization_endpoint": "https://auth.agentid.com/v0/authorize",  "token_endpoint": "https://auth.agentid.com/v0/token",  "jwks_uri": "https://auth.agentid.com/v0/jwks.json",  "userinfo_endpoint": "https://auth.agentid.com/v0/userinfo",  "grant_types_supported": ["authorization_code"],  "response_types_supported": ["code"],  "code_challenge_methods_supported": ["S256"],  "id_token_signing_alg_values_supported": ["ES256"],  "scopes_supported": ["openid", "email", "profile", "owner_profile", "owner_email"]}

Tokens from this issuer last ten minutes. There are no refresh tokens. Apps that need a live check of owner claims or revocation within that window call /userinfo with the access token. That endpoint re-checks live state, so a revoked inbox shows up before the id_token expires.

Where AgentID fits (one live OpenID Connect provider for agents)

AgentID is a standard OpenID Connect provider from AgentMail that lets an AI agent sign in to apps with its own verified email address instead of borrowing its owner's account. Apps that add it get a stable identifier for each agent and, if they register, the name and email of the human who owns it.

It slots into Clerk, Supabase, Auth0, Better Auth, Auth.js v4, or any OIDC stack as configuration in most cases. Open clients use a URL they own as client_id and never receive owner scopes. Registered clients are created in the AgentID console or with the CLI, get a client secret, and may request owner_profile and owner_email.

If a sign-in asks for owner data and the agent's key lacks share-owner permission, the agent cannot finish alone. The organization owner approves instead. The app never receives a token that silently lacks the owner claim it required.

The longer product walkthrough, including PKCE, client tiers, scopes, and threat model, is the complete OIDC for AI agents guide on agentid.com. For how "agent identity provider" sits next to directories and registration protocols, see what an agent identity provider is.

What AgentMail does not do

AgentID does not prove an agent is safe or well-behaved, and a token is not a trust score. It does not grant mailbox access: sharing an address is identity, not permission to read or send mail. It does not issue refresh tokens or support offline_access, and it does not offer password login.

Revoking a key does not sign the agent out of apps. There is no revocation webhook and no back-channel logout, so an issued id_token stays valid until its ten-minute expiry unless the app re-checks /userinfo. Open clients never receive owner name or email, and there is no bulk revoke-all endpoint for every key in an organization.

What this explainer skips

The goal here is the category definition: what OIDC for AI agents means, why human OIDC assumptions break, how identify differs from authorize, and what to check in a token. It is not a protocol reference, not a step-by-step integration for every auth platform, and not a vendor roundup.

For discovery fields, lifetimes, and platform setup in one place, use the agentid.com complete guide linked above. For the agent-side connect and authorize flow, use the AgentMail AgentID sign-in docs. For choosing among directories, registration protocols, and portable issuers, use the agent identity provider explainer.

OIDC for AI agents is ordinary OpenID Connect with the agent as subject and the human as an accountable claim. Once that frame is clear, the remaining work is verification and product choice, not a new protocol inventing itself from scratch.