IdentityServerBearerTokenAuthenticationOptions class has a number of options to influence token validation.
Authoritysets the base address of IdentityServer. This allows for auto configuration (JWTs) and access to the token validation endpoint (reference tokens).
RequiredScopesset the value of one OR more
scopeclaims that are expected to be present in the access token.
ValidationModecan be either set to
ValidationEndpoint(JWTs and reference tokens using the validation endpoint - and
Bothfor JWTs locally and reference tokens using the validation endpoint (defaults to
TokenProviderdefines how to get the token from the HTTP request. By default the
Authorizationheader is inspected. A custom token provider could be useful for getting the token from an alternative header or a query string.
NameClaimTypesets the name claim type of the
RoleClaimTypesets the role claim type of the
PreserveAccessTokenif set to true a claim of type
tokenis created that holds the incoming access token (defaults to
false). This is useful for situations where you want to forward the access token to another API, e.g. for calling the user info endpoint.
BackChannelHttpHandlerallows specifying a custom handler for all back-channel communication (e.g. to the discovery endpoint or the token validation endpoint).
BackchannelCertificateValidatorallows specifying a custom certificate validator for the back-channel communication.
DelayLoadMetadatatells the middleware to not load the metadata at application startup time, but on the first incoming request (defaults to
false). This is useful when the discovery endpoint is not available at startup time - e.g. when the consumer is hosted in the same process as the token service.
Static Configuration for JWTs
Instead of automatically obtaining the configuration from the discovery endpoint, you can also statically configure the middleware
IssuerNameset the expected issuer name of IdentityServer
SigningCertificatesets the X.509 certificate to validate the access token signatur
Remark This is useful, if for some reaso the discovery document is not available to you, e.g. when running IdentityServer and the client or API in the same web application.
Using the Introspection Endpoint (added in v2.2)
Version 2.2 of IdentityServer added support for the token introspection specification. This is the recommended technique when using reference tokens (see here).
In this case you need to specify the
ClientSecret to match the name and secret of the scope configuration
in IdentityServer (see scopes)
When using reference tokens, you probably don’t want to make a round-trip to IdentityServer for each incoming request. In this case you can cache the validation outcome locally.
EnableValidationResultCacheenables/disables caching of the validation outcome (defaults to
ValidationResultCacheDurationset the cache duration (defaults to 5 minutes).
ValidationResultCachesets the caching implemenation. Defaults to an in-memory cache but can be customized by implementing