Client class models an OpenID Connect or OAuth 2.0 client -
e.g. a native application, a web application or a JS-based application.
- Specifies if client is enabled. Defaults to true.
- Unique ID of the client
- List of client secrets - credentials to access the token endpoint.
- Specifies whether this client needs a secret to request tokens from the token endpoint (defaults to
- Specifies whether this client needs to wrap the authorize request parameters in a JWT (defaults to
- Specifies the grant types the client is allowed to use. Use the
GrantTypesclass for common combinations.
- Specifies whether clients using an authorization code based grant type must send a proof key (defaults to
- Specifies whether clients using PKCE can use a plain text code challenge (not recommended - and default to
- Specifies the allowed URIs to return tokens or authorization codes to
- By default a client has no access to any resources - specify the allowed resources by adding the corresponding scopes names
- Specifies whether this client can request refresh tokens (be requesting the
- Specifies whether this client is allowed to receive access tokens via the browser. This is useful to harden flows that allow multiple response types (e.g. by disallowing a hybrid flow client that is supposed to use code id_token to add the token response type and thus leaking the token to the browser.
- Dictionary to hold any custom client-specific values as needed.
- Specifies allowed URIs to redirect to after logout. See the OIDC Connect Session Management spec for more details.
- Specifies logout URI at client for HTTP based front-channel logout. See the OIDC Front-Channel spec for more details.
- Specifies if the user’s session id should be sent to the FrontChannelLogoutUri. Defaults to true.
- Specifies logout URI at client for HTTP based back-channel logout. See the OIDC Back-Channel spec for more details.
- Specifies if the user’s session id should be sent in the request to the BackChannelLogoutUri. Defaults to true.
- Specifies if this client can use local accounts, or external IdPs only. Defaults to true.
- Specifies which external IdPs can be used with this client (if list is empty all IdPs are allowed). Defaults to empty.
UserSsoLifetimeadded in 2.3
- The maximum duration (in seconds) since the last time the user authenticated. Defaults to
null. You can adjust the lifetime of a session token to control when and how often a user is required to reenter credentials instead of being silently authenticated, when using a web application.
- Lifetime to identity token in seconds (defaults to 300 seconds / 5 minutes)
- List of allowed signing algorithms for identity token. If empty, will use the server default signing algorithm.
- Lifetime of access token in seconds (defaults to 3600 seconds / 1 hour)
- Lifetime of authorization code in seconds (defaults to 300 seconds / 5 minutes)
- Maximum lifetime of a refresh token in seconds. Defaults to 2592000 seconds / 30 days
- Sliding lifetime of a refresh token in seconds. Defaults to 1296000 seconds / 15 days
ReUsethe refresh token handle will stay the same when refreshing tokens
OneTimethe refresh token handle will be updated when refreshing tokens. This is the default.
Absolutethe refresh token will expire on a fixed point in time (specified by the AbsoluteRefreshTokenLifetime)
Slidingwhen refreshing the token, the lifetime of the refresh token will be renewed (by the amount specified in SlidingRefreshTokenLifetime). The lifetime will not exceed AbsoluteRefreshTokenLifetime.
- Gets or sets a value indicating whether the access token (and its claims) should be updated on a refresh token request.
- Specifies whether the access token is a reference token or a self contained JWT token (defaults to Jwt).
- Specifies whether JWT access tokens should have an embedded unique ID (via the jti claim). Defaults to
- Allows settings claims for the client (will be included in the access token).
- If set, the client claims will be sent for every flow. If not, only for client credentials flow (default is false)
- When requesting both an id token and access token, should the user claims always be added to the id token instead of requiring the client to use the userinfo endpoint. Default is false.
- If set, the prefix client claim types will be prefixed with. Defaults to client_. The intent is to make sure they don’t accidentally collide with user claims.
- Salt value used in pair-wise subjectId generation for users of this client.
- Specifies whether a consent screen is required. Defaults to
- Specifies whether user can choose to store consent decisions. Defaults to
- Lifetime of a user consent in seconds. Defaults to null (no expiration).
- Client display name (used for logging and consent screen)
- URI to further information about client (used on consent screen)
- URI to client logo (used on consent screen)
- Specifies the type of user code to use for the client. Otherwise falls back to default.
- Lifetime to device code in seconds (defaults to 300 seconds / 5 minutes)