Tighten auth-framework concept page against current MCP spec

[danbarr]

Spinning out of the MCP primer refresh (#822, PR #824) - while comparing primer wording against the MCP spec, I noticed several places in docs/toolhive/concepts/auth-framework.mdx that drift slightly from what the current 2025-11-25 spec actually says. None of these change ToolHive's behavior; they're editorial accuracy fixes against /specification/2025-11-25/basic/authorization. Roughly in order of confidence.

1. Soften-then-tighten the "recommends OAuth 2.1" framing

File: docs/toolhive/concepts/auth-framework.mdx, line 47-50

Current:

The official MCP specification recommends OAuth 2.1-based authorization for HTTP transports, where each MCP server acts as an OAuth resource server.

The spec is layered: authorization is OPTIONAL overall, but if an HTTP-based implementation does authorization, it SHOULD conform to the OAuth 2.1 profile, and within that profile a number of mechanisms (RFC 8707, RFC 9728, PKCE) are MUSTs. "Recommends" reads like OAuth is one option among several inside the MCP spec, which isn't quite right.

Suggested wording:

The official MCP specification defines an OAuth 2.1-based authorization profile for HTTP transports, where each MCP server acts as an OAuth resource server. Authorization itself is optional, but HTTP-transport implementations that adopt it conform to this profile.

2. Fix the link target

Same paragraph. The link goes to /docs/tutorials/security/authorization (the implementation tutorial) but the sentence is making a claim about the specification, and the link text is literally "official MCP specification." Re-point to /specification/2025-11-25/basic/authorization (or /specification/latest/basic/authorization if we'd rather auto-track future revisions). The tutorial is a fine "Related information" entry, just not the citation for a normative claim.

3. Drop "typically" on the Authorization header

File: docs/toolhive/concepts/auth-framework.mdx, line 154-156

Current:

2. Token presentation: You include the token in your requests to ToolHive (typically in the Authorization header).

The spec is unambiguous: bearer tokens MUST be in the Authorization header and MUST NOT appear in URI query strings. "Typically" softens a hard MUST.

Suggested wording:

2. Token presentation: You include the token in the Authorization header on every request to ToolHive.

4. Acknowledge Client ID Metadata Documents alongside DCR

File: docs/toolhive/concepts/auth-framework.mdx, lines 53-57 and 73-80

The "OAuth client registration burden" section frames pre-registration as the only OAuth answer to the registration problem, then introduces DCR later as ToolHive's solution. The 2025-11-25 spec actually defines three registration approaches with a priority order:

1. Pre-registered client info (when there's an existing relationship)
2. Client ID Metadata Documents (most common when there's no prior relationship - the spec's preferred new-relationship path)
3. Dynamic Client Registration (for backwards compatibility or specific requirements)

ToolHive currently implements DCR only; CIMD support is in-progress work to catch up with the spec. The page should reflect both:

• Acknowledge that the spec defines CIMD as the preferred path for clients/servers with no prior relationship.
• Be explicit that ToolHive's embedded authorization server uses DCR today, with CIMD support planned.

This keeps the page honest about today's behavior while not implying the spec offers nothing here.

Out of scope for this issue

• Anything about Cedar policies, the embedded auth server's session storage / token forwarding, or the broader gateway model - those describe ToolHive's actual implementation choices and don't need spec alignment.
• The "MCP-server-to-backend authentication" scope callout - already correct.
• Token validation methods (JWT vs introspection) - already correct.