Client Configuration

Detailed explanation of all configuration fields available when creating or editing a client.

This page describes all configuration fields available for clients in IdentitySuite. The sections are common to both the creation and modification processes, ensuring a unified experience. The only difference is the Client Type tab, which appears exclusively when creating a new client to simplify setup with predefined values.

Client Type

This tab is shown only during the creation of a new client. It allows you to select a predefined Client Type, which automatically applies recommended defaults for authentication flows. When editing an existing client, this tab is hidden since the type has already been defined.

Single Page Client

Uses Authorization Code Flow with PKCE. Recommended for browser-based apps.

Web Application

Server-side application using Authorization Code Flow. Requires client secret.

Native

Mobile or desktop apps using Authorization Code Flow with PKCE.

Machine

Uses Client Credentials Flow. Suitable for backend services and daemons.

Device

Uses Device Flow with external browser. Ideal for input-constrained devices.

SPA (Legacy)

Uses Implicit Flow. Deprecated and not recommended for new applications.

Each type applies recommended defaults to simplify setup, but all values can be customized later in the configuration process.

Name

Defines the basic identity of the client. Values entered here are used for display, identification, and flow validation.

  • Client Id: Unique identifier for the client.
  • Display Name: Human-readable name shown in portals and consent screens.
  • Client Type: Determines how redirect URIs and flows are validated. Choose Web for browser-based apps or Native for mobile/desktop clients.

Credentials

This section configures the authentication model of the client, including client type, consent behavior and secret management.

Defines how the client authenticates with the server. Public clients do not use a secret and are typically used for browser-based or native applications. Confidential clients authenticate using a secret and are suited for server-side applications that can securely store credentials.

Determines how user consent is handled during authentication. Options include: systematic (consent is always required on every authorization request), explicit (the user must actively approve the request), external (consent is managed outside the authorization server), and implicit (no consent prompt is shown).

Only applicable to Confidential clients. The secret is used to authenticate the client securely against the token endpoint. Keep this value private, never expose it in client-side code, and rotate it periodically as part of your security policy.

Client URLs

This section defines the URLs used during authentication and logout flows. These values must match the client's actual endpoints and are validated during runtime.

Specifies the URLs to which the authorization server redirects the user after successful authentication. Must match exactly with the client's configured endpoints.

Defines where the user is redirected after logging out. Useful for returning users to a landing page or confirmation screen.

Token Request

This section defines how the client requests tokens and which flows and response types are enabled. These settings directly affect authentication behavior and protocol compliance.

Specifies which OAuth 2.0 flows the client is allowed to use. Common options include: AuthorizationCode, ClientCredentials, DeviceCode, Implicit, Password, RefreshToken, and TokenExchange. Enabling only the necessary flows improves security and clarity.

Defines the types of responses the authorization server can return. Examples include: Code, IdToken, Token, and combinations like CodeIdToken. These must align with the selected grant types and client capabilities.

Additional protocol-level constraints. Common options: ProofKeyForCodeExchange (PKCE) enhances security for public clients, and PushedAuthorizationRequests (PAR) improves request integrity and confidentiality.

Allowed Scopes

This section defines which scopes the client is allowed to request during authentication. Scopes determine the level of access and the type of user information returned in tokens.

Standard OpenID Connect scopes that expose user profile information. Common options include: profile (basic user info), email, phone, address, and roles. Only the selected scopes will be included in issued tokens.

Custom scopes that grant access to protected APIs. These scopes can be defined and managed through the Scopes menu, allowing fine-grained control over API permissions and exposure.

Advanced

This section provides fine-grained control over protocol endpoints, custom properties, and token lifetimes. These settings are intended for advanced scenarios and should be adjusted with care.

Enables or disables specific protocol endpoints exposed by the client. Common options include: Authorization, Token, EndSession, Introspection, Revocation, DeviceAuthorization, and PushedAuthorization. Disabling unused endpoints can improve security posture.

Custom key-value pairs used to store metadata or configuration flags. These are client-specific and may be used by external systems or extensions.

Defines the validity duration for issued tokens and codes. Each type (e.g. Authorization Code, Access Token, Refresh Token) can be configured independently using global time values.

Consent

This section allows you to define the consent message shown to users during their first login via the OpenIddict authorize flow. The editor supports HTML formatting and is used to present a clear explanation of the client's purpose and requested permissions.

Use the rich text editor to compose a custom message that will be displayed on the consent screen. You can include headings, paragraphs, links, and styling to help users understand why the client is requesting access.

Security

This section contains destructive security actions scoped to this client. Use these operations only when the client is suspected to be compromised or when an emergency revocation is required.

Immediately revokes all active tokens issued for this client, including access tokens and refresh tokens. Users authenticated through this client will be required to complete a new authorization flow to obtain fresh tokens.

When to use this: if the client secret has been leaked, if suspicious token activity has been detected for this client, or as part of a targeted incident response affecting only this application. For a system-wide compromise, use the global revocation action available on the Dashboard instead.