Client registration carried two overlapping profile fields. `type`
(web/native/user-agent-based) was a better-auth invention with no RFC 7591
standing, validated only for self-consistency against the auth method;
`application_type` is the OIDC Registration field, and the one MCP clients
are told to send.
Registration accepted both without cross-checking, so a client could declare
`type: "web"` alongside `application_type: "native"` and be stored claiming
two profiles. Collapsing to `application_type` removes the ambiguity and
gives the field a real column rather than the untyped metadata bag.
`user-agent-based` has no successor: a browser app registers with
`token_endpoint_auth_method: "none"`, which already marks it public. PKCE
enforcement reads `application_type` for the native case that `type` used to
cover, so a native client stays public whatever auth method it registered
with.
Client ID Metadata Documents are the registration mechanism the MCP
2026-07-28 spec recommends, and dynamic client registration the one it
deprecates, but the `application_type` redirect URI constraint reached only
the deprecated path: the field was dropped by the metadata document
allowlist before validation ran.
`type` and `application_type` both describe the client profile, so a
registration sending both must keep them consistent. Cite RFC 8252 for the
native redirect URI rule actually enforced; OIDC Registration predates
claimed https links and does not permit them.
The insufficient-scope challenge keyed on the FORBIDDEN status, so any
permission denial became a scope challenge advertising the configured
scopes, which the token already held. Clients following the step-up flow
re-authorized for scopes they had and retried into the same failure.
Key the challenge on an explicit `insufficient_scope` marker carrying the
scopes the token lacks, matching how DPoP challenges are already detected.
Scope verification reports every missing scope at once rather than the first,
and handlers raise the same challenge through `insufficientScopeError` for
scopes only they know about. Everything else, including a plain FORBIDDEN,
propagates untouched.
OIDC Registration §2 / MCP 2026-07-28 (SEP-837): when a registration
declares application_type, redirect URIs are constrained to what the
declared type allows — native clients may use custom schemes, loopback
http redirects, or claimed https links, while web clients require https
on non-loopback hosts. Only enforced when the parameter is explicit, so
existing registrations keep working. The field round-trips through
client metadata and is echoed in the registration response.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QbU1ZgRHK5A1btqpdR5gbD
Per the MCP 2026-07-28 scope-challenge guidance (RFC 6750 §3.1),
raiseResourceServerChallenge now maps FORBIDDEN errors to a 403 with a
WWW-Authenticate challenge carrying error="insufficient_scope", the
required scope, and the resource_metadata pointer so MCP clients can
step up their authorization. requireMcpAuth and mcpHandler gain a
`scopes` option enforced against the token's scope claim, and awaited
handlers let handler-thrown FORBIDDEN errors produce the same challenge.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QbU1ZgRHK5A1btqpdR5gbD
Gustavo Valverde
Claude
better-release[bot]andGitHub
TaesuandGitHub
Akshat malikandGitHub
