OidcOptions Class

OidcOptions.AuthorizationCodeLength Property

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

public int AuthorizationCodeLength { get; set; }

Property Value

BackChannelAuthenticationOptions

OidcOptions.BackChannelAuthentication Property

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

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

Property Value

OidcOptions.CheckSessionCookie Property

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.

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

Property Value

CheckSessionCookieOptions

OidcOptions.Clients Property

A collection of client configurations supported by this OIDC server. Each 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.

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

Property Value

System.Collections.Generic.IEnumerable<ClientInfo >

OidcOptions.ConsentUri Property

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.

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

Property Value

OidcOptions.DefaultAuthorizationResponseEncryptionAlgorithm Property

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.

public string DefaultAuthorizationResponseEncryptionAlgorithm { get; set; }

Property Value

Remarks

Separate from 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

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.

public string DefaultContentEncryptionAlgorithm { get; set; }

Property Value

OidcOptions.DefaultResourceIndicator Property

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.

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

Property Value

DeviceAuthorizationOptions

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

The security profile this deployment holds EVERY client to, whatever SecurityProfile each one names for itself. A single-profile deployment sets this once - for example to 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 demands nothing, leaving each client governed by whatever it names for itself, or by its individual metadata flags where it names nothing.

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

Property Value

ClientSecurityProfile

OidcOptions.DeviceAuthorization Property

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

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

Property Value

OidcOptions.Discovery Property

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.

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

Property Value

DiscoveryOptions

OidcOptions.DPoP Property

Configuration options for OAuth 2.0 DPoP (RFC 9449), governing the Abblix.Oidc.Server.Features.DPoP.ProofValidator behaviour and related primitives.

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

Property Value

DPoPOptions

OidcOptions.EnabledEndpoints Property

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

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

Property Value

OidcEndpoints

OidcOptions.EncryptionKeys Property

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.

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

Property Value

System.Collections.Generic.IReadOnlyCollection<JsonWebKey >

OidcOptions.FilterAuthorizationDetailsByLocation Property

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.

public bool FilterAuthorizationDetailsByLocation { get; set; }

Property Value

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

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.

public int GrantIdLength { get; set; }

Property Value

OidcOptions.IgnoreParametersOutsideRequestObject Property

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.

public bool IgnoreParametersOutsideRequestObject { get; set; }

Property Value

OidcOptions.InteractionUri Property

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.

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

Property Value

OidcOptions.Issuer Property

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.

public string? Issuer { get; set; }

Property Value

OidcOptions.JwtAuthorizationResponseExpiresIn Property

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.

public System.TimeSpan JwtAuthorizationResponseExpiresIn { get; set; }

Property Value

OidcOptions.JwtBearer Property

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

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

Property Value

JwtBearerOptions

OidcOptions.KeyRolloverPropagation Property

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.

public System.TimeSpan KeyRolloverPropagation { get; set; }

Property Value

OidcOptions.LicenseJwt Property

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.

public string? LicenseJwt { get; set; }

Property Value

OidcOptions.LoginSessionExpiresIn Property

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.

public System.TimeSpan LoginSessionExpiresIn { get; set; }

Property Value

OidcOptions.LoginUri Property

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.

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

Property Value

System.Nullable<System.Int64 >

OidcOptions.MaxRegistrationRequestSize Property

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.

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

Property Value

Remarks

The bound exists because these endpoints parse a foreign document and keep the members they do not model (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

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.

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

Property Value

NewClientOptions

OidcOptions.PkceAndNonceReuseDetectionInterval Property

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.

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

Property Value

System.Nullable<System.TimeSpan >

OidcOptions.PushedAuthorizationRequestExpiresIn Property

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.

public System.TimeSpan PushedAuthorizationRequestExpiresIn { get; set; }

Property Value

OidcOptions.RegistrationUri Property

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 is used instead, so hosts whose login page also offers registration need no extra configuration.

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

Property Value

OidcOptions.RequestUriLength Property

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

public int RequestUriLength { get; set; }

Property Value

OidcOptions.RequestUriParameterName Property

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.

public string RequestUriParameterName { get; set; }

Property Value

OidcOptions.RequireInitialAccessToken Property

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.

public bool RequireInitialAccessToken { get; set; }

Property Value

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

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

public bool RequirePushedAuthorizationRequests { get; set; }

Property Value

OidcOptions.RequireSignedRequestObject Property

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

public bool RequireSignedRequestObject { get; set; }

Property Value

OidcOptions.Resources Property

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.

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

Property Value

ResourceDefinition []

OidcOptions.RevocationCutoffRetention Property

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

public System.TimeSpan RevocationCutoffRetention { get; set; }

Property Value

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

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

public System.TimeSpan RevocationCutoffSkew { get; set; }

Property Value

System.Collections.Generic.HashSet<System.String >

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

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 with a database- or cache-backed implementation.

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

Property Value

OidcOptions.RevokeSessionTokensOnLogout Property

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

public bool RevokeSessionTokensOnLogout { get; set; }

Property Value

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

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.

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

Property Value

ScopeDefinition []

OidcOptions.ServiceTokens Property

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 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 to false (for example to keep the access token readable by external resource servers).

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

Property Value

ServiceTokensOptions

OidcOptions.SessionIdLength Property

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

public int SessionIdLength { get; set; }

Property Value

System.Collections.Generic.IReadOnlyCollection<JsonWebKey >

OidcOptions.SigningKeys Property

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.

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

Property Value

OidcOptions.SoftwareStatement Property

Configuration options for software statement validation per RFC 7591 Section 2.3.

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

Property Value

SoftwareStatementOptions

OidcOptions.TokenIdLength Property

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

public int TokenIdLength { get; set; }

Property Value