Skip to main content

AuthorizationDetailsTypesValidator Class

Abblix.Oidc.Server​

Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation​

AuthorizationDetailsTypesValidator Class​

Rejects client registration when the requested authorization_details_types per-client allowlist (RFC 9396 §5.1) names any type value the server does not understand, returning invalid_client_metadata per OIDC DCR §3.2. Without this gate the registration would succeed and every RAR-bearing request from this client would fail at the authorize/PAR endpoint with invalid_authorization_details — a worse error surface for the deployer who registered with a typo.

public class AuthorizationDetailsTypesValidator : Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SyncClientRegistrationContextValidator

Inheritance System.Object → SyncClientRegistrationContextValidator → AuthorizationDetailsTypesValidator

Remarks​

The server-supported set is enumerated from the same keyed-DI registry of IAuthorizationDetailValidator implementations that request-time dispatch uses, via Microsoft.Extensions.DependencyInjection.KeyedService.AnyKey. This makes registration gating, run-time gating, and discovery's authorization_details_types_supported field share one source of truth — same shape as SupportedGrantTypeValidator.

Semantics of the requested allowlist: - null — client does not request any constraint; this validator passes. - Empty array — client explicitly opts out of RAR; passes (a client may legitimately register zero allowed types to disable the feature for itself). - Non-empty array — every value must appear in the server-supported set, else reject.

Constructors​

AuthorizationDetailsTypesValidator(IServiceProvider) Constructor​

Rejects client registration when the requested authorization_details_types per-client allowlist (RFC 9396 §5.1) names any type value the server does not understand, returning invalid_client_metadata per OIDC DCR §3.2. Without this gate the registration would succeed and every RAR-bearing request from this client would fail at the authorize/PAR endpoint with invalid_authorization_details — a worse error surface for the deployer who registered with a typo.

public AuthorizationDetailsTypesValidator(System.IServiceProvider serviceProvider);

Parameters​

serviceProvider System.IServiceProvider​

Remarks​

The server-supported set is enumerated from the same keyed-DI registry of IAuthorizationDetailValidator implementations that request-time dispatch uses, via Microsoft.Extensions.DependencyInjection.KeyedService.AnyKey. This makes registration gating, run-time gating, and discovery's authorization_details_types_supported field share one source of truth — same shape as SupportedGrantTypeValidator.

Semantics of the requested allowlist: - null — client does not request any constraint; this validator passes. - Empty array — client explicitly opts out of RAR; passes (a client may legitimately register zero allowed types to disable the feature for itself). - Non-empty array — every value must appear in the server-supported set, else reject.