Registering an application, and the two screens that do it
App catalog and OIDC clients write to the same list. Which to use, the choice you cannot undo, the redirect rules, and the secret you get exactly once.
You have a product — an intranet, a finance portal, a Grafana, something somebody in the business built — and you want people to sign in to it with their Qorionix account instead of yet another password. Under Identity there are two menu entries that look like they do this: App catalog and OIDC clients. Neither name tells you which one to open.
Here is the fact that makes the rest of this easy: they are the same list. Both screens read and write the same registrations. An entry in the app catalogue is an OIDC client row; the catalogue's launcher view is a query over exactly that table. You are not choosing between two features. You are choosing between two ways into one, and one of them can do a thing the other cannot.
If you are not yet sure that registering an application is what you want at all — as opposed to letting your people sign in to Qorionix with their existing Microsoft accounts, which is the opposite direction — read Which single sign-on screen to use first. It is five minutes and it will save you setting up the wrong half.
Which of the two to open, and why it matters once
| Identity → OIDC clients | Identity → App catalog | |
|---|---|---|
| Shape | A step-by-step wizard. Optionally starts from an application template that fills in the redirect URI and scopes for you. | A list with a single form. Everything on one screen, advanced settings folded away. |
| Editing an existing registration | Not offered. Delete and register again. | Yes. The only place an existing registration can be corrected. |
| Issuing a replacement secret | Immediate, with no confirmation prompt. | Confirms first, naming the application and the consequence. |
| Showing a new secret | Requires you to tick an acknowledgement before the dialog will close. | A plain Close button. One click and it is gone. |
| For people who are not administrators | Nothing — the page is administrative. | Falls back to a launcher of the applications assigned to them. |
Use App catalog. It is the screen with the edit form, its secret dialog is harder to dismiss by accident, and it confirms before it invalidates a working secret. Use OIDC clients when the application you are registering has a template — the wizard fills in the redirect URI and the scopes from it, and a redirect URI you did not type is a redirect URI you cannot mistype.
Confidential or public, and why you only get to choose once
The first real question the form asks is the application type, and it is the only answer on the form that cannot be changed afterwards. The two options are described on screen rather than left to you to infer:
- Confidential — a server that can keep a secret
- The application runs on hardware you control and can hold a credential nobody else can read. Qorionix issues it a client secret. This is what an intranet, a web application or a back-office tool is.
- Public — mobile, single-page or CLI, cannot keep a secret
- The application's code is on somebody's phone or in their browser, so any secret you gave it would be readable by anyone who bothered to look. No secret is issued. Instead the application proves itself per sign-in with PKCE, a one-time value it generates and then has to reproduce — which is a stronger protection here than a shared secret would be, because there is nothing durable to steal.
The form's own guidance is the right rule: Choose Confidential for anything running on a server that can keep a secret. Choose Public for a mobile app, a single-page app or a CLI — those get no secret and use PKCE instead. If you are unsure and the thing runs on a server you administer, choose confidential.
One combination is refused outright rather than saved and left to fail later. A public client asking for the client_credentials grant — the mode where the application acts as itself with no person involved — is rejected, because a public client has no secret to authenticate with on the token endpoint and accepting it would hand tokens to anyone who asked.
Redirect URIs, and the four ways one gets refused
A redirect URI is the address Qorionix sends the person back to, carrying the result of their sign-in. It is the single most security-sensitive field on the form, because whoever controls that address receives the authorisation code. The rules are enforced on the server, so pasting past the console will not help.
| Refused | Why |
|---|---|
Anything containing * | A wildcard redirect is an open redirector, and an open redirector on this field is a code-interception vulnerability. The console says so plainly: anyone could then choose where the sign-in code is sent. |
Plain http:// to anything but a loopback address | Authorisation codes are only delivered over HTTPS. localhost, 127.0.0.1 and [::1] are the exception, because native and local development flows need them — and using one produces a warning telling you to switch to HTTPS for anything reachable off that machine. |
A URI containing a # fragment | The specification forbids it, and a fragment is not sent to the server anyway. |
| A custom scheme without a dot in it | A native app receives its redirect on a private-use scheme, and the specification asks for a reverse-DNS name. com.example.app:/callback is accepted; myapp:/callback is not, and neither is anything more creative. |
Beyond those, the field is unforgiving in the ordinary way: Must match exactly what the application asks for, character for character. A trailing slash, http where the application sends https, a port number present on one side and absent on the other — each of those is a sign-in that fails at the last step with an error from us that reads like a configuration problem, because it is one.
Scopes and grants, where the defaults are the answer
Scopes are what the application may ask about the person signing in. The default set — openid profile email — is enough to sign somebody in and learn their name and address, and it is the right answer for almost every application. Grant types are how the application collects its tokens; the default pair, authorisation code plus refresh token, is a normal web sign-in.
One scope is special enough that removing it is corrected rather than obeyed. Take openid out of an interactive sign-in and the platform puts it back, and tells you why:
The "openid" scope was added automatically. Without it no ID token is issued and the application cannot learn who signed in.
Without that scope you have plain OAuth 2.0 — an authorisation without an identity — which is essentially never what somebody configuring single sign-on meant. Adding it back is safer than refusing the registration, and saying so is safer than doing it quietly.
Two grant types you may have used elsewhere are missing from the list on purpose. The implicit flow and the password grant are both removed in the current version of the standard, and neither is offered here — not as a deprecated option, not behind an advanced toggle. If an application's documentation asks for one, its documentation is old; ask its vendor for the authorisation-code equivalent.
The secret, shown once, and what to do when it is gone
This secret is shown once and cannot be retrieved again. Store it now; if it is lost, issue a new one.
That is literal. The value is not stored in a form we can read back; only a hash of it is kept, which is what lets us verify the application without being able to disclose the secret to anybody — including to you, and including to us. Alongside it the dialog offers the endpoints for the application, with the note that most will accept the discovery URL alone. If the application asks for a discovery or .well-known URL, give it that one value and let it fetch the rest.
If the secret is lost, the fix is New secret, and it is genuinely disruptive rather than merely inconvenient. The confirmation says what happens: Issue a new secret for “{name}”? The current one stops working immediately and the application will not sign anybody in until the new secret is installed. There is no overlap period in which both work. Do it when you are in a position to paste the new value into the application within the next minute, not when you are investigating.
Changing a registration, and what is recorded when you do
Editing runs the same validation as registering, deliberately: a redirect URI that could not be added at registration must not become reachable by editing one that could. The application type is carried through untouched, so an edit cannot quietly turn a confidential client public.
Application is active is the switch to reach for before Delete. Switching it off blocks sign-in and leaves the registration, its client ID and its secret intact, so turning it back on restores service without anybody reconfiguring anything. Deleting is the version with no way back: Delete “{name}”? Its client id stops working at once and everybody using it loses access.
Every one of these actions is written to the audit log with the detail that matters rather than a bare it was edited. An edit records the redirect URIs before and after, because adding one is precisely how a registered application starts delivering sign-in codes somewhere new — and that is the change an investigator will want to see, months later, attributed to a person.
What registering an application does not do
- It does not give anybody access. A new registration is assigned to nobody, and assignment is a separate screen. See App assignments.
- It does not do SAML. Both screens here are OpenID Connect only. If the other product speaks SAML, the route is the Set up button in the integration catalogue — see Setting up single sign-on from the catalogue.
- It does not configure the other product. Half the work is in somebody else's admin console, and nothing here can tell whether you have done it.
- It does not test anything. There is no verify this works action. The only test is signing in.
What to do next
- Register the application from Identity → App catalog, choosing the type carefully, and copy the secret into your password manager before closing the dialog.
- Paste the client ID, the secret and the discovery URL into the other product, and make its redirect URI match yours character for character.
- Assign it to the people who should have it — App assignments.
- Sign in from a private window as somebody who is not you, then tell people it exists.
- If the sign-in fails, Single sign-on with OIDC covers what each stage of the exchange is doing and where it breaks.