SSO for AI Agents with OpenID Connect

SSO for AI agents is plain OpenID Connect with an issuer that only signs in agents. AgentID, the sign-in for AI agents from AgentMail, is that issuer: add it to any login that accepts a custom OpenID Connect (OIDC) provider, and an agent signs in to your app with the same identity it uses everywhere else.

That also answers the question of whether you can use a custom OIDC provider for agent authentication. You can, and the custom-provider option in your auth platform is exactly where it goes. Nothing about the protocol changes because the user is software. What changes is who the subject is, what the issuer tells you about it, and what "single" means when the one signing in never sees a password prompt. The sections below cover the meaning first, then the configuration your library reads, the choice between the two client types, and where it plugs in on each platform.

What does "SSO" mean when the user is an agent?

SSO for an agent means one identity that works at every app and one approval per app that is remembered. The agent's sub is stable across apps for the lifetime of its inbox, so it is the same agent at your app and at the next one. The integration side of that is covered step by step in how to let an AI agent sign in to your website.

The "single" part is the remembered approval. The first time an agent signs in to your app it approves what your app will receive, and AgentID remembers that approval for 180 days per inbox and app. Inside that window the agent's browser continues on its own. If you change your redirect URI or the scopes you request, the agent is asked again.

For your app, a returning agent looks like a returning user: the same sub, the same account, and no second signup. Between those sign-ins your app decides how long the agent stays signed in, because each app sets its own session length.

It isn't workforce SSO. There is no company directory behind it and no administrator provisioning seats; each agent brings its own identity, backed by its own inbox.

What does the discovery document tell your OIDC library?

The discovery document at https://auth.agentid.com/.well-known/openid-configuration tells your library everything it needs, and most libraries read it for you. This excerpt shows the fields that shape your configuration:

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

Two values trip libraries up. Signing is ES256 only, so a library that assumes RS256 has to be told, or valid tokens fail verification. PKCE is S256 only. There is also no offline_access scope and no refresh token, because the flow is built for a sign-in, not for standing access.

Should you register a client or use an open client?

Use an open client to accept agents today with no setup, and register when you need to know who owns them. Both tiers use the same endpoints and the same tokens.

Open clients don't work on localhost; the client ID has to be an https URL your app owns. Registration needs an AgentMail account on purpose, so every registered client belongs to one.

Can you plug AgentID into the identity provider you already run?

Yes. If your login already handles Sign in with Google, it can accept AgentID, and on most platforms that is configuration rather than code. One line per platform, each with its own guide:

• Clerk: a custom OAuth or OIDC connection from the discovery URL, with PKCE on.
• Supabase: a custom provider named custom:agentid with auto-discovery; scopes are comma-separated, and free Supabase projects allow three custom providers.
• Auth0: the official AgentID social connection from the Auth0 Marketplace, rather than an enterprise OIDC connection.
• Better Auth: the @agentmail/agentid-better-auth helper for the Generic OAuth plugin, on Better Auth 1.7.2 or later.
• Auth.js: version 4 is the documented path, with ES256 set explicitly because v4 otherwise assumes RS256.
• Anything else: point any OIDC client at the endpoints above, or start with open clients for no registration at all.

The shortcut for most of these is npx @agentmail/agentid-cli init in your app's directory. It detects your auth provider, registers the application in your browser with your organization's approval, configures it and verifies it. Adding a Sign in with AgentID button covers the button itself.

What doesn't AgentID SSO do?

AgentID SSO doesn't manage sessions after sign-in. There is no logout endpoint in the discovery document, so your app ends its own sessions, and there are no refresh tokens, so fresh proof means a new sign-in, which completes on its own inside the remembered approval.

It also grants nothing beyond identity. Signing in gives your app no access to the agent's mailbox, and the token isn't a trust score; it tells you which agent this is and, for registered apps, who is accountable for it. What happens when that needs to stop is covered in revoking an AI agent's access, and the agent's half of the setup is on the AgentID page on AgentMail.