Register applications
An application that wants to authenticate your users is a relying party, in OIDC terms. You register it on the provider's Applications tab with Add Application.
Registration does two things: it turns unknown software into a client your provider talks to, and it puts a name and logo on the consent screen where your users judge that software.
The important fields
| Field | Notes |
|---|---|
| Name and Origin / Publisher | How the application presents itself on the consent screen. Write them for your users, not for yourself: "Team wiki (wiki.example.com)" is better than "test-app-2". |
| Redirect URIs | Where the provider may send a user back after sign-in. Matched exactly. |
| Logo | Optional. Shown on the consent screen. |
Anyone who can receive the redirect can complete the sign-in. List the exact callback URLs your application uses and nothing wider.
Confidential or public
A client is confidential or public. That's not a switch; it follows from whether the client has a secret.
| Has a secret | Right for | |
|---|---|---|
| Confidential | Yes. Press Generate Client Secret. | A server-side application, which can keep the secret away from users. |
| Public | No. It uses PKCE instead. | A single-page or mobile application. Neither can keep a secret. |
Put it in your application's configuration right away; for a container, an environment file is the natural place.
Generating a new secret replaces the old one, which is also the fix for a leaked secret.
Advanced options
Everything else has a working default. The advanced options are for an application that asks for something specific: post-logout redirect URIs, CORS origins for a browser client, and the token signature and encryption algorithms.
Leave them alone until an application's documentation asks for them.
That's the per-application scope policy, in Scopes and consent. Connect your application covers the application's side once it's registered.