You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SEP-2352 follow-up: key credential/state stores per authorization server #982
Follow-up to #879 / PR #965 (repurposed from a duplicate of #879).
PR #965 implements the SEP-2352 binding rule: stored credentials are stamped with the issuer that minted them, get_access_token() rejects issuer mismatches (AuthError::AuthorizationServerMismatch), and stale credentials are cleared on mismatch so the next flow re-registers with the new AS.
What it intentionally leaves out (from the PR's scope note): per-AS keying of custom credential/state stores. Today there is a single active credential set, so:
Credentials for AS "A" are destroyed when the client talks to AS "B", even though the "A" credentials are still valid — switching back requires a full re-auth.
A client connecting to multiple MCP servers backed by different authorization servers cannot hold credentials for both simultaneously.
Work: key stored credentials (and any registration state) by AS issuer so multiple credential sets can coexist, and select the right set based on the issuer of the currently discovered metadata.
Not required for 2026-07-28 conformance (the auth/authorization-server-migration scenario is covered by #965), so this is not on the 2026-07-28 milestone.
changed the title [-]Implement SEP-2352: re-register client when the authorization server changes[/-][+]SEP-2352 follow-up: key credential/state stores per authorization server[/+]on Jul 13, 2026
This issue has had no activity for 60 days and is now marked as stale. It will be closed in 14 days if there is no further activity. Add the keep label to keep it open.
Activity
[-]Implement SEP-2352: re-register client when the authorization server changes[/-][+]SEP-2352 follow-up: key credential/state stores per authorization server[/+]github-actions commentedon Sep 15, 2026
This issue has had no activity for 60 days and is now marked as stale. It will be closed in 14 days if there is no further activity. Add the
keeplabel to keep it open.github-actions commentedon Sep 29, 2026
Closing this issue after 14 days of inactivity since it was marked stale. Feel free to reopen if it is still relevant.