MCP 2026-07-28 Auth RC: 3 Changes Hit Your Tool Gateway

Change 2: Dynamic Client Registration Stops Guessing What Your Gateway Is (SEP-837)

SEP-837 requires MCP clients to declare an appropriate OpenID Connect application_type during Dynamic Client Registration.^[4] Before this change, the field was left empty, and most OIDC providers default an unspecified client to "web" — which then rejects the localhost redirect URI that every stdio-based client, CLI tool, or desktop agent needs. A gateway process spawning MCP servers over stdio, exactly as Pattern 1 of the Hermes Tool Gateway guide does with command: npx, is a native/CLI client by definition. It was getting classified as a browser-based web app and failing registration against any OIDC-strict authorization server.

The before/after at the registration request is small but decisive:

// Before SEP-837 — application_type omitted, AS defaults to "web"
POST /register HTTP/1.1
Content-Type: application/json

{
  "client_name": "hermes-orchestrator",
  "redirect_uris": ["http://localhost:33421/callback"],
  "grant_types": ["authorization_code", "refresh_token"]
}
// → many OIDC providers reject: redirect_uri not permitted for "web" clients

// After SEP-837 — application_type declared explicitly
POST /register HTTP/1.1
Content-Type: application/json

{
  "client_name": "hermes-orchestrator",
  "application_type": "native",
  "redirect_uris": ["http://localhost:33421/callback"],
  "grant_types": ["authorization_code", "refresh_token"]
}
// → localhost redirect accepted under native-client rules

Fold that into the config from Pattern 3 of the Hermes reference — the OAuth-protected remote server pattern used for Stripe — and the client registration step that Hermes performs against mcp.stripe.com/oauth/token now needs application_type: "native" set explicitly if you are on Dynamic Client Registration rather than a pre-registered client ID. Get this wrong under the current spec and the failure is silent right up until token exchange; get it wrong under the RC and beta SDKs and it fails at registration, which is a faster and more honest failure mode.

There is a second thread worth pulling here. The base spec now recommends OAuth Client ID Metadata Documents (CIMD) over Dynamic Client Registration, and formally deprecates DCR — retained only for backward compatibility with authorization servers that have not adopted CIMD, under a twelve-month deprecation window.^[6] SEP-837 fixes DCR’s biggest practical bug at the exact moment DCR itself stops being the recommended path. Fix the application_type gap this week if you are still on DCR — every server you talk to still needs it — but the actual migration target for new outbound connections is CIMD, where your client ID is a hosted HTTPS metadata document instead of a registration round trip.

Change 3: Protected Resource Metadata Makes Your Server Side an OAuth Citizen (RFC 9728)

The base authorization spec is unambiguous here: “MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728). MCP clients MUST use OAuth 2.0 Protected Resource Metadata for authorization server discovery.”^[6] RFC 9728 itself defines the mechanism: a protected resource publishes a JSON document at /.well-known/oauth-protected-resource that names the authorization servers a client should use, and the resource server signals its location in a WWW-Authenticate challenge on a 401.^[8]

Everything up to this point in the RC is about your gateway as an OAuth client — the outbound side, Patterns 1 through 4 and 8 of the Hermes reference. RFC 9728 flips it. The moment your gateway runs Pattern 5, Hermes serving itself as an MCP server to Claude Code or any other external agent, it is now the OAuth resource server, and this MUST clause applies to it directly. That means your own hermes mcp serve process needs to answer a discovery request, not just make one:

GET /.well-known/oauth-protected-resource HTTP/1.1
Host: hermes-orchestrator.internal

HTTP/1.1 200 OK
Content-Type: application/json

{
  "resource": "https://hermes-orchestrator.internal/mcp",
  "authorization_servers": ["https://auth.yourcompany.com"],
  "scopes_supported": ["run_task:write", "run_task:read"]
}

And on an unauthenticated call, the 401 needs to point there:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://hermes-orchestrator.internal/.well-known/oauth-protected-resource",
                         scope="run_task:write"

The scope parameter in that header is doing work you already understand from the client side of your own gateway. The spec’s scope-selection strategy — use the challenged scope if present, fall back to scopes_supported otherwise — is the OAuth-layer counterpart to the include/exclude tool whitelist from Patterns 2 and 11 of the Hermes reference. Where include: [list_issues, get_issue, create_issue] hides tools your gateway should never call, a well-scoped run_task:write now hides operations an external caller’s token should never be able to invoke, enforced by the authorization server instead of by your tool registry alone. Run both layers together and a compromised token buys an attacker nothing your tool allowlist did not already refuse to expose.

What the Stateless Redesign Does to Your Circuit Breaker

The RC’s largest change is not an auth SEP at all — it removes the initialize/initialized handshake and the Mcp-Session-Id header entirely, making every request self-describing instead of tied to a stateful connection.^[5] That is good news for infrastructure: a gateway can now sit behind a plain round-robin load balancer instead of needing sticky sessions, because there is no server-side session to route back to.

It is also the reason the issuer-mismatch trap from Change 1 matters more than it looks. Without sessions, every request re-authenticates independently, so an integration gap in your callback handling does not fail once at connection time — it fails on every single request through every replica behind the load balancer. That is a fast way to trip a naive failure_threshold. The fix is to make your circuit breaker status-code-aware instead of failure-count-blind:

# ~/.hermes/config.yaml — circuit breaker that separates auth
# rejections from actual upstream failures (extends Pattern 8)
mcpServers:
  stripe:
    transport: http
    url: "https://mcp.stripe.com/v1"
    use_gateway:
      timeout_seconds: 30
      circuit_breaker:
        failure_threshold: 5
        recovery_timeout_s: 60
        # New in the auth-hardening pass: don't let issuer
        # mismatches or 401s from a stale callback signature
        # count toward the same threshold as timeouts/5xx.
        count_toward_threshold:
          - timeout
          - "5xx"
        alert_separately:
          - "401_iss_mismatch"
          - "403_insufficient_scope"

That split is not cosmetic. A circuit that opens because Stripe’s MCP endpoint is genuinely down should recover on its own in 60 seconds. A circuit that opens because your host forgot to extract iss from the redirect URI will still be open in 60 seconds, and in 60 minutes, because nothing about waiting fixes a code path that was never updated. Routing those two failure shapes to different alerts is the difference between a self-healing gateway and a page at 2 a.m. for a bug that has been sitting in production for a week.

This Week vs. When the Spec Locks

Change	Do this week (RC + beta SDKs)	Do when 2026-07-28 goes final
SEP-2468 (issuer validation)	Pin the beta SDK; audit every OAuth callback handler in your gateway for whether it extracts and forwards iss	Treat client-side validation as MUST, not best-effort — the spec expects the current SHOULD on servers to become MUST in a future revision
SEP-837 (DCR application_type)	Set application_type: "native" on every stdio/CLI client still using Dynamic Client Registration	Start migrating new outbound OAuth connections to Client ID Metadata Documents; DCR is deprecated but usable for 12 months
RFC 9728 (Protected Resource Metadata)	Stand up /.well-known/oauth-protected-resource on any gateway you expose as an inbound MCP server	Wire real per-scope enforcement server-side so the WWW-Authenticate scope claim matches what your tool allowlist already restricts
Stateless redesign	Split circuit-breaker alerting by status-code shape, not just failure count	Remove any lingering session-affinity assumptions from load balancer config once GA SDKs confirm the handshake is gone for good

None of this is deploy-today territory. WorkOS’s read on the RC is the right framing for an operator: “the path from ‘unauthenticated MCP server’ to ‘properly secured MCP server’ is now defined at the spec level rather than left as an exercise.”^[7] That is true, and it is also why a gateway with real production traffic cannot just flip the switch on RC behavior — you test the issuer-validation path against your own callback handlers with a scratch OIDC tenant, you set application_type on new registrations without ripping out working DCR flows, and you publish Protected Resource Metadata on a staging gateway before your production one. The spec locking on 2026-07-28 is the deadline for having done that testing, not the moment you start it.

A JWT decoder earns its keep here — run any access token your gateway issues or consumes through our free JWT Decoder to eyeball the iss and aud claims before you wire up the validation logic above, and our JSON Formatter is the fastest way to sanity-check a hand-written Protected Resource Metadata document before you serve it. If the config surface here looks familiar, it should — the MCP Server Pack ships the pinned, circuit-breaker-hardened server configs this RC now needs to account for, and the AI Agent Ops Bundle covers the observability and cost-control side of running exactly this kind of multi-server gateway in production.

For the governance layer that sits on top of all three changes — least-privilege scopes, audit trails, tool-level allowlists — see the WOWHOW Least-Privilege MCP Governance Layer. And if you are building or buying tools for a gateway like this, browse the full WOWHOW catalog for the rest of the stack.

---

Sources

1. The 2026-07-28 MCP Specification Release Candidate — Model Context Protocol Blog
2. Beta SDKs for the 2026-07-28 MCP Spec Release Candidate — Model Context Protocol Blog
3. SEP-2468: Recommend Issuer (iss) Parameter in MCP Auth Responses — Model Context Protocol
4. SEP-837: Update authorization spec to clarify client type requirements — GitHub PR
5. Key Changes — Model Context Protocol Specification Changelog
6. Authorization — Model Context Protocol Specification (draft)
7. The biggest MCP spec update ships July 28: What changes for AI agent authentication — WorkOS
8. RFC 9728 — OAuth 2.0 Protected Resource Metadata — IETF Datatracker