feat(oauth): RFC 9207 iss + application_type (MCP 2026-07-28, slice 2) - #62
Merged
Conversation
Adopts the two OAuth items from the MCP 2026-07-28 revision that are stable independently of the new protocol path: - RFC 9207 (SEP-2468): the authorization success redirect now carries iss=<origin> and AS metadata advertises authorization_response_iss_parameter_supported, closing the authorization-server mix-up gap flagged in the spec update. Error responses stay inline HTML (never a redirect), so the success redirect is the only place iss applies. - SEP-837: Dynamic Client Registration accepts, validates (web or native), records and echoes application_type, so future redirect policy can differentiate native loopback clients without re-registration. Redirect matching itself is unchanged. Both changes are additive; clients that ignore iss or omit application_type behave exactly as before. Signed-off-by: Łukasz Gumowski <lukasz.gumowski@gmail.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
3 tasks
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
A registered redirect_uri carrying its own iss query parameter would make the authorization redirect emit two iss values after the RFC 9207 append - a compliant client rejects such a response, a naive one may validate the wrong issuer. Refused inline at authorize time (GET and POST), like every other authorize-time rejection; literal match is enough because an encoded evasion only confuses the registering client's own flow. Addresses Greptile P1 on #62. Signed-off-by: Łukasz Gumowski <lukasz.gumowski@gmail.com>
The embedded-iss detector compared raw query-pair text, so a registered redirect URI carrying a percent-encoded name (%69ss=...) slipped past it while the client-side query parser still decodes it to a second iss parameter - the exact duplicate-issuer failure the check exists to prevent (verified repro in the Greptile follow-up on #62). Names are now percent-decoded (single pass, invalid escapes pass through, lossy UTF-8 can never spell the pure-ASCII iss) before the case-sensitive comparison. Signed-off-by: Łukasz Gumowski <lukasz.gumowski@gmail.com>
RFC 6749 section 3.1.2 forbids fragments in the redirection endpoint URI, and the string-append response construction makes the failure concrete: for a registered URI like https://client.example/cb#frag the appended code, state and iss all land inside the client-side fragment, so the callback request never receives them (verified repro in the Greptile follow-up on #62 - the code/state part of that defect predates this branch; the iss append extended it). Refused inline on both authorize paths, next to the embedded-iss rule. A percent-encoded %23 is an ordinary octet and stays allowed. Rebuilding the redirect with a URI parser instead of string appends is a broader pre-existing refactor - deferred as a follow-up outside this brief. Signed-off-by: Łukasz Gumowski <lukasz.gumowski@gmail.com>
3 tasks
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
Slice 2 of the MCP 2026-07-28 adoption brief — the OAuth items that are stable independently of the new protocol surface:
iss=<origin>, and AS metadata advertisesauthorization_response_iss_parameter_supported: true. Closes the authorization-server mix-up gap called out in the 2026-07-28 spec release./oauth/registeracceptsapplication_type(webdefault,native), validates it (unknown values →invalid_client_metadata, same posture as the existing auth-method check), records it on the client and echoes it in the response. Redirect matching is intentionally unchanged — RFC 8252 loopback-port policy for native apps is follow-up work.Why
The brief's recommended order starts with this slice: small, additive, and grounded in stable RFCs regardless of MCP schema publication timing. Error-path authorize responses stay inline HTML (never redirect to an unvalidated target), so only the success redirect carries
iss— by design.Gate
cargo fmt --checkcargo clippy --workspace -- -D warningscargo test -p loomem-server— all green (312 unit + integration)Tests added:
isspresent in the redirect, metadata flag advertised,application_typestored/echoed, unknownapplication_typerejected.Slice 1 (stateless 2026-07-28 protocol path) lands as a separate PR.
🤖 Generated with Claude Code
https://claude.ai/code/session_011gqzVB16MKWKvhDtGQ7Mnn
Greptile Summary
This change adds issuer identification to successful OAuth authorization redirects, advertises that behavior in authorization-server metadata, and supports
application_typeduring dynamic client registration. It also rejects redirect URIs containing fragments or an existingissparameter so response parameters remain unambiguous.T-Rex validation blocked
The focused OAuth authorization test could not run because the required LLVM tooling is unavailable:
clang-syscould not findllvm-configor a sharedlibclang.so. Cargo stopped while compiling dependencies, before the authorization redirect path could be exercised.Confidence Score: 5/5
The PR is safe to merge; no blocking failure remains.
No product defect was found. The focused OAuth callback test was unable to compile because required native LLVM tooling is absent, but the blocked environment did not establish a failure in the change.
What T-Rex did
Reviews (4): Last reviewed commit: "fix(oauth): refuse fragment-bearing redi..." | Re-trigger Greptile