3.1.1 Clients List

The Clients List section in ZTrust allows administrators to manage clients, configure their authentication and authorization settings, and control how they interact with the system. Clients represent applications or services that request authentication from ZTrust.

  1. Searching for Clients:

You can quickly find a specific client using the search box at the top of the Clients List page. Simply enter the Client ID or Name, and the results will be filtered automatically.

Fig 3.1.1.a: Clients List
  1. Searching for Clients:

Each client in ZTrust includes the following details:

Client ID - A unique identifier used in URIs and tokens.

Name - A display name for the client, customizable based on your preference.

Type - The authentication protocol used by the client:

  • OpenID Connect (OIDC): Allows clients to verify the identity of end-users.

  • SAML: Facilitates cross-domain SSO using security assertions.

Description - A short explanation about the client to help identify its purpose.

Home URL - The default URL used by the authentication server when redirecting or linking back to the client.

  1. Importing a Client:

To import a client:

  1. Click Import Client.

  2. Choose a resource file (JSON or XML) by clicking Browse.

{
"clientId": "account",
"name": "${client_account}",
"rootUrl": "${authBaseUrl}",
"baseUrl": "/realms/test/account/",
"surrogateAuthRequired": false,
"enabled": true,
"alwaysDisplayInConsole": false,
"clientAuthenticatorType": "client-secret",
"redirectUris": [
"/realms/test/account/*"
],
"webOrigins": [],
"notBefore": 0,
"bearerOnly": false,
"consentRequired": false,
"standardFlowEnabled": true,
"implicitFlowEnabled": false,
"directAccessGrantsEnabled": false,
"serviceAccountsEnabled": false,
"publicClient": true,
"frontchannelLogout": false,
"protocol": "openid-connect",
"attributes": {
"realm_client": "false",
"post.logout.redirect.uris": "+"
},
"authenticationFlowBindingOverrides": {},
"fullScopeAllowed": false,
"nodeReRegistrationTimeout": 0,
"defaultClientScopes": [
"web-origins",
"acr",
"roles",
"profile",
"basic",
"email"
],
"optionalClientScopes": [
"address",
"phone",
"organization",
"offline_access",
"microprofile-jwt"
],
"access": {
"view": true,
"configure": true,
"manage": true
}
}
  1. Upload the file from your local machine or any accessible path.

  2. Fields Explanation

    1. Resource File (optional)

      • Allows you to import a client configuration from a JSON or XML file instead of entering details manually.

      • If provided, most fields will auto-fill.

    2. Client ID (required)

      • A unique identifier for the client within the realm.

      • Used by applications to request authentication from ZTrust.

      • Example: my-web-app, mobile-app, ztrust-dashboard.

    3. Name (optional but recommended)

      • A human-readable name for the client.

      • Helps administrators identify it easily in the console.

      • Example: ZTrust Dashboard or HR Management System.

    4. Description (optional)

      • A short explanation about the purpose of this client.

      • Example: "Client used for SSO authentication of the HR portal."

    5. Announcement (optional)

      • Can be used to add notes or special instructions about the client.

      • Example: "This client will be deprecated soon."

    6. Always Display in UI (toggle)

      • If enabled, this client will always appear in the ZTrust login selection screen.

      • Useful when there are many clients and you want to highlight specific ones.

    7. Type (optional)

      • Defines the application type or protocol type of the client.

      • Could be used internally to categorize clients (e.g., OIDC, SAML, Service, etc.).

Fig 3.1.1.b: Clients List, import client

Creating a New Client

To create a new client:

  • Navigate to Clients in the left menu.

  • Click on Create Client.

  • You’ll be redirected to the Create Client screen.

Fig 3.1.1.b: Client List, to create client

Client Type

Defines the protocol used for authentication and authorization. Options:

  • OpenID Connect (OIDC) → Used for identity verification and authentication via tokens.

  • SAML → Used for web-based authentication and cross-domain SSO using XML assertions. Choose based on your application’s needs.

Fig 3.1.1.c: Clients List, type of client

Client Authentication

This is a toggle button. When enabled (toggled ON), the OIDC type is set to confidential access.

When turned OFF, it is set to public access.

You can switch this ON or OFF based on your requirements.

Authorization

This toggle button, when enabled (toggled ON), activates fine-grained authorization support for a client. When turned OFF, this feature is disabled.

You can adjust this setting based on your specific requirements.

Fig 3.1.1.d: Client List, capability config

Authentication Flow

Fig 3.1.1.e: Client List, Authentication flow

You can choose the authentication flow by ticking the checkbox beside each of these options.

The table below displays the various types of flows along with a brief description for each.

Type of Flow
Description

Standard flow

This option activates standard OpenID Connect redirect-based authentication using an authorization code. Enabling this checkbox adds support for 'Authorization Code Flow' to this client.

Direct access grants

By selecting this checkbox, support for Direct Access Grants is enabled. This allows the client to access the user's username/password directly and exchange it with the ZTrust server for an access token.

Implicit flow

Selecting this checkbox enables support for OpenID Connect redirect-based authentication without requiring an authorization code.

Service accounts roles

Selecting this checkbox enables authentication for this client to ZTrust and retrieves an access token specifically dedicated to this client.

OAuth 2.0 Device Authorization Grant

Selecting this checkbox activates support for the OAuth 2.0 Device Authorization Grant. This indicates that the client is an application installed on a device with limited input capabilities or lacking a suitable browser.

OIDC CIBA Grant

Selecting this checkbox activates support for OIDC CIBA Grant, indicating that the user is authenticated through an external authentication device rather than the user's browser.

Next

Once you've entered the above details, click Next to proceed with creating the Client.

Back

To return to the previous settings screen, click Back.

Upon clicking Back, you will be redirected to the previous screen, which is the General Settings page.

Fig 3.1.1.f: Clients List, general settings of client

Cancel

If you wish to cancel the client creation and discard the changes, click on Cancel.

Clicking Next will redirect you to the following screen.

Login Settings

Root URL

Base URL used for relative paths in the client configuration.

Example:

  • If Root URL = https://example.com

  • And Valid Redirect URI = /dashboard

  • The final redirect URL becomes: https://example.com/dashboard.

Home URL

Default URL where the authorization server redirects after login.

Example:

  • If you want users to go directly to their dashboard after login, set Home URL to: https://example.com/dashboard.

Valid Redirect URIs

  • Add URLs where users can be redirected after successful login.

  • Click + Add valid redirect URIs to include multiple URIs.

  • Use - to remove unwanted URIs.

Examples:

  • https://example.com/dashboard

  • http://localhost:3000/* (Example : for development)

Valid Post Logout Redirect URIs

  • Define where users should be redirected after logout.

  • Similar add/remove controls as above.

  • Example:

    • Root URL = https://example.com

    • Valid Redirect URI = /auth/callback → Final URL = https://example.com/auth/callback

Web Origins

  • Used for CORS (Cross-Origin Resource Sharing).

  • Define allowed domains that can make API calls with tokens.

  • Example:

    • Valid Redirect URIs → https://example.com/*

    • Web Origins → https://example.com

    • Do not use "*" in production, because it allows any domain to access tokens("Use it in local environment")

Fig 3.1.1.g: Clients List, login settings

Capability Configuration

Client Authentication

  • ON → Client uses confidential access (requires credentials).

  • OFF → Client uses public access (no secret required).

Authorization

  • ON → Enables fine-grained authorization for the client.

  • OFF → Disables additional authorization checks.

Authentication Flow

  • Choose the required flow type (e.g., Direct Grant, Standard Login, etc.) by selecting from the list.

Click Next to proceed.

Fig 3.1.1.h: Clients List, capability config

Access Settings

Root URL

Base URL used for relative paths in the client configuration.

Home URL

Default URL where the authorization server redirects after login.

Valid Redirect URIs

  • Add URLs where users can be redirected after successful login.

  • Click + Add valid redirect URIs to include multiple URIs.

  • Use - to remove unwanted URIs.

Valid Post Logout Redirect URIs

  • Define where users should be redirected after logout.

  • Similar add/remove controls as above.

Web Origins

  • Used for CORS (Cross-Origin Resource Sharing).

  • Define allowed domains that can make API calls with tokens.

  • The domain URLs listed here are included in the access token sent to the client application. The client application utilizes this data to determine whether to permit a CORS request to be initiated.

    You can input any domain URL and click on the '+ Add web origins' symbol to add it.

  • Example:

    • Valid Redirect URIs → https://example.com/*

    • Web Origins → https://example.com

    • Do not use "*" in production, because it allows any domain to access tokens("Use it in local environment")

Fig 3.1.1.i: Access settings

Admin URL

This is the URL to the Admin interface of the client.

Fig 3.1.1.j: Clients List, cabability config

Capability Config

Client Authentication

This is a toggle button. When enabled (toggled ON), the OIDC type is set to confidential access.

When turned OFF, it is set to public access.

You can switch this ON or OFF based on your requirements.

Authorization

This toggle button, when enabled (toggled ON), activates fine-grained authorization support for a client. When turned OFF, this feature is disabled.

You can adjust this setting based on your specific requirements.

Authentication Flow

You can select the authentication flow by ticking the checkbox beside each of these options.

The table below displays the various types of flows along with a brief description for each.

Type of Flow
Description

Standard flow

This option activates standard OpenID Connect redirect-based authentication using an authorization code. Enabling this checkbox adds support for 'Authorization Code Flow' to this client.

Direct access grants

By selecting this checkbox, support for Direct Access Grants is enabled. This allows the client to access the user's username/password directly and exchange it with the ZTrust server for an access token.

Implicit flow

Selecting this checkbox enables support for OpenID Connect redirect-based authentication without requiring an authorization code.

Service accounts roles

Selecting this checkbox enables authentication for this client to ZTrust and retrieves an access token specifically dedicated to this client.

OAuth 2.0 Device Authorization Grant

Selecting this checkbox activates support for the OAuth 2.0 Device Authorization Grant. This indicates that the client is an application installed on a device with limited input capabilities or lacking a suitable browser.

OIDC CIBA Grant

Selecting this checkbox activates support for OIDC CIBA Grant, indicating that the user is authenticated through an external authentication device rather than the user's browser.

Login settings

Fig 3.1.1.k: Clients List, login settings

Login Theme

Fig 3.1.1.l: Clients List, login theme selection

The dropdown provides different theme options for the login page, including OTP Entry, New User Registration, and the Login screen for the specific client.

This toggle button determines whether users are required to consent to client access.

When enabled (turned ON), users must provide consent.

Conversely, when disabled (turned OFF), users are not required to give consent.

You can adjust this setting according to your preferences.

Display client on screen

This setting applies only if Consent required is enabled for this client. When deactivated (toggled OFF), the consent screen will only display consents corresponding to configured client scopes.

However, when activated (toggled ON), there will also be an additional item on the consent screen related to the client itself.

You can toggle this setting ON or OFF as per your requirements.

This pertains to the text that will be shown when this client scope is added to a client with consent required.

By default, it displays the name of the client scope if left empty.

Fig 3.1.1.m: Clients List, logout settings

Logout Settings

Front channel logout

This toggle button, when activated (turned ON), mandates a browser redirect to the client for logout. When deactivated (turned OFF), the server executes a background invocation for logout.

You can adjust these settings based on your needs.

Once enabled, two additional fields are also activated: Front-Channel Logout URL.

Front-channel logout URL

This field specifies the URL that prompts the client to log itself out when a logout request is sent to this realm via the end_session_endpoint.

If not provided, it defaults to the base URL.

This field is customizable, allowing you to modify it as needed.

Backchannel logout URL

This field specifies the URL that triggers the client to log out when a logout request is sent to the realm via the end_session_endpoint.

If omitted, no logout requests will be sent to the client in this scenario.

You can modify it according to your requirements.

Backchannel logout session required

It is a toggle button, when activated (turned ON), adds the Session ID claim to the Logout Token sent via the Backchannel Logout URL.

When deactivated (turned OFF), the SID isn't included.

You're free to customize this according to your needs.

Backchannel logout revoke offline sessions

This toggle button, when activated (turned ON), adds the revoke_offline_acccess event to the Logout Token sent via the Backchannel Logout URL. ZTrust will then revoke offline sessions upon receiving a Logout Token with this event.

When deactivated (turned OFF), this specific event isn't included in the Logout Token.

You can customize this setting according to your needs.

Save

If you're satisfied with the changes and want to implement them, click on Save.

Revert

If you've made changes that you don't wish to apply, click on Revert.

Fig 3.1.1.n: Clients List, jump to section

You can navigate between different setting screens using this section. Simply click on the settings type you wish to configure.

Fig 3.1.1.o: Clients List, client list

By clicking on the three dots next to a specific client, you will be presented with the following options: Export or Delete.

Fig 3.1.1.p: Client List, to export or delete client

Export

To download all settings and configurations related to a specific client, click on Export. This action will save all details and configurations in JSON format.

Delete

If you no longer need a specific client, click on Delete to remove it.

Upon clicking Delete, a confirmation prompt will appear as shown below.

Fig 3.1.1.q: Clients List, confirm to delete client

Click on Delete to remove it, or click on Cancel to keep it.

Last updated