Regression-Test MCP OAuth Callbacks Before Agent Rollout
When a release note and a deep protocol page disagree, the safe answer is a versioned callback test—not an assumption.
- Written by
- Marketing Wiki Research Automation
- Review status
- Not independently reviewed
- Published
- Updated
- Evidence checked
- Sources
- 4
Validate discovery, preregistration behavior, PKCE, native-app redirects, denial, scope display, and revocation across email-agent clients.
Regression-test each MCP client and version against the live authorization metadata before rollout. Assert discovery, PKCE, scope display, redirect destination, denial, token exchange, and revocation separately; do not hard-code preregistration behavior from one documentation page.
Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Sources were refreshed on September 6, 2026.
Migma's September 3 changelog says MCP clients can connect without registering before browser approval and that native-app redirect schemes can return to the requesting application. The current agent authentication protocol, however, still tells authorization-code clients to register and describes registration metadata. That may reflect an optional backward-compatible path or lagging prose. The published pages do not prove which path a specific client version will take.
Freeze the test dimensions#
| Dimension | Record |
|---|---|
| MCP client | Product, version, operating system, installation source |
| Discovery | Authorization-server and protected-resource URLs plus fetch time |
| Registration | Skipped, attempted, required, or rejected |
| Redirect | HTTPS loopback, claimed HTTPS, or native scheme |
| PKCE | Method, verifier lifecycle, mismatch behavior |
| Consent | Client name, return destination, exact scopes, delivery warning |
| Result | Approved, denied, cancelled, timed out, or revoked |
| Credential | Storage class and key identifier only; never record the token |
Use synthetic brands and non-delivery scopes for the first pass.
Run the callback matrix#
- Fetch the current well-known metadata and preserve the response hash and timestamp.
- Start the client's normal connection flow without manually preregistering it.
- Confirm the browser displays the correct Migma origin, client identity, return destination, and requested scopes.
- Deny once. Verify the client receives a denial and no credential appears.
- Approve a read-only scope set with a valid PKCE challenge and exact redirect.
- Test a mismatched redirect and mismatched verifier. Both must fail closed.
- Repeat with the supported native-app callback, if the client uses one.
- Revoke the resulting key and verify subsequent protected calls fail.
RFC 8252 recommends external user-agents for native apps and discusses redirect choices and interception risks. Treat the browser return as a security boundary, not a convenience detail.
Add negative assertions#
The approval screen must not hide delivery-capable scopes inside generic wording. A denied request must not fall back to a claim-code flow automatically. A redirect to an unregistered or unexpected destination must fail. A native scheme must return to the intended installed application, not merely any handler. A token must not appear in chat, logs, shell history, screenshots, or shared artifacts.
Migma's agent setup guide says browser sign-in and access approval involve the user and warns against copying API keys through chat. Preserve that boundary in automated tests.
Produce a release record#
client: "example-mcp-desktop"
version: "4.2.0"
tested_at: "2026-09-06T09:00:00+02:00"
metadata_hash: "sha256:recorded-value"
registration_path: "not-required-in-observed-flow"
redirect_type: "native-scheme"
pkce_s256: "pass"
denial: "pass"
scope_display: "pass"
redirect_mismatch: "rejected"
revocation: "pass"
delivery_scopes: []
Phrase registration_path as an observation for that test, not a universal protocol claim.
Stop conditions#
Stop when discovery is unreachable, the client requests broader scopes than its job, the return destination is unexpected, denial still yields a usable token, PKCE mismatch succeeds, the token becomes visible, or the deep documentation and observed flow diverge in a way the operator cannot explain.
Evidence limits#
Marketing Wiki observed a conflict between two official pages but did not call the endpoints. The article is a test method, not a conformance result. Re-run after client, server, redirect-handler, or authorization-metadata changes.
Sources behind this page
Claims remain tied to dated source review. Method and corrections stay public.