#### [Abblix\.Oidc\.Server](https://www.abblix.com/en/docs/api/abblix-oidc-server 'index')
### [Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation')

## 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\.

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

Inheritance [System\.Object](https://learn.microsoft.com/en-us/dotnet/api/system.object 'System\.Object') → [SyncClientRegistrationContextValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SyncClientRegistrationContextValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.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](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.BackChannelLogoutUriValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.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](https://learn.microsoft.com/en-us/dotnet/api/system.uri.host '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](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.SecureHttpFetch.SecureHttpFetchOptions#Abblix.Oidc.Server.Features.SecureHttpFetch.SecureHttpFetchOptions.AllowedDestinations 'Abblix\.Oidc\.Server\.Features\.SecureHttpFetch\.SecureHttpFetchOptions\.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 {#Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.JwksUriValidator.JwksUriValidator(Abblix.Oidc.Server.Features.SecureHttpFetch.ISecureUriValidator)}

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\.

```csharp
public JwksUriValidator(Abblix.Oidc.Server.Features.SecureHttpFetch.ISecureUriValidator uriValidator);
```
#### Parameters

###### `uriValidator` [ISecureUriValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.SecureHttpFetch.ISecureUriValidator 'Abblix\.Oidc\.Server\.Features\.SecureHttpFetch\.ISecureUriValidator') {#Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.JwksUriValidator.JwksUriValidator(Abblix.Oidc.Server.Features.SecureHttpFetch.ISecureUriValidator).uriValidator}

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](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.BackChannelLogoutUriValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.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](https://learn.microsoft.com/en-us/dotnet/api/system.uri.host '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](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.SecureHttpFetch.SecureHttpFetchOptions#Abblix.Oidc.Server.Features.SecureHttpFetch.SecureHttpFetchOptions.AllowedDestinations 'Abblix\.Oidc\.Server\.Features\.SecureHttpFetch\.SecureHttpFetchOptions\.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.