Skip to main content

Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation Namespace

Abblix.Oidc.Server

Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation Namespace

Classes
AuthorizationDetailsTypesValidatorRejects 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.
BackChannelAuthenticationValidatorValidates CIBA-related metadata (OpenID Connect Client-Initiated Backchannel Authentication 1.0 §4): the consistency between backchannel_token_delivery_mode and backchannel_client_notification_endpoint, and that backchannel_authentication_request_signing_alg is on the server's supported list.
BackChannelLogoutUriValidatorValidates the OIDC Back-Channel Logout 1.0 backchannel_logout_uri: when supplied it must be an absolute URI that the server is permitted to fetch under the active SSRF policy (SecureHttpFetchOptions). Because the OP itself POSTs the logout token to this endpoint, rejecting an internal/loopback or disallowed-scheme target at registration stops a registered client from becoming a (blind) SSRF vector and surfaces the problem to the caller up front rather than as a silent delivery failure at logout time. The outbound handler still re-validates at request time.
ClientIdValidatorCross-checks the supplied client_id against the operation type: for Update (RFC 7592 §2.2) the client must already exist, for Register (RFC 7591 §3) it must not. A missing client_id is treated as new-registration with server-assigned id.
ClientRegistrationContextValidatorCompositeComposite that runs the configured chain of IClientRegistrationContextValidator steps in order and short-circuits on the first failure, mirroring RFC 7591 §3.2.2 which requires the server to reject a registration on the first invalid metadata field.
ClientRegistrationValidationContextMutable state shared by the validation pipeline. Carries the original ClientRegistrationRequest alongside derived values that earlier steps compute and later steps (or the processor) consume.
CredentialsValidatorValidates that client authentication methods are consistent with the credentials provided during registration. Ensures clients using JWT-based or TLS authentication have the required credentials (JWKS for JWT methods, TLS metadata for TLS methods). JWKS may be provided by any client for encryption or request object signing.
EncryptedResponseAlgorithmsValidatorValidates the JWE algorithms a client requests for the JWTs this server encrypts or decrypts: id_token_encrypted_response_alg/enc and userinfo_encrypted_response_alg/enc (OIDC Core), request_object_encryption_alg/enc (RFC 9101) and authorization_encrypted_response_alg/enc (JARM §3). Each key-management (alg) value must appear in the server's supported key-management algorithms and each content-encryption (enc) value in its supported content-encryption algorithms.
ErrorFactoryBuilds OidcError instances using the error codes RFC 7591 §3.2.2 reserves for dynamic client registration: invalid_redirect_uri, invalid_client_metadata, invalid_software_statement, and unapproved_software_statement.
GrantTypeValidatorEnforces the consistency rule from OIDC DCR 1.0 §2 between response_types and grant_types: a client requesting code must register the authorization_code grant, and one requesting token or id_token must register the implicit grant.
InitialAccessTokenValidatorValidates the initial access token on client registration requests per RFC 7591 Section 3 and RFC 6750 Bearer Token Usage. When RequireInitialAccessToken is enabled, checks JWT signature, expiration, type, and revocation status. Skipped for update operations and when the feature is disabled.
InitiateLoginUriValidatorValidates the OIDC DCR 1.0 §2 initiate_login_uri: when supplied it must be an absolute URI using the https scheme.
PostLogoutRedirectUrisValidatorValidates the OpenID Connect RP-Initiated Logout 1.0 post_logout_redirect_uris: each URI must be absolute, fragment-free, and consistent with the OIDC DCR 1.0 §2 scheme rules for the declared application_type (Web = https, non-localhost; Native = custom scheme or http://localhost).
ScopeValidatorValidates the scope values in a client registration request per RFC 7591 Section 2. Each requested scope must be recognized by the server.
SecurityProfileValidatorFail-loud companion to the request-time profile enforcement: rejects a registration whose declared response types can never satisfy the security profile the client falls under, so the contradiction surfaces at registration with a clear invalid_client_metadata diagnostic instead of as a per-request rejection the client has to reverse-engineer later. Whether a client is held to a profile is a server-side policy decision: a dynamically registered client cannot declare one, so it inherits the server-wide DefaultSecurityProfile.
SignedResponseAlgorithmsValidatorValidates the algorithms a client requests for tokens this server signs: id_token_signed_response_alg and userinfo_signed_response_alg (OIDC DCR 1.0 §2), and authorization_signed_response_alg (JARM §3). Each must appear in the server's set of supported signing algorithms; in addition, JARM §3 forbids none for the authorization response.
SigningAlgorithmsValidatorValidates the algorithms a client commits to using on inbound JWTs the server will verify: request_object_signing_alg (OIDC Core §6.1), backchannel_authentication_request_signing_alg (CIBA §7.1.1), and token_endpoint_auth_signing_alg (RFC 7591 §2 / RFC 8414 §2). Each must appear in the matching set the server advertises in discovery: request_object_signing_alg may be none, but token_endpoint_auth_signing_alg excludes none and backchannel_authentication_request_signing_alg excludes both none and the symmetric HS* algorithms. The same provider feeds the discovery document, so DCR accepts exactly what the server advertises.
SoftwareStatementValidatorValidates the software_statement parameter in a client registration request per RFC 7591 Section 2.3. Software statements are signed JWTs issued by a third-party authority asserting metadata about client software.
SubjectTypeValidatorValidates the OIDC Core §8 subject_type metadata and computes the pairwise sector identifier per OIDC Core §8.1: when pairwise is requested, either a supplied sector_identifier_uri (HTTPS, JSON document of redirect URIs) is dereferenced and cross-checked against the registered redirect_uris, or all redirect URIs must share a single host. The resolved host is stored on the context for later persistence.
SupportedGrantTypeValidatorRejects client registration when any value in grant_types is not advertised as supported by this server, returning invalid_client_metadata per OIDC DCR §3.2. Without this gate the registration would succeed and the client would only fail later at the token endpoint with unsupported_grant_type, or at the authorization endpoint for the implicit grant. Companion to SupportedResponseTypeValidator, which applies the same rule to response_types.
SupportedResponseTypeValidatorServer-level support gate for the response_types registration parameter (OIDC DCR §3.2): every part of every requested combination must have a registered IAuthorizationResponseBuilder. Without EnableImplicitFlow() the token / id_token processors are absent — registration must reject those values with invalid_client_metadata at registration time, instead of letting the client succeed at registration and fail with unsupported_response_type on its first authorization request.
SyncClientRegistrationContextValidatorConvenience base for validation steps whose checks are purely in-memory: implements the async contract by wrapping the synchronous Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SyncClientRegistrationContextValidator.Validate(Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.ClientRegistrationValidationContext) result in a completed task.
TlsClientAuthValidatorValidates tls_client_auth metadata fields for RFC 8705 mutual TLS client authentication. Ensures that required metadata is present and properly formatted when tls_client_auth method is selected.
TokenEndpointAuthMethodValidatorValidates that the requested token_endpoint_auth_method (RFC 7591 §2) is one this server announces in token_endpoint_auth_methods_supported on its discovery document.
Interfaces
IClientRegistrationContextValidatorOne step in the client-registration validation pipeline (RFC 7591 §2 / OIDC DCR 1.0). Implementations check a specific aspect of the supplied metadata (redirect URIs, grant types, signing algorithms, sector identifier, software statement, etc.) and either clear it or surface an OidcError for the response. Aggregated by ClientRegistrationContextValidatorComposite.
Enums
DynamicClientOperationDefines the type of dynamic client management operation being performed.