Connecting an Application
Each application that may sign users in is registered as a client with its own identifier, credentials and rules.
Where to find it
Architect Panel → Integration & Connections:
- OpenID Connect Provider — the console — clients, scopes, keys and the log
Architect Panel → Security:
- Permissions — groups, which a client can be restricted to
What a client holds
- An identifier and, where appropriate, a secret with its own creation and expiry dates.
- Name, description, logo and links to its site, privacy policy and terms — all shown on the consent screen.
- A type, distinguishing an application that can keep a secret from one that cannot.
- Redirect URIs, post-logout redirects and allowed origins.
- Four grant type switches.
- PKCE required, and a trusted flag.
- Allowed and default scopes.
- Token lifetimes, and optionally allowed groups.
Confidential or public
A server-side application can keep a secret. A single-page application or a mobile app cannot — whatever you give it ships to the user's device and can be extracted.
Set the type honestly. Treating a public client as confidential does not make its secret secret; it just means you believe something untrue about your own security.
Redirect URIs are a security control
They are the exact addresses you will send a user back to after signing in, and they are matched exactly.
This is what stops an attacker starting a sign-in and having the result delivered to them. Never add a wildcard, never add a host you do not control, and remove development addresses before the client goes live — a local address left registered on a production client is a real hole.
The four grant types
- Authorisation code — the normal one. A person signs in and is redirected back. Use this.
- Refresh — lets a client keep a session alive without asking again. Convenient, and it extends how long access survives.
- Client credentials — no user at all; the application acts as itself. Only for machine-to-machine, and note it is not really identity — nobody is being signed in.
- Device — for things with no browser, where a code is entered elsewhere.
Enable only what the application uses. Each is a route to a token, and one nobody needs is surface area for nothing.
Require PKCE
It closes a class of attack where an intercepted authorisation code is exchanged by somebody else. It is mandatory for public clients and harmless for confidential ones.
Turn it on for everything. Modern libraries support it, and an integrator who objects is telling you something about how current their library is.
The trusted flag skips consent
Reasonable for your own first-party applications, where asking a member to consent to sharing their profile with your own portal is noise.
Never set it on a third party's application. The consent screen is the user's only visibility into what is being shared, and removing it on somebody else's behalf is a decision that is not yours to take.
Restrict by group where it fits
A client can be limited to members of particular groups, so signing in succeeds only for people who should use that application. That is cleaner than letting everybody authenticate and having the application decide.
Secrets expire
They carry creation and expiry dates. Diary the renewal — an expired secret breaks the integration completely, on a date you knew in advance.
Worked example
An events site is registered as a confidential client with one exact redirect URI, authorisation code and refresh grants only, PKCE required, not trusted, restricted to the Members group, and a secret expiring in a year with a calendar reminder at ten months.
Recommendations
- Exact redirect URIs only, and remove development ones before go-live.
- Require PKCE everywhere.
- Never mark a third party trusted.
- Diary every secret expiry.