OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) vs auth.md
The map lists them as complementary: sites and agents commonly implement both. OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) is a prerequisite of auth.md.
| OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) | auth.md | |
|---|---|---|
| Lifecycle step | 3 Permit: What may the agent do here? | 3 Permit: What may the agent do here? |
| Answers | How does an agent (or an MCP client acting for it) discover which authorization server protects a resource, and what that authorization server's endpoints and capabilities are, before requesting access? | How does an AI agent register a new account for its user on a service, without a human filling out a sign-up form or an OAuth redirect flow existing to authorize it? |
| Governed by | IETF OAuth Working Group; both are Internet Standards Track RFCs with IETF/IESG consensus | Single vendor (auth-md.com, associated with WorkOS and founder Fabricio Telles); adopted by several named third parties (Resend, Cloudflare, Firecrawl, Alpic, here.now, mailbox.bot) who each publish their own auth.md file |
| Status (issuer's words) | Internet Standard (RFC 8414, published June 2018) and Internet Standard (RFC 9728, published 2025); both are products of IETF consensus, not works in progress | Published protocol specification at auth-md.com/specification; not submitted to IETF, W3C, or any standards body |
| Phase | stable | draft |
| Version | RFC 8414 (2018-06) and RFC 9728 (2025) (2025) | Launched 2026-06, current spec undated beyond launch (2026-06) |
| Form / transport | well-known file | document format |
| Found at | /.well-known/oauth-protected-resource | /auth.md |
| Adoption | unmeasured | claimed — auth-md.com, which lists Resend, Cloudflare, Firecrawl, Ora.ai, here.now, mailbox.bot, agents-txt.com, WorkOS, and Alpic as 'already supported' adopters |
| Evidence | 2 verified, 1 reported | 1 verified, 1 reported |
| Primary use case | Let agents discover my API or service | Delegate a user's authority to an agent |
| Last verified | 2026-10-16 (current) | 2026-10-16 (current) |
| Specification | https://www.rfc-editor.org/rfc/rfc9728.html | https://auth-md.com/specification |
When to use which
- Choose OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) when your question is “How does an agent (or an MCP client acting for it) discover which authorization server protects a resource, and what that authorization server's endpoints and capabilities are, before requesting access?” and you accept its maturity: phase stable, adoption unmeasured.
- Choose auth.md when your question is “How does an AI agent register a new account for its user on a service, without a human filling out a sign-up form or an OAuth redirect flow existing to authorize it?” and you accept its maturity: phase draft, adoption claimed (auth-md.com, which lists Resend, Cloudflare, Firecrawl, Ora.ai, here.now, mailbox.bot, agents-txt.com, WorkOS, and Alpic as 'already supported' adopters).
Read the full articles
- OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization): How does an agent (or an MCP client acting for it) discover which authorization server protects a resource, and what that authorization server's endpoints and capabilities are, before requesting access?
- auth.md: How does an AI agent register a new account for its user on a service, without a human filling out a sign-up form or an OAuth redirect flow existing to authorize it?