GeezerVison

Copy link

Copy Markdown

Member

maxisbey approved these changes Jun 20, 2026

View reviewed changes

32 checks passed

maxisbey deleted the sep-2352-as-binding branch June 20, 2026 17:47

claude Bot reviewed Jun 20, 2026

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

…r metadata

Backport of the discovery half of #3398, together with the SEP-2352
credential binding that main has had since 2.0 and that change relies on
(the parts of #2921, #2933, #2936, #2946 and #3181 it needs).

The discovery step now knows which issuer the authorization server
metadata must carry before fetching it: the PRM-advertised server, or on
the 2025-03-26 no-PRM fallback the resource server's origin, which is
what that well-known URL is built from (RFC 8414 section 3.3). On this
line there was no issuer check at all; it now runs on both paths
(`validate_metadata_issuer`, with `issuers_match`: exact, except that a
root issuer with and without its trailing slash is the same server,
which matters here because every parsed issuer renders with the slash).
Stored client credentials gain the binding main has: the SDK records the
issuer a registration was made with (`OAuthClientInformationFull.issuer`,
never read from the registration response), and before any metadata is
fetched a registration bound to a different issuer is discarded together
with its tokens so the flow re-registers instead of presenting another
server's credentials (`credentials_match_issuer`); newly registered
clients are bound to the expected issuer when metadata for it was found and
the registration actually went to that server.
When no protected resource metadata location answers and one of them
failed with a server error (or 429), the flow stops rather than reading
that as "no such metadata".

A 403 insufficient_scope step-up takes the same path as a 401: it
discovers first when no metadata is held (extract_resource_metadata_from_www_auth
also reads the `resource_metadata` hint from a 403 challenge) and then
re-authorizes with the challenged scope; metadata already discovered in
this process is reused as before. A 403 that is not a scope challenge is
handed back to the caller instead of being retried unchanged.

The conformance harness pinned on this line (0.1.13) still serves, in its
two path-based authorization server scenarios, metadata whose `issuer` omits
the advertised tenant path; those two scenarios are listed as expected
failures until the pin moves past conformance 0.1.15, where the mock was
corrected.

Differences from the main change:
- RFC 9207 `iss` validation is not included; the callback contract on
  1.x stays `tuple[str, str | None]`.
- 1.x has no SEP-2350 scope union, so a step-up asks for the challenged
  scope as it did before.
- The root-slash allowance lives in `validate_metadata_issuer` itself
  (new on this line) rather than only on the legacy path.