Edit Client Applications

The React AdminApp groups client settings by the task you are performing. Field and tab changes stay in the page draft until Save. Child collection and authentication-dialog commands save separately and immediately.

Tab	Configuration
General	Application name, enabled state, immutable client ID and subscription, application and logo links.
Security	Public/confidential and native client settings, allowed response types, user login, client credentials and device authorization; security profile and PAR; JAR and registered request URLs; token formats and encryption; public/pairwise subject identifiers.
Credentials	Client authentication method and sender constraints, shared secrets, and key sets for client assertions, request signing, certificate matching or token encryption.
Redirects	Login and post-logout callback allowlists, front-channel and back-channel logout endpoints, session requirements and logout consent.
Permissions	Restricted user/group access, resource and scope filtering, access consent, roles and group claims, and token-exchange source clients.
Relationships	Identity and MFA providers, tenant access and cross-subscription use, and federated client identities.
Metadata	Application-specific key/value metadata.

Common configuration workflows

Confidential web application: enable user login, keep Public off, configure authentication in Credentials, and register login callbacks in Redirects. Client credentials is a separate machine-to-machine grant; enable it only when required. Public browser/native clients cannot protect shared credentials. Device authorization requires client opt-in, user login and tenant support.

Native applications and response types: in Security, enable Is Native Application for an installed application that needs HTTP loopback redirects with a variable port. Register an IP-literal callback such as http://127.0.0.1/callback; Public alone does not enable this behavior. Allowed Response Types defaults to code. Register any required implicit or hybrid response types explicitly; see client security upgrade guidance before changing existing applications.

FAPI 2.0: select the profile in Security and configure private_key_jwt or mutual TLS authentication in Credentials. Configure DPoP or certificate-bound tokens there as well. The client must use PAR, authorization code flow and S256 PKCE. The profile does not create keys or configure the relying party. Mandatory tenant FAPI enforcement takes precedence even when the client selects None. See FAPI requirements.

Sender constraints: DPoP requires a proof on token requests and protected resource requests. Certificate binding requires the client certificate and resource-server validation of that binding. Encryption is separate: it protects token contents and does not establish proof of possession. See DPoP and mutual TLS.

Authentication configuration: open Credentials and use Configure authentication if no record exists, or edit the existing record. The dialog saves independently of the parent form. TLS subject/SAN values apply only to tls_client_auth; clear existing values before changing to another method. Optional certificate binding inherits the method default (enabled for mutual TLS). DPoP and nonce requirements have explicit inherited/enabled/disabled choices. A nonce requirement can also apply to optional DPoP proofs. After initial creation, Configure authentication can remain enabled until the page is reloaded; duplicate creation is rejected before another record is submitted.

Encrypted responses: configure alg and enc together for ID tokens or UserInfo, and register a compatible key set with TokenEncryption usage in Credentials. Clear both values to disable that response's encryption. Introspection defaults an omitted enc to A128CBC-HS256 when alg is configured. Reference access tokens ignore the JWT encryption override, so the override is disabled while Reference is selected; its stored value is retained. See token encryption.

Restricted access: enable Restrict user access in Permissions, then select allowed users or groups. Existing selections remain visible but cannot be edited while restriction is off. Resource and scope filters sit beside their lists: review those lists before enabling enforcement. These flags do not replace other authorization checks.

Privacy: pairwise subjects isolate user identifiers by sector. Changing a live client's subject type or sector can break account linking. The sector URL is enabled for pairwise subjects; an existing value remains editable so it can be cleared. See pairwise subject identifiers.

Logout: post-logout redirect allowlists control browser return locations. Front-channel iframe URLs and back-channel HTTPS POST endpoints notify the application of logout. Set the corresponding session requirement only if the application needs iss/sid or a logout-token sid. An already enabled requirement remains editable if its URL is removed so the setting can be cleared.

Dynamic login redirect URI

If your application uses subdomains or URL paths to identify the tenant, you can set placeholders in the login redirect URI. In this case, the login request parameter acr_values with the tenant property can be omitted.

The following placeholders are supported:

• tenantkey

  This setting is defined in the Tenant entity

• tenantid

  This is the primary key of the Tenant entity

INFO

The redirect URI and the placeholders must be lowercase.

Samples:

• https://.myapp.com
• https://www.myapp.com/
• https://www.myapp.com/