#### [Abblix\.Oidc\.Server](https://www.abblix.com/docs/api/abblix-oidc-server 'index')
### [Abblix\.Oidc\.Server\.Common\.Configuration](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration 'Abblix\.Oidc\.Server\.Common\.Configuration')

## OidcOptions Class

The root of the OIDC configuration\. Provides the simplest way to configure and start your OIDC server\.

```csharp
public record OidcOptions : System.IEquatable<Abblix.Oidc.Server.Common.Configuration.OidcOptions>
```

Inheritance [System\.Object](https://learn.microsoft.com/en-us/dotnet/api/system.object 'System\.Object') → OidcOptions

Implements [System\.IEquatable&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.iequatable-1 'System\.IEquatable\`1')[OidcOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.iequatable-1 'System\.IEquatable\`1')
### Properties

## OidcOptions\.AccountSelectionUri Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.AccountSelectionUri}

The URL to a user interface or service that allows users to select an account during the authentication process\.
This is useful in scenarios where users have multiple accounts and need to choose which one to use for signing in\.

```csharp
public System.Uri? AccountSelectionUri { get; set; }
```

#### Property Value
[System\.Uri](https://learn.microsoft.com/en-us/dotnet/api/system.uri 'System\.Uri')

## OidcOptions\.AuthorizationCodeLength Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.AuthorizationCodeLength}

The standard length of the authorization code generated by the server\.

```csharp
public int AuthorizationCodeLength { get; set; }
```

#### Property Value
[System\.Int32](https://learn.microsoft.com/en-us/dotnet/api/system.int32 'System\.Int32')

## OidcOptions\.BackChannelAuthentication Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.BackChannelAuthentication}

Configuration options for the backchannel authentication flow,
used in scenarios such as Client\-Initiated Backchannel Authentication \(CIBA\)\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.BackChannelAuthenticationOptions BackChannelAuthentication { get; set; }
```

#### Property Value
[BackChannelAuthenticationOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.BackChannelAuthenticationOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.BackChannelAuthenticationOptions')

## OidcOptions\.CheckSessionCookie Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.CheckSessionCookie}

Options related to the check session mechanism in OIDC\. This configuration controls how the OIDC server manages
session state information, allowing clients to monitor the login session's status\. Properly configuring these
options ensures that clients can react to session changes \(e\.g\., logout\) in a timely and secure manner\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.CheckSessionCookieOptions CheckSessionCookie { get; set; }
```

#### Property Value
[CheckSessionCookieOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.CheckSessionCookieOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.CheckSessionCookieOptions')

## OidcOptions\.Clients Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.Clients}

A collection of client configurations supported by this OIDC server\. Each [ClientInfo](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.ClientInformation.ClientInfo 'Abblix\.Oidc\.Server\.Features\.ClientInformation\.ClientInfo') object
defines the settings and capabilities of a registered client, including client ID, client secrets,
redirect URIs, and other OAuth2/OIDC parameters\. Proper client configuration is essential for securing client
applications and enabling them to interact with the OIDC server according to the OAuth2 and OIDC specifications\.

```csharp
public System.Collections.Generic.IEnumerable<Abblix.Oidc.Server.Features.ClientInformation.ClientInfo> Clients { get; set; }
```

#### Property Value
[System\.Collections\.Generic\.IEnumerable&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ienumerable-1 'System\.Collections\.Generic\.IEnumerable\`1')[ClientInfo](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.ClientInformation.ClientInfo 'Abblix\.Oidc\.Server\.Features\.ClientInformation\.ClientInfo')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ienumerable-1 'System\.Collections\.Generic\.IEnumerable\`1')

## OidcOptions\.ConsentUri Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.ConsentUri}

The URL to a user interface or service for obtaining user consent during the authentication process\. Consent is
often required when the client application requests access to user data or when sharing information between
different parties\. This URI should point to a page or API that can manage consent workflows and communicate
the user's decisions back to the OIDC server\.

```csharp
public System.Uri? ConsentUri { get; set; }
```

#### Property Value
[System\.Uri](https://learn.microsoft.com/en-us/dotnet/api/system.uri 'System\.Uri')

## OidcOptions\.DefaultAuthorizationResponseEncryptionAlgorithm Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DefaultAuthorizationResponseEncryptionAlgorithm}

The content encryption algorithm used for an encrypted authorization response \(JARM\) when the client
registered `authorization_encrypted_response_alg` but omitted
`authorization_encrypted_response_enc`\.

```csharp
public string DefaultAuthorizationResponseEncryptionAlgorithm { get; set; }
```

#### Property Value
[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')

### Remarks
Separate from [DefaultContentEncryptionAlgorithm](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DefaultContentEncryptionAlgorithm 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions\.DefaultContentEncryptionAlgorithm') because the specification names a
different value for this one response: JWT Secured Authorization Response Mode section 3 says that
"if authorization\_encrypted\_response\_alg is specified, the default for this value is A128CBC\-HS256"\.
A client registering only the key\-management algorithm expects that, so the server has to encrypt
with it or produce a response the client cannot read\.
It is a setting rather than a constant so a deployment whose clients all understand a stronger
algorithm can raise the floor, the same way the general default can be raised\.

## OidcOptions\.DefaultContentEncryptionAlgorithm Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DefaultContentEncryptionAlgorithm}

The default content encryption algorithm used for encrypting JWT tokens\.
Per RFC 7518 Section 5, specifies how the JWT payload is encrypted using the Content Encryption Key \(CEK\)\.
Common values: A256CBC\-HS512, A128CBC\-HS256, A256GCM, A128GCM\.
Defaults to A256CBC\-HS512 for maximum security\.

```csharp
public string DefaultContentEncryptionAlgorithm { get; set; }
```

#### Property Value
[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')

## OidcOptions\.DefaultResourceIndicator Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DefaultResourceIndicator}

The resource an access token is minted for when the request names none\. Left null, the token's
`aud` falls back to the client identifier, which is what prior versions did\.

```csharp
public System.Uri? DefaultResourceIndicator { get; set; }
```

#### Property Value
[System\.Uri](https://learn.microsoft.com/en-us/dotnet/api/system.uri 'System\.Uri')

### Remarks
RFC 9068 Section 3 requires an authorization server to "use a default resource indicator in the \`aud\`
claim" when a request carries no `resource` parameter, and Section 4 tells a resource server to
reject a token whose `aud` does not name it\. A client identifier names the party that asked for the
token rather than the one meant to consume it, so a conforming resource server should refuse it; a
deployment with one API therefore says so here once, instead of teaching every client to send
`resource`\.
This is opt\-in because the value is read by every resource server in the deployment: changing it is a
change to their contract, not to this server's configuration alone\. The fallback is unchanged until a
host states otherwise\. Must be an absolute URI naming a registered [Resources](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions#Abblix.Oidc.Server.Common.Configuration.OidcOptions.Resources 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions\.Resources') entry \-
startup refuses anything else, since a token minted for a resource this server does not know is one
nobody can accept\.

## OidcOptions\.DefaultSecurityProfile Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DefaultSecurityProfile}

The security profile this deployment holds EVERY client to, whatever
[SecurityProfile](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.ClientInformation.ClientInfo#Abblix.Oidc.Server.Features.ClientInformation.ClientInfo.SecurityProfile 'Abblix\.Oidc\.Server\.Features\.ClientInformation\.ClientInfo\.SecurityProfile') each one names for itself\. A single\-profile
deployment sets this once \- for example to [Fapi2](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Constants.ClientSecurityProfile#Abblix.Oidc.Server.Common.Constants.ClientSecurityProfile.Fapi2 'Abblix\.Oidc\.Server\.Common\.Constants\.ClientSecurityProfile\.Fapi2') \- and
every client is held to the FAPI 2\.0 control bundle\.
This is a floor rather than a default: a client can ask for more and no registration can take
it out from under what is set here\. The default [None](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Constants.ClientSecurityProfile#Abblix.Oidc.Server.Common.Constants.ClientSecurityProfile.None 'Abblix\.Oidc\.Server\.Common\.Constants\.ClientSecurityProfile\.None')
demands nothing, leaving each client governed by whatever it names for itself, or by its
individual metadata flags where it names nothing\.

```csharp
public Abblix.Oidc.Server.Common.Constants.ClientSecurityProfile DefaultSecurityProfile { get; set; }
```

#### Property Value
[ClientSecurityProfile](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Constants.ClientSecurityProfile 'Abblix\.Oidc\.Server\.Common\.Constants\.ClientSecurityProfile')

## OidcOptions\.DeviceAuthorization Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DeviceAuthorization}

Configuration options for the Device Authorization Grant \(RFC 8628\),
used for devices with limited input capabilities\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.DeviceAuthorizationOptions? DeviceAuthorization { get; set; }
```

#### Property Value
[DeviceAuthorizationOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.DeviceAuthorizationOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.DeviceAuthorizationOptions')

## OidcOptions\.Discovery Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.Discovery}

Configuration options for OIDC discovery\. These options control how the OIDC server advertises its capabilities
and endpoints to clients through the OIDC Discovery mechanism\. Proper configuration ensures that clients can
dynamically discover information about the OIDC server, such as URLs for authorization, token, userinfo, and
JWKS endpoints, supported scopes, response types, and more\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.DiscoveryOptions Discovery { get; set; }
```

#### Property Value
[DiscoveryOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.DiscoveryOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.DiscoveryOptions')

## OidcOptions\.DPoP Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DPoP}

Configuration options for OAuth 2\.0 DPoP \(RFC 9449\), governing the
[Abblix\.Oidc\.Server\.Features\.DPoP\.ProofValidator](https://learn.microsoft.com/en-us/dotnet/api/abblix.oidc.server.features.dpop.proofvalidator 'Abblix\.Oidc\.Server\.Features\.DPoP\.ProofValidator') behaviour and related primitives\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.DPoPOptions DPoP { get; set; }
```

#### Property Value
[DPoPOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.DPoPOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.DPoPOptions')

## OidcOptions\.EnabledEndpoints Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.EnabledEndpoints}

Specifies which OIDC endpoints are enabled on the server\. This property allows for fine\-grained control over
the available functionality, enabling or disabling specific endpoints based on the server's role, security
considerations, or operational requirements\. Defaults to [Base](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcEndpoints#Abblix.Oidc.Server.Common.Configuration.OidcEndpoints.Base 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcEndpoints\.Base') \- the core
interactive OIDC set plus PAR and RP\-initiated logout\. The six niche or security\-sensitive endpoints
\(CheckSession, Revocation, Introspection, dynamic client registration, CIBA and device authorization\) are
off by default and each turned on by its dedicated `AddX()` opt\-in, which registers the feature and
re\-enables the corresponding flag\. Leaving them off keeps a server that never opts in from advertising \- or
validating \- an endpoint it was never asked to serve\. Setting this to [All](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcEndpoints#Abblix.Oidc.Server.Common.Configuration.OidcEndpoints.All 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcEndpoints\.All') only
re\-advertises and routes every endpoint \- the handler for each opt\-in endpoint \(CheckSession, Revocation,
Introspection, dynamic client registration, CIBA, device authorization\) is still registered solely by its
`AddX()` call, so `All` restores the previous every\-endpoint\-on behaviour only when combined with
all of those opt\-in calls\. Setting `All` without them advertises and routes endpoints whose handlers are
absent, so every request to such an endpoint fails at runtime\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.OidcEndpoints EnabledEndpoints { get; set; }
```

#### Property Value
[OidcEndpoints](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcEndpoints 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcEndpoints')

## OidcOptions\.EncryptionKeys Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.EncryptionKeys}

The collection of JSON Web Keys \(JWK\) used for encrypting tokens or sensitive information sent to the clients\.
Encryption is essential for protecting sensitive data within tokens, especially when tokens are passed through
less secure channels or when storing tokens on the client side\.
These keys are used to encrypt ID tokens and, optionally, access tokens when the OIDC server sends them to clients\.
Clients use the corresponding public keys to decrypt the tokens and access the contained claims\.

```csharp
public System.Collections.Generic.IReadOnlyCollection<Abblix.Jwt.JsonWebKey> EncryptionKeys { get; set; }
```

#### Property Value
[System\.Collections\.Generic\.IReadOnlyCollection&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ireadonlycollection-1 'System\.Collections\.Generic\.IReadOnlyCollection\`1')[JsonWebKey](https://www.abblix.com/docs/api/abblix-jwt/Abblix.Jwt.JsonWebKey 'Abblix\.Jwt\.JsonWebKey')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ireadonlycollection-1 'System\.Collections\.Generic\.IReadOnlyCollection\`1')

## OidcOptions\.FilterAuthorizationDetailsByLocation Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.FilterAuthorizationDetailsByLocation}

Whether an access token carries only the `authorization_details` entries whose
`locations` name one of its audiences\. Off, every granted entry is emitted, which is what
prior versions did\.

```csharp
public bool FilterAuthorizationDetailsByLocation { get; set; }
```

#### Property Value
[System\.Boolean](https://learn.microsoft.com/en-us/dotnet/api/system.boolean 'System\.Boolean')

### Remarks
A deployment fact rather than a protocol one, which is why it is a switch and not a default\. RFC
9396 §2\.2 says `locations` "typically" holds URIs identifying resource servers, and §9\.1's own
worked example pairs a client\-style `aud` with a resource URI in `locations` \- so the two
members are not required to be drawn from the same namespace, and comparing them is only meaningful
where a deployment has decided they are\. §7 leaves what an access token carries to the authorization
server where the client did not ask, and §13 asks for need\-to\-know "as determined by local policy"\.
This is that policy, stated once\.

The shape this was written for: several resource servers, every access token that carries
authorization details minted for a `resource`, and each server's `locations` written
exactly as the resource indicator it is registered under\. That is RFC 9396 §12's
multiple\-resource\-server case, which is what `locations` was defined for\. Matching a deployment
against that description is the operator's judgement, not a recommendation made here\.

With no [Resources](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions#Abblix.Oidc.Server.Common.Configuration.OidcOptions.Resources 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions\.Resources') registered and no token exchange in use, the audience is the issuer
on every token and the filter can only delete: nothing can put a resource in the audience for a
`locations` value to match\. That combination is not refused at startup, because it cannot be
told apart there from a deployment whose audiences arrive through RFC 8693 token exchange, where
they come from the client's own allowlist rather than from this list and the filter works\.

Turn it on and an entry naming only other resource servers stops travelling to this one, which is
what §9\.1 recommends where the comparison holds\. Turn it on where it does not \- RFC 8693 audiences
are opaque logical names, and a [DefaultResourceIndicator](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DefaultResourceIndicator 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions\.DefaultResourceIndicator') names one API while
`locations` name others \- and every located entry disappears from every token\. The switch is
off until a host says the two agree, because nothing here can check that they do\.

The case worth knowing about is not a misconfiguration\. A request that names no resource gets the
issuer as its audience, and the issuer names this server rather than any resource, so EVERY located
entry is dropped from that token\. Correct under the policy \- such a token is addressed here, and an
entry located elsewhere cannot be exercised with it \- and it means a deployment using resource
indicators for its APIs while also issuing ordinary OpenID Connect tokens loses located entries from
all of the latter\. RFC 9396 Appendix A\.1 is exactly that shape: it locates an entry at the UserInfo
endpoint, which no resource indicator names, so an opted\-in deployment following that example loses
the entry from every token it issues\.

Worth knowing, and NOT a cost of turning this on: introspection already treats an entry with no
`locations` the other way round, withholding it from a caller that did not register for it\. A
resource server can read such an entry out of the token and not get it back when it introspects the
same token, and that holds with this setting off as well\.

The refresh token is never filtered: it is read by this server rather than by a resource server, and
it is what a later refresh for a DIFFERENT resource is rebuilt from\.

## OidcOptions\.GrantIdLength Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.GrantIdLength}

Specifies the length, in random bytes, of the refresh\-token grant identifier \(the `grant_id`
claim\)\. The grant id binds every refresh token of one authorization grant into a single lineage for
rotation and family revocation \(RFC 9700 Section 4\.14\.2\), so it must carry enough entropy to make the
identifier unguessable\.

```csharp
public int GrantIdLength { get; set; }
```

#### Property Value
[System\.Int32](https://learn.microsoft.com/en-us/dotnet/api/system.int32 'System\.Int32')

## OidcOptions\.IgnoreParametersOutsideRequestObject Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.IgnoreParametersOutsideRequestObject}

Governs how a request object resolves a parameter that appears both inside the object and in the
OAuth query syntax \- a choice between two specifications\. When `false` \(the default\), request\-object
processing follows the OpenID Connect Core §6\.1 merge semantics: the object's values supersede those
passed outside it, but a parameter passed only outside the object is still used\. Set to `true` for
the strict RFC 9101 §6\.3 rule, where the authorization request is exactly the content of the object and
any parameter passed outside it is ignored \("the authorization server MUST only use the parameters in
the Request Object"\)\. The strict rule suits FAPI\-style OAuth deployments; as an OpenID Provider the
server defaults to the merge behaviour, since strict processing would drop parameters that existing
OpenID Connect clients commonly pass outside the object\. A client held to the FAPI 2\.0 security profile
is processed strictly regardless of this global default\.
This switch affects only parameter exclusivity; the other RFC 9101 §6\.3 requirement \- that a
`client_id` or `response_type` present both inside and outside the object be identical \- is
enforced in both modes and cannot be turned off\.

```csharp
public bool IgnoreParametersOutsideRequestObject { get; set; }
```

#### Property Value
[System\.Boolean](https://learn.microsoft.com/en-us/dotnet/api/system.boolean 'System\.Boolean')

## OidcOptions\.InteractionUri Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.InteractionUri}

The URL to a user interface or service for handling additional interactions required during the authentication
process\. This can include multiple factor authentication, user consent, or any custom interaction required by
the authentication flow\. The OIDC server can redirect users to this URI when additional interaction is needed\.

```csharp
public System.Uri? InteractionUri { get; set; }
```

#### Property Value
[System\.Uri](https://learn.microsoft.com/en-us/dotnet/api/system.uri 'System\.Uri')

## OidcOptions\.Issuer Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.Issuer}

Represents the unique identifier of the OIDC server\.
It is recommended to use a URL controlled by the entity operating the OIDC server, and it should be
consistent across different environments to maintain trust with client applications\.

```csharp
public string? Issuer { get; set; }
```

#### Property Value
[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')

## OidcOptions\.JwtAuthorizationResponseExpiresIn Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.JwtAuthorizationResponseExpiresIn}

The lifetime of a JARM \(JWT Secured Authorization Response Mode\) `response` JWT\. The authorization
response is consumed by the client immediately upon redirect, so a short window suffices and mostly
absorbs clock skew\. JARM §2\.1 RECOMMENDS a maximum of 10 minutes; deployments with stricter requirements
\(e\.g\. FAPI\) may shorten it\.

```csharp
public System.TimeSpan JwtAuthorizationResponseExpiresIn { get; set; }
```

#### Property Value
[System\.TimeSpan](https://learn.microsoft.com/en-us/dotnet/api/system.timespan 'System\.TimeSpan')

## OidcOptions\.JwtBearer Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.JwtBearer}

Configuration options for JWT Bearer grant type \(RFC 7523\)\.
Defines trusted external identity providers whose JWT assertions can be exchanged for access tokens\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.JwtBearerOptions JwtBearer { get; set; }
```

#### Property Value
[JwtBearerOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.JwtBearerOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.JwtBearerOptions')

## OidcOptions\.KeyRolloverPropagation Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.KeyRolloverPropagation}

The key\-rollover propagation window: how long a newly published signing or encryption key is served at the
JWKS endpoint before the server begins producing tokens with it, giving client JWKS caches time to pick it
up so a rotation never causes a verification or decryption failure\. This single value is the server's
source of truth for rollover timing: the JWKS endpoint derives its `Cache-Control` max\-age from it
\(so a client honouring the header is never staler than this window\), and a key provider that rotates keys
dynamically \(for example the external\-custodian provider addressing a versioned HSM/KMS key\) holds a freshly
rotated key as announced\-but\-not\-yet\-signing for this long\. Size it to at least the longest a client may
cache the JWKS\. A static, non\-rotating key set is unaffected by the activation gate but still gets this as
the advertised JWKS cache lifetime\. Defaults to one hour\.

```csharp
public System.TimeSpan KeyRolloverPropagation { get; set; }
```

#### Property Value
[System\.TimeSpan](https://learn.microsoft.com/en-us/dotnet/api/system.timespan 'System\.TimeSpan')

## OidcOptions\.LicenseJwt Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.LicenseJwt}

A JWT used for licensing and configuration validation of the OIDC service\. This token contains claims that the
OIDC service uses to validate its configuration, features, and licensing status, ensuring the service operates
within its licensed capabilities\. Proper validation of this token is crucial for the service's legal and
functional compliance\.

```csharp
public string? LicenseJwt { get; set; }
```

#### Property Value
[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')

## OidcOptions\.LoginSessionExpiresIn Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.LoginSessionExpiresIn}

The duration after which a login session expires\. This setting determines how long a user's authentication
session remains valid before requiring re\-authentication\. Configuring this duration is essential for balancing
security concerns with usability, particularly in environments with varying security requirements\.

```csharp
public System.TimeSpan LoginSessionExpiresIn { get; set; }
```

#### Property Value
[System\.TimeSpan](https://learn.microsoft.com/en-us/dotnet/api/system.timespan 'System\.TimeSpan')

## OidcOptions\.LoginUri Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.LoginUri}

The URL to initiate the login process\. This URI is typically used in scenarios where the OIDC server needs to
direct users to a specific login interface or when integrating with external identity providers\. Configuring
this URI allows the OIDC server to delegate the initial user authentication step to another service or UI\.

```csharp
public System.Uri? LoginUri { get; set; }
```

#### Property Value
[System\.Uri](https://learn.microsoft.com/en-us/dotnet/api/system.uri 'System\.Uri')

## OidcOptions\.MaxRegistrationRequestSize Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.MaxRegistrationRequestSize}

The largest body the registration and update endpoints will read, in bytes, or `null` to leave
the bound entirely to the host\. A body over the limit is answered 413 before it is bound\.

```csharp
public System.Nullable<long> MaxRegistrationRequestSize { get; set; }
```

#### Property Value
[System\.Nullable&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.nullable-1 'System\.Nullable\`1')[System\.Int64](https://learn.microsoft.com/en-us/dotnet/api/system.int64 'System\.Int64')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.nullable-1 'System\.Nullable\`1')

### Remarks
The bound exists because these endpoints parse a foreign document and keep the members they do not
model \([AdditionalMembers](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Model.ClientRegistrationRequest#Abblix.Oidc.Server.Model.ClientRegistrationRequest.AdditionalMembers 'Abblix\.Oidc\.Server\.Model\.ClientRegistrationRequest\.AdditionalMembers')\), which costs several times
the body's own size in memory\. Model binding runs ahead of every validator, including the initial
access token check and the registration access token check, so a bound expressed as a validator
would be paid for after the allocation it is meant to prevent\.

The refusal is about length and never about content. RFC 7591 Section 2 requires the server to
ignore metadata it does not understand, so refusing a registration for carrying unknown members
would contradict it - whereas declining to read an oversized body is not a statement about metadata
at all, and a bound that counted unrecognised members would be.

How it is enforced differs by host, and the difference is worth knowing when sizing capacity.
A minimal API host publishes the value as endpoint metadata the server reads before the body, so
the refusal costs no managed memory - but a server that does not implement
`IHttpMaxRequestBodySizeFeature`, including the in-memory test server, ignores it. An MVC host
enforces it in a resource filter that buffers the body itself, which holds regardless of server and
costs up to this many bytes per concurrent request while the request is refused.

The default is generous next to a real registration: an inline JWKS with several keys, a software
statement and a long list of redirect URIs together stay well under a tenth of it. Raise it for a
deployment that genuinely needs more.

Clearing it adds no bound of ours and removes none of anybody else's: the server's own limit still
applies (Kestrel defaults to 30,000,000 bytes) and so does whatever a reverse proxy in front of it
enforces, which is the point of clearing it. That is why it is expressed as an absent value rather
than as a very large number - a number is still a bound, and a very large one asks an MVC host to
buffer a very large body.

## OidcOptions\.NewClientOptions Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.NewClientOptions}

Configuration options for registering new clients dynamically in the OIDC server\. These options define default
values and constraints for new client registrations, facilitating dynamic and secure client onboarding processes\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.NewClientOptions NewClientOptions { get; init; }
```

#### Property Value
[NewClientOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.NewClientOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.NewClientOptions')

## OidcOptions\.PkceAndNonceReuseDetectionInterval Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.PkceAndNonceReuseDetectionInterval}

Enables detection of a client reusing a constant PKCE `code_challenge` or OpenID Connect
`nonce` across authorization requests, which defeats the transaction\-binding those values provide
\(RFC 9700 Section 2\.1\.1 encourages the authorization server to make a reasonable effort to detect and
prevent it\)\. When set, the server records each value at the moment it issues an authorization code and
rejects a later authorization request from the same client that repeats a value within this interval\.
Recording at code issuance \- not on every authorization request \- means re\-processing one request
across a login or consent redirect is not flagged\. Left `null` \(the default\) the check is off:
a conforming client generates a fresh value per request and is never affected, but a client that
incorrectly reuses a value across separate authorizations would then be rejected, so it is opt\-in\.

```csharp
public System.Nullable<System.TimeSpan> PkceAndNonceReuseDetectionInterval { get; set; }
```

#### Property Value
[System\.Nullable&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.nullable-1 'System\.Nullable\`1')[System\.TimeSpan](https://learn.microsoft.com/en-us/dotnet/api/system.timespan 'System\.TimeSpan')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.nullable-1 'System\.Nullable\`1')

## OidcOptions\.PushedAuthorizationRequestExpiresIn Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.PushedAuthorizationRequestExpiresIn}

The duration for which a Pushed Authorization Request \(PAR\) is valid\. PAR is a security enhancement that allows
clients to pre\-register authorization requests directly with the authorization server\. This duration specifies
the maximum time a pre\-registered request is considered valid, balancing the need for security with usability
in completing the authorization process\.

```csharp
public System.TimeSpan PushedAuthorizationRequestExpiresIn { get; set; }
```

#### Property Value
[System\.TimeSpan](https://learn.microsoft.com/en-us/dotnet/api/system.timespan 'System\.TimeSpan')

## OidcOptions\.RegistrationUri Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RegistrationUri}

The URL of the account\-creation \(registration\) UI the user is redirected to when a client requests
user registration via `prompt=create` \(Initiating User Registration via OpenID Connect 1\.0\)\.
When not set, [LoginUri](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions#Abblix.Oidc.Server.Common.Configuration.OidcOptions.LoginUri 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions\.LoginUri') is used instead, so hosts whose login page also offers
registration need no extra configuration\.

```csharp
public System.Uri? RegistrationUri { get; set; }
```

#### Property Value
[System\.Uri](https://learn.microsoft.com/en-us/dotnet/api/system.uri 'System\.Uri')

## OidcOptions\.RequestUriLength Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RequestUriLength}

The standard length of the request URI generated by the server for Pushed Authorization Requests \(PAR\)\.

```csharp
public int RequestUriLength { get; set; }
```

#### Property Value
[System\.Int32](https://learn.microsoft.com/en-us/dotnet/api/system.int32 'System\.Int32')

## OidcOptions\.RequestUriParameterName Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RequestUriParameterName}

The name of the parameter used by the OIDC server to pass the authorization request identifier\. This parameter
name is used in URLs and requests to reference specific authorization requests, especially in advanced features
like Pushed Authorization Requests \(PAR\)\. Customizing this parameter name can help align with specific client
requirements or naming conventions\.

```csharp
public string RequestUriParameterName { get; set; }
```

#### Property Value
[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')

## OidcOptions\.RequireInitialAccessToken Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RequireInitialAccessToken}

Determines whether the client registration endpoint requires an initial access token in the
Authorization header\. When `true`, POST requests to the registration endpoint must include a valid
Bearer token\. When `false`, open registration is allowed\.

```csharp
public bool RequireInitialAccessToken { get; set; }
```

#### Property Value
[System\.Boolean](https://learn.microsoft.com/en-us/dotnet/api/system.boolean 'System\.Boolean')

### Remarks
The default deviates from a SHOULD deliberately\. RFC 7591 Section 3: "To support open registration and
facilitate wider interoperability, the client registration endpoint SHOULD allow registration requests
with no authorization \(which is to say, with no initial access token in the request\)\." Appendix A\.1\.2
describes the other choice, protected registration, as an equally supported deployment, and that is what
this default picks: an endpoint that mints client credentials to anyone who asks is not a safe starting
point, and a host that wants open registration opts into it in one line\. The trade the specification
names in return is interoperability, since client software cannot register itself unattended\.

## OidcOptions\.RequirePushedAuthorizationRequests Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RequirePushedAuthorizationRequests}

Determines whether the OIDC server requires Pushed Authorization Requests \(PAR\)\.

```csharp
public bool RequirePushedAuthorizationRequests { get; set; }
```

#### Property Value
[System\.Boolean](https://learn.microsoft.com/en-us/dotnet/api/system.boolean 'System\.Boolean')

## OidcOptions\.RequireSignedRequestObject Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RequireSignedRequestObject}

Determines whether request objects must be signed by the client,
enhancing security for certain sensitive operations\.

```csharp
public bool RequireSignedRequestObject { get; set; }
```

#### Property Value
[System\.Boolean](https://learn.microsoft.com/en-us/dotnet/api/system.boolean 'System\.Boolean')

## OidcOptions\.Resources Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.Resources}

The resource definitions supported by the OIDC server\. This setting outlines the resources that clients
can request access to during authorization, ensuring the OIDC server can enforce access control policies
and permissions based on these definitions\.

```csharp
public Abblix.Oidc.Server.Common.Constants.ResourceDefinition[]? Resources { get; set; }
```

#### Property Value
[ResourceDefinition](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Constants.ResourceDefinition 'Abblix\.Oidc\.Server\.Common\.Constants\.ResourceDefinition')[\[\]](https://learn.microsoft.com/en-us/dotnet/api/system.array 'System\.Array')

## OidcOptions\.RevocationCutoffRetention Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RevocationCutoffRetention}

How long a subject\- or session\-level revocation cutoff is kept\.

```csharp
public System.TimeSpan RevocationCutoffRetention { get; set; }
```

#### Property Value
[System\.TimeSpan](https://learn.microsoft.com/en-us/dotnet/api/system.timespan 'System\.TimeSpan')

### Remarks
A cutoff refuses tokens issued before it, so it stops mattering once the longest\-lived token it could
refuse has expired on its own, and keeping it past that costs one small record per revoked principal\.

Dropping it early is the failure that matters, and it is silent: a refresh token issued before a
revocation and still alive when the record expires starts working again, rotates into a fresh one, and
nothing logs anything. Set this to the longest [RefreshToken](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.ClientInformation.ClientInfo#Abblix.Oidc.Server.Features.ClientInformation.ClientInfo.RefreshToken 'Abblix\.Oidc\.Server\.Features\.ClientInformation\.ClientInfo\.RefreshToken')
absolute lifetime any client is configured with. It cannot be derived here - lifetimes are per client
and the client store answers by identifier rather than by enumeration - so the value is yours to keep
in step, and only a non-positive one is refused at startup.

The default covers a month, which is the longest refresh token most deployments issue and far past this
server's own default of eight hours.

## OidcOptions\.RevocationCutoffSkew Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RevocationCutoffSkew}

How far a token may appear to have been issued after a revocation cutoff and still be refused by it\.

```csharp
public System.TimeSpan RevocationCutoffSkew { get; set; }
```

#### Property Value
[System\.TimeSpan](https://learn.microsoft.com/en-us/dotnet/api/system.timespan 'System\.TimeSpan')

### Remarks
The cutoff compares an instant one instance recorded against an `iat` another instance stamped, so
the two come from different clocks\. The error is not symmetric in consequence\. A token that reads as
older than it is gets refused once and the client asks again; a token that reads as newer escapes the
revocation entirely, and because a refresh rotation carries the original `iat` forward it keeps
escaping on every use\. A drift of seconds therefore becomes access that never ends, and nothing
reports it\.

The value is added to the cutoff, so it widens what a revocation catches, and the cost is that it
catches more than the revocation named. A token minted after a legitimate sign-in, but inside this
window of a cutoff, cannot be told apart from a drifted old one and is refused. That is not one
retry - it lasts the whole window, because every token minted inside it carries an issue time inside
it. A user reinstated a moment after being suspended waits this long before their tokens work.

So this is priced against clock drift and nothing else: it must exceed the worst difference between
the instance that stamps a token and the instance that records a revocation, and buy no more than
that. On hosts running NTP the difference is milliseconds, and the default of five seconds is three
orders of magnitude above it while staying short enough to read as a retry. Raise it only for a
deployment that knows its clocks are worse, and price the lockout when doing so.

It applies to tokens alone. An authentication session is judged with no tolerance at all, because
there the same widening would refuse the fresh sign-in a user answers the refusal with, and that
retry lands in the same window - a loop rather than a wait.

Zero is allowed and means the tokens are trusted to carry comparable instants, which is true of a
single-instance deployment and of nothing else.

## OidcOptions\.RevokedInitialAccessTokenSubjects Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RevokedInitialAccessTokenSubjects}

The set of revoked initial access token identifiers \(JWT subject claims\)\.
Tokens whose subject appears in this set will be rejected during client registration\.
For production use with large or dynamic revocation lists, replace
[IInitialAccessTokenRevocationProvider](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Interfaces.IInitialAccessTokenRevocationProvider 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Interfaces\.IInitialAccessTokenRevocationProvider')
with a database\- or cache\-backed implementation\.

```csharp
public System.Collections.Generic.HashSet<string> RevokedInitialAccessTokenSubjects { get; set; }
```

#### Property Value
[System\.Collections\.Generic\.HashSet&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.hashset-1 'System\.Collections\.Generic\.HashSet\`1')[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.hashset-1 'System\.Collections\.Generic\.HashSet\`1')

## OidcOptions\.RevokeSessionTokensOnLogout Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RevokeSessionTokensOnLogout}

Whether ending a session also revokes the tokens issued within it\.

```csharp
public bool RevokeSessionTokensOnLogout { get; set; }
```

#### Property Value
[System\.Boolean](https://learn.microsoft.com/en-us/dotnet/api/system.boolean 'System\.Boolean')

### Remarks
Off, which keeps a refresh token working after the user has signed out of the browser\. That is what a
native application relies on to stay signed in while the web session ends, and turning it on for an
existing deployment would log those users out with nothing in their own code having changed\.

Turn it on where a sign-out is meant to mean the end of access rather than the end of a browser session,
and read the specification's advice as advice. OpenID Connect RP-Initiated Logout 1.0 says nothing about
tokens at all, but Back-Channel Logout 1.0 Section 2.7 does: "Refresh tokens issued without the
offline_access property to a session being logged out SHOULD be revoked. Refresh tokens issued with the
offline_access property normally SHOULD NOT be revoked."

Every refresh token this server mints carries `offline_access`, because that scope is what makes it
issue one at all. So the first sentence applies to nothing here, and the second describes every token
this option would revoke - which is why it is off. Turning it on is a deliberate departure from a
SHOULD NOT, and the word "normally" is what leaves room for it: a deployment whose sign-out is meant to
end access has a reason the specification's default case does not cover.

What it reaches is what a revocation cutoff reaches: refresh tokens, and access tokens a resource server
introspects. An access token validated locally against its signature and expiry never comes back here.

## OidcOptions\.Scopes Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.Scopes}

The supported scopes and their respective claim types, which outline the access permissions and associated data
that clients can request\.
This setting determines what information and operations are available to different clients based on the scopes
they request during authorization\.

```csharp
public Abblix.Oidc.Server.Common.Constants.ScopeDefinition[]? Scopes { get; set; }
```

#### Property Value
[ScopeDefinition](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Constants.ScopeDefinition 'Abblix\.Oidc\.Server\.Common\.Constants\.ScopeDefinition')[\[\]](https://learn.microsoft.com/en-us/dotnet/api/system.array 'System\.Array')

## OidcOptions\.ServiceTokens Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.ServiceTokens}

Per\-type signing and encryption settings for the JWTs the server issues for itself \(access, refresh,
registration access and initial access tokens\)\. Each type signs with RS256 and, when a server
[EncryptionKeys](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions#Abblix.Oidc.Server.Common.Configuration.OidcOptions.EncryptionKeys 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions\.EncryptionKeys') entry is configured, is encrypted to it by default, as in prior versions\.
A host controls each type independently: it can pin the signing algorithm or key, choose the
key\-management algorithm or encryption key, or disable encryption for a specific type by setting that
type's [Encrypt](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.ServiceTokenOptions#Abblix.Oidc.Server.Common.Configuration.ServiceTokenOptions.Encrypt 'Abblix\.Oidc\.Server\.Common\.Configuration\.ServiceTokenOptions\.Encrypt') to `false` \(for example to keep the access token
readable by external resource servers\)\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.ServiceTokensOptions ServiceTokens { get; set; }
```

#### Property Value
[ServiceTokensOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.ServiceTokensOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.ServiceTokensOptions')

## OidcOptions\.SessionIdLength Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.SessionIdLength}

Specifies the length of session identifiers used by the OIDC server\.
The length determines the uniqueness and security of the session identifiers\.

```csharp
public int SessionIdLength { get; set; }
```

#### Property Value
[System\.Int32](https://learn.microsoft.com/en-us/dotnet/api/system.int32 'System\.Int32')

## OidcOptions\.SigningKeys Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.SigningKeys}

The collection of JSON Web Keys \(JWK\) used for signing tokens issued by the OIDC server\.
Signing tokens is a critical security measure that ensures the integrity and authenticity of the tokens\.
These keys are used to digitally sign ID tokens, access tokens, and other JWT tokens issued by the server,
allowing clients to verify that the tokens have not been tampered with and were indeed issued by this server\.
It is recommended to rotate these keys periodically to maintain the security of the token signing process\.

```csharp
public System.Collections.Generic.IReadOnlyCollection<Abblix.Jwt.JsonWebKey> SigningKeys { get; set; }
```

#### Property Value
[System\.Collections\.Generic\.IReadOnlyCollection&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ireadonlycollection-1 'System\.Collections\.Generic\.IReadOnlyCollection\`1')[JsonWebKey](https://www.abblix.com/docs/api/abblix-jwt/Abblix.Jwt.JsonWebKey 'Abblix\.Jwt\.JsonWebKey')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ireadonlycollection-1 'System\.Collections\.Generic\.IReadOnlyCollection\`1')

## OidcOptions\.SoftwareStatement Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.SoftwareStatement}

Configuration options for software statement validation per RFC 7591 Section 2\.3\.

```csharp
public Abblix.Oidc.Server.Common.Configuration.SoftwareStatementOptions SoftwareStatement { get; set; }
```

#### Property Value
[SoftwareStatementOptions](https://www.abblix.com/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.SoftwareStatementOptions 'Abblix\.Oidc\.Server\.Common\.Configuration\.SoftwareStatementOptions')

## OidcOptions\.TokenIdLength Property {#Abblix.Oidc.Server.Common.Configuration.OidcOptions.TokenIdLength}

Specifies the length of token identifiers used by the OIDC server\.
This value determines the length of the unique ID assigned to tokens\.

```csharp
public int TokenIdLength { get; set; }
```

#### Property Value
[System\.Int32](https://learn.microsoft.com/en-us/dotnet/api/system.int32 'System\.Int32')