WorkOS Proposes auth.md Agent Registration Protocol Built on OAuth Standards

WorkOS has proposed auth.md, a small Markdown — based agent registration protocol built on OAuth discovery and JWT verification.

WorkOS has proposed auth.md, an open agent registration protocol built on OAuth standards that gives autonomous agents a structured way to obtain scoped credentials without a human filling out forms. The proposal addresses a common gap: web authentication typically assumes a human in a browser, so teams today instead issue broad, hard-to-audit API keys or session tokens to support agents. If adopted, auth.md aims to make agent onboarding auditable and credential issuance more narrowly scoped.

auth.md is defined as a small Markdown file an app publishes at a well-known location (for example https://service.com/auth.md). As plain text it is intended to serve both as human documentation and as a runtime artifact agents can fetch programmatically. Discovery is a two-step process: machine — readable Protected Resource Metadata (PRM) is published at /.well-known/oauth — protected-resource and points to the Authorization Server metadata at /.well-known/oauth — authorization-server, which in turn carries an agent_auth block describing supported flows and key URIs.

The agent_auth block lists register_uri, claim_uri, revocation_uri, and identity_types_supported so agents can learn how to interact with the service. Services are also expected to return a WWW — Authenticate: Bearer resource_metadata="..." header on 401 responses so agents can bootstrap discovery from an unauthorized request and then follow the referenced metadata.

auth.md defines two primary registration flows apps can support. The agent — verified flow relies on an agent identity provider — the proposal cites examples such as OpenAI, Anthropic, and Cursor. In that flow, an agent requests an audience — specific JAG from its provider and then POSTS it to the app’s /agent/auth endpoint. The app decodes the JAG header (kid, alg), looks up the issuer in its trusted providers list, fetches the provider’s JWKS, verifies the signature and claims (aud, exp, iat, jti, client_id), and returns credentials synchronously.

WorkOS frames this pattern as mirroring just-in-time provisioning used with OIDC and SAML while binding issued credentials directly to an agent identity rather than to a human session. That binding is intended to tighten the link between a verified agent and the scoped credentials it receives.

The user-claimed flow is an OTP-based path that requires no provider participation. It uses two endpoints — /agent/auth/claim to trigger the OTP email and /agent/auth/claim/complete to submit the one-time code. There are two start variants: an anonymous — start variant where the agent receives a credential immediately (scoped to pre-claim permissions) and later upgrades in place after the OTP ceremony, and an email — required variant where the credential is withheld until the user completes the OTP step.