JwksUriValidator Class

Validates that a registered jwks_uri names a destination this deployment is allowed to fetch from: RFC 7591 Section 2 makes the member a URL, and this server fetches it to load the client's keys.

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

Inheritance System.Object → SyncClientRegistrationContextValidator → JwksUriValidator

Remarks

A value the fetch cannot resolve registers happily and produces a client whose keys can never be loaded. What the registrant then meets is a private_key_jwt assertion refused as "no signing key matched", at a moment that names neither the metadata nor the mistake - and nothing upstream can say more, since the fetcher answers every failure with an empty key set. Registration is the last point at which the caller is still on the line to be told.

Absoluteness is asked HERE and everything else is asked of the POLICY, which is what BackChannelLogoutUriValidator does with the other address this server fetches. The split matters because absoluteness alone is not the property: a dot is legal in a URI scheme, so client.example.com:8080/jwks - the way people write a host and a port - parses as an ABSOLUTE URI whose scheme is the host name and whose System.Uri.Host is empty, and every member the policy reads below would then be read off a value that names nowhere.

The scheme is NOT decided here, and a literal https would be wrong: AllowedDestinations names an address the deployment reaches inside its own network, over plain HTTP, and the policy lifts the scheme restriction for exactly those. Refusing them at registration while the fetch allows them would make one fetched endpoint disagree with the other about the same address.

Constructors

JwksUriValidator(ISecureUriValidator) Constructor

Validates that a registered jwks_uri names a destination this deployment is allowed to fetch from: RFC 7591 Section 2 makes the member a URL, and this server fetches it to load the client's keys.

public JwksUriValidator(Abblix.Oidc.Server.Features.SecureHttpFetch.ISecureUriValidator uriValidator);

Parameters

uriValidator ISecureUriValidator

The shared SSRF URI policy used by the outbound HTTP handler.

Remarks

A value the fetch cannot resolve registers happily and produces a client whose keys can never be loaded. What the registrant then meets is a private_key_jwt assertion refused as "no signing key matched", at a moment that names neither the metadata nor the mistake - and nothing upstream can say more, since the fetcher answers every failure with an empty key set. Registration is the last point at which the caller is still on the line to be told.

Absoluteness is asked HERE and everything else is asked of the POLICY, which is what BackChannelLogoutUriValidator does with the other address this server fetches. The split matters because absoluteness alone is not the property: a dot is legal in a URI scheme, so client.example.com:8080/jwks - the way people write a host and a port - parses as an ABSOLUTE URI whose scheme is the host name and whose System.Uri.Host is empty, and every member the policy reads below would then be read off a value that names nowhere.

The scheme is NOT decided here, and a literal https would be wrong: AllowedDestinations names an address the deployment reaches inside its own network, over plain HTTP, and the policy lifts the scheme restriction for exactly those. Refusing them at registration while the fetch allows them would make one fetched endpoint disagree with the other about the same address.