add(well-known): OAuth 2.0 discovery pages — oauth-protected-resource (RFC 9728) + oauth-authorization-server (RFC 8414)#85
Merged
Conversation
Documents the OAuth 2.0 Protected Resource Metadata document — the resource-server counterpart to oauth-authorization-server / openid-configuration. Status optional: it applies only to sites exposing an OAuth-protected resource, so 'ship it before you spec it' is not triggered (our public MCP endpoint is unauthenticated and has nothing to advertise). Relevant now because MCP's authorization spec requires authenticated MCP servers to publish it. Wires relatedSlugs on well-known-overview, openid-configuration, and mcp-and-tool-discovery; adds an 'added' changelog entry and the OG images (new page + four count-driven). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Deploying specification-website with
|
| Latest commit: |
66ef1cf
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://6590f990.specification-website.pages.dev |
| Branch Preview URL: | https://standards-scan-oauth-protect.specification-website.pages.dev |
Completes the OAuth 2.0 discovery set alongside oauth-protected-resource (RFC 9728) and openid-configuration. Covers the plain-OAuth (non-OIDC) authorization server, whose only home in the spec was a passing mention; notes the RFC 8414 vs OIDC path-insertion difference and its place in the 9728 discovery chain. Status optional. Cross-links the trio via relatedSlugs and adds a short orientation paragraph to well-known-overview naming how the three chain together. Folds both new pages into one 'added' changelog entry. Regenerates OG images (new page + four count-driven). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jdevalk
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Adds the OAuth 2.0 discovery metadata set to the
well-knowncategory — two newoptionalpages plus a short orientation paragraph tying the three documents together:/.well-known/oauth-protected-resource(RFC 9728) — the resource-server metadata naming which authorisation server(s) issue the tokens a protected API accepts. Now required of authenticated MCP servers./.well-known/oauth-authorization-server(RFC 8414) — the plain-OAuth (non-OIDC) sibling ofopenid-configuration, for authorisation servers with no OpenID Connect layer.Together with the existing
openid-configurationpage they form the discovery chain: a resource points at its authorisation server(s), whose own metadata lives atoauth-authorization-server(oropenid-configurationfor OIDC).Also:
well-known-overview, using the OAuth trio as the example.relatedSlugswired acrosswell-known-overview,openid-configuration,oauth-protected-resource,oauth-authorization-server, andmcp-and-tool-discovery.addedchangelog entry covering both pages.Why keep three pages instead of one
Discussed in-session. The site is one-page-per-well-known-URI by design — the checklist,
llms.txt, the OKF bundle, and the MCPget_topic/list_topicstools all treat one page as one auditable unit, and the three documents serve genuinely different roles (resource server vs authorisation server; OIDC vs plain OAuth). Merging would also retire two live, stable URLs (openid-configurationexists; #85 addedoauth-protected-resource), contradicting the spec's ownstable-urlsguidance. The coherence comes from linkage + the overview paragraph, not a merged page.Why "ship it before you spec it" does not block either page
Both are conditional well-known URIs — they only apply to a site that exposes an OAuth-protected resource or runs an authorisation server. This site's MCP endpoint is public and unauthenticated, so there is nothing to ship, exactly like the existing
openid-configuration,webfinger,nodeinfo, andwebauthnpages. Each page says so.Status justification
Both
optional— needed only when the condition holds. Notrecommended: a site with no protected resource / no authorisation server should not publish these.Primary sources
Verification
npm run buildpasses locally (158 pages indexed, integrity check green).eslint+prettier --checkpass via the pre-commit hook.Opened as draft by the daily standards scan; both pages follow the in-session decision that RFC 9728/8414 should be spec'd because neither requires the site to ship anything.
🤖 Generated with Claude Code