Make IdentityAssertionOAuthProvider a standalone httpx.Auth

The previous implementation inherited OAuthClientProvider.async_auth_flow,
whose trust model (RS chooses the AS via PRM, client DCRs there, AS-advertised
scopes win) is the inverse of SEP-990's (AS is enterprise configuration, RS is
untrusted for AS selection, client is pre-provisioned). Each inherited step was
neutralized by a guard, and successive review rounds kept finding paths around
them - PRM authorization_servers[0] overwriting the pin, the legacy ASM-from-RS
fallback, SEP-2352 clear-and-re-DCR, scope-selection overwrite.

This drops the inheritance. IdentityAssertionOAuthProvider is now a standalone
httpx.Auth: the AS issuer is a constructor argument, ASM is fetched from that
issuer's RFC 8414 well-known, validate_metadata_issuer and a same-origin
token_endpoint check run, and the jwt-bearer request goes only there. There is
no PRM fetch, no DCR step, no credentials_match_issuer step, and no mutable
client_metadata.scope - the resource server has no input into where the ID-JAG
or client secret are sent. This matches go-sdk and csharp-sdk, which take the
AS URL as configuration.

Also:
- ClientAuthenticator now rejects a secret-based auth method registered without
  a stored secret (the gap the per-grant confidential gate was compensating for).
- JWT_BEARER_GRANT_TYPE is defined once in mcp.shared.auth and imported.
- expected_issuer renamed to issuer (it is the address, not a check); scopes
  renamed to scope for consistency with the other extensions.
- Client tests rewritten around the new flow, including a by-construction test
  asserting the RS is never consulted for AS selection.

Author: maxisbey

docs/migration.md

@@ -1460,16 +1460,16 @@ provider = IdentityAssertionOAuthProvider(
     storage=my_token_storage,
     client_id="enterprise-mcp-client",
     client_secret="enterprise-mcp-secret",
-    expected_issuer="https://auth.example.com",
+    issuer="https://auth.example.com",
     assertion_provider=fetch_id_jag,
 )
 ```
 
-SEP-990 §5.1 requires the client to authenticate; this SDK currently requires a shared secret, so `client_secret` is mandatory (`token_endpoint_auth_method` chooses `client_secret_post` (default) or `client_secret_basic`; the spec also permits `private_key_jwt`). `expected_issuer` pins the authorization server the client is provisioned for: the provider fixes authorization-server discovery to that issuer (rather than trusting the untrusted resource server's metadata) and refuses to send the ID-JAG or secret to any other, preventing a hostile resource server from redirecting the credentials.
+SEP-990 §5.1 requires the client to authenticate; this SDK currently requires a shared secret, so `client_secret` is mandatory (`token_endpoint_auth_method` chooses `client_secret_post` (default) or `client_secret_basic`; the spec also permits `private_key_jwt`). The authorization server is configuration, not discovery: `issuer` is the AS the client is provisioned for, authorization-server metadata is fetched from that issuer's RFC 8414 well-known, and the resource server is never asked which AS to use - so a hostile resource server cannot redirect the ID-JAG or secret.
 
 On the authorization server, set `AuthSettings(identity_assertion_enabled=True)` (or pass `identity_assertion_enabled=True` to `create_auth_routes`) and implement `exchange_identity_assertion` on your `OAuthAuthorizationServerProvider`. The method receives an `IdentityAssertionParams` (the ID-JAG `assertion`, requested scopes, and request `resource`) and returns a plain RFC 6749 `OAuthToken`. The flag gates both metadata advertisement and the token endpoint: when off, `/token` rejects the grant with `unsupported_grant_type` even if the provider implements the hook. When on, the metadata advertises the jwt-bearer grant and the `urn:ietf:params:oauth:grant-profile:id-jag` profile in `authorization_grant_profiles_supported` (the discovery mechanism per ext-auth §6).
 
-The implementation is responsible for validating the assertion per RFC 7523 §3 and SEP-990 §5.1 - verify the signature/`iss`/`exp`/`typ`, require `aud` to be this AS, require the ID-JAG's `client_id` claim to match the authenticated client, audience-restrict the issued token to the ID-JAG's `resource` claim (not the client-controlled request `resource`), and derive scopes from the ID-JAG rather than granting the request verbatim. See `examples/snippets/servers/identity_assertion_server.py`, which fails closed. Two hardening points are enforced by the SDK: the handler rejects public (`none`) clients before calling the hook, and Dynamic Client Registration refuses the jwt-bearer grant so the ID-JAG flow requires a pre-registered confidential client.
+The implementation is responsible for validating the assertion per RFC 7523 §3 and SEP-990 §5.1 - verify the signature/`iss`/`exp`/`typ`, require `aud` to be this AS, require the ID-JAG's `client_id` claim to match the authenticated client, audience-restrict the issued token to the ID-JAG's `resource` claim (not the client-controlled request `resource`), and derive scopes from the ID-JAG rather than granting the request verbatim. See `examples/snippets/servers/identity_assertion_server.py`, which fails closed. Two hardening points are enforced by the SDK: the handler rejects clients without a stored secret before calling the hook (and `ClientAuthenticator` itself now refuses a secret-based auth method registered without a secret), and Dynamic Client Registration refuses the jwt-bearer grant so the ID-JAG flow requires a pre-registered confidential client.
 
 ### 2025-11-25 and 2026-07-28 protocol fields modeled
 

examples/snippets/clients/identity_assertion_client.py

@@ -9,7 +9,9 @@
 and out of scope for the SDK; supply it through the `assertion_provider` callback. The callback
 receives the authorization server's issuer (the ID-JAG `aud`) and the MCP server's resource
 identifier (the ID-JAG `resource` claim). SEP-990 requires a confidential client, so a client secret
-is mandatory, and `expected_issuer` pins the authorization server the credentials are provisioned for.
+is mandatory, and `issuer` is the authorization server the credentials are provisioned for - the
+provider fetches metadata from that issuer's well-known and never asks the resource server which AS
+to use.
 """
 
 import asyncio
@@ -59,9 +61,9 @@ async def main() -> None:
         storage=InMemoryTokenStorage(),
         client_id="enterprise-mcp-client",
         client_secret="enterprise-mcp-secret",
-        expected_issuer="http://localhost:8001",
+        issuer="http://localhost:8001",
         assertion_provider=fetch_id_jag,
-        scopes="user",
+        scope="user",
     )
 
     async with httpx.AsyncClient(auth=oauth_auth, follow_redirects=True) as http_client: