Streamlined OIDC client management

Creating an OpenID Connect client used to mean a form that was easy to mis-fill and a details view that did not show the issuer links you needed next. The security console workflow for OIDC clients is reworked: create, inspect, and update sit together, and dashboard onboarding points at the same setup.

This is the longer note behind the January 19 changelog entry.

How it works

Security > Clients (OIDC clients tab) is the control plane for environment clients. You create a client, set redirect URIs and the usual OIDC fields, and open details without leaving the environment.

The details view exposes the issuer-derived links for the current environment, including discovery and JWKS ({issuer}/.well-known/jwks.json), using identityFlowUri when the environment has a custom identity host.

Dashboard onboarding links into this workflow so a new environment is not left with "create a client" as tribal knowledge.

Client create, update, and delete still emit oidc.client_* events when those management actions run.

Set it up

In the console, open Security > Clients:

1. Create an OIDC client for the environment.
2. Set redirect URIs that match the app.
3. Copy discovery and JWKS from the client details, not from a remembered default host.

If you later attach a custom domain, re-open the client and confirm the issuer links follow identityFlowUri.

Trust boundaries

A client id is not a user session. Redirect URIs must be exact. Dashboard guidance does not issue tokens; it only routes you to the form.

Do not embed a client secret in a public CLI or SPA. Use the client type that matches the app.

Try it

Create a client, complete hosted sign-in with its client_id, and confirm the callback. The original release note is in the changelog.