ServiceTokensAlgorithmsValidator Class

Fails loudly at startup when a configured ServiceTokensOptions names a signing or key-management algorithm that no registered signer or encryptor can produce, instead of letting the contradiction surface at token-issuance time as a per-request failure. The accepted sets are read from the live JWT registrations, the same union OpenID Connect discovery advertises, so a host that adds or replaces an algorithm is validated against exactly what it registered - no static allow-list to keep in sync.

public sealed class ServiceTokensAlgorithmsValidator : Microsoft.Extensions.Options.IValidateOptions<Abblix.Oidc.Server.Common.Configuration.OidcOptions>

Inheritance System.Object → ServiceTokensAlgorithmsValidator

Implements Microsoft.Extensions.Options.IValidateOptions<OidcOptions >

Constructors

ServiceTokensAlgorithmsValidator(IJsonWebTokenCreator, IKeyCustodian) Constructor

public ServiceTokensAlgorithmsValidator(Abblix.Jwt.IJsonWebTokenCreator jwtCreator, Abblix.Jwt.ExternalKeys.IKeyCustodian? custodian=null);

Parameters

`jwtCreator` IJsonWebTokenCreator

Source of the registered signing and JWE key-management algorithms. Kept lightweight on purpose, so validating options does not drag the runtime token pipeline (and its storage) into startup.

`custodian` IKeyCustodian

Present when the host holds its keys in an external custodian (a Vault or Key Vault backend), absent when they come from EncryptionKeys. It is a registration marker only, and is never called here: it answers where the keys come from without reading them, and without reading the options that are still being created. Injecting the key provider instead would re-enter Microsoft.Extensions.Options.IOptions<>.Value from inside its own creation.

ServiceTokenOptions

ServiceTokensOptions