Clients: console walkthrough¶
The same operations as the step-by-step guide, done in the console.
This console page has a guided tour
Click Start the tour beside the create button for a walkthrough that highlights each field as you go.
List¶
In the IAM perspective, Clients lists the applications registered against the selected project's domain.
Create¶
Create Client opens a guided form.
- Client ID - the identifier your application sends when it asks for a sign-in, so it has to match what the application is configured with, exactly. It cannot be changed.
- Public client - tick it for anything running in a browser or on a phone; leave it clear for anything running on a server you control.
- Standard flow - leave enabled. That is the authorization code flow.
- Redirect URIs - every URL the domain may return a user to.
- Web origins - for a browser application, the origin it is served from.
Realm appears above the client ID only when the project has more than one domain.
Redirect URIs are a security control, not configuration
The domain returns a signed-in user only to a URL matching this list, which is what stops an attacker redirecting a successful sign-in somewhere of their own. List the exact URLs, and avoid a trailing wildcard unless you genuinely need one.
If you cannot tell whether the client is public
Ask where the code that would hold the secret runs. If a user could open developer tools and read it, the client is public.
Change¶
The console form creates clients; it does not edit them. Redirect URIs and web origins are
changed with oc - see Change - and that is the field you will come
back to whenever the application moves or gains an environment.
The client ID, the realm and the public flag are fixed. Moving an application from public to confidential means registering a new client.
Delete¶
Use the kebab menu at the end of the row.
The application stops being able to authenticate anyone immediately. Users are unaffected.
Where the console differs from the CLI¶
| Console | oc |
|
|---|---|---|
| Realm reference | Filled in when there is one domain | You write spec.realmRef.name |
| Standard flow | On by default | You set standardFlowEnabled |
| Secret | Written into the project either way | Same |
| Editing | Not offered | Redirect URIs and web origins |
Verify¶
A client that reports OK can still fail at the first real sign-in, because the list
cannot tell whether the redirect URIs match what the application actually sends. Sign in
through the application once, end to end.
- "invalid redirect uri" - the URL the application sent is not in the list. Add exactly the URL the error names.
- "invalid client credentials" on a confidential client - the application has the wrong secret. Read it from the project again.