OAuthClientInformationFull, the client's parse of the authorization server's
Dynamic Client Registration response, inherited from OAuthClientMetadata, the
request the client sends. That typed the response as though it had to be a
request this SDK would send. RFC 7591 3.2.1 says otherwise: the server may
reject or replace any requested metadata value, and real servers echo an
application_type outside OIDC Registration's web/native, an explicit null,
an auth method the SDK does not implement, or an empty redirect_uris. Each
raised ValidationError on a 2xx response, after the server had already
provisioned the client, so the registration was discarded and orphaned.
Make the two models siblings over a shared OAuthClientMetadataBase. The
request keeps its strict types, so the SDK still refuses to send an
unregistered application_type. The record accepts what a server may echo:
application_type and token_endpoint_auth_method are str | None (with an
echoed "" read as absent, as the optional URL fields already were),
grant_types is list[str], and redirect_uris may be absent or empty.
client_id is now required, as RFC 7591 3.2.1 makes it in the response.
Whether a substituted value is usable is judged where it matters, not at
parse: an auth method the client cannot apply is reported as an
OAuthRegistrationError when the registration completes, before the record
is stored or any interactive authorization begins, and prepare_token_auth
reports the same for a stored record. The recognized set is derived from
the one TokenEndpointAuthMethod type so the two cannot drift.
The bundled registration endpoint now returns all registered metadata in
its 201 response, building the record from the validated request's dump so
a field can no longer be silently dropped from the echo; it previously
omitted application_type, reporting the default in place of a client's
"web".
Max Isbey
6b0166f3d1