Clients
Clients represent applications in the Curity Identity Server. A client contains all the configuration for an application to obtain an authorization grant on behalf of a user or non-human entity.
In the Curity Identity Server, clients are extremely flexible and can be configured for many different purposes, including:
- performing the OAuth authorization code flow (and all other OAuth flows)
- performing backend authentication via CIBA
- introspecting tokens
- exchanging tokens
- running authentication flows using the Hypermedia Authentication API (HAAPI)
Client Capabilities#
Clients in the Curity Identity Server support a wide range of capabilities that control what operations they can perform. These capabilities determine which OAuth flows and operations are available to each client.
To understand the full scope of what a client can do and how to configure these capabilities, see Client Capabilities
Client Authentication#
Before a client can interact with the Curity Identity Server, it may need to authenticate itself. Multiple authentication methods are supported, from simple secrets to advanced methods like private key JWT and mutual TLS.
Learn more about configuring these authentication mechanisms in Client Authentication
Client Configuration#
Beyond capabilities and authentication, clients have numerous configuration options that control their behavior, including redirect URIs, token lifetimes, and consent settings.
For a comprehensive reference to all available configuration options, see Client Configuration .
Client Types#
Depending on your deployment needs, the Curity Identity Server supports different client storage and management approaches:
- Configuration Clients — Clients defined directly in the system configuration, ideal for controlled environments.
- Database Clients — Clients stored in a database, suitable for dynamic client management.
- Dynamically Registered Clients (DCR) — Clients registered at runtime via the Dynamic Client Registration protocol.
Regardless of the type, all clients share the same configuration options and capabilities with only small discrepancies.
Client Framability#
To integrate the OAuth token issuance process, the Token Service offers specific capabilities to allow its user screens to be embedded through IFRAMEs.
While the default behaviour of HTML-pages is to not be allowed to be framed (due to security reasons, i.e. clickjacking prevention), it is however possible to allow framing on a per-client base.
The configuration and use of framability controls for OAuth clients is the same as for Service Providers . Please see the Service Providers’ Framability documentation for further instructions.