Which single sign-on screen to use

Open the Identity menu and count the entries that look like they set up single sign-on. SSO Providers. SAML providers. Federated providers. Domain routing. OIDC clients. App catalog. Six, and none of their names says which one your Microsoft Entra tenant belongs in. If you have been clicking between them trying to work out the difference, you are not missing something obvious — the naming is genuinely bad, and one of those screens does not work at all.

This article is the map. It is blunt about the screen that does not work, because the alternative is you spending an afternoon configuring it correctly and then wondering why nobody can sign in.

The one question that sorts most of it

Every one of these screens is on one side or the other of a single question: who is being trusted to say who somebody is?

Inbound — somebody else vouches for your people

Your staff already have Microsoft or Google accounts. You want them to sign in to Qorionix with those, so that when somebody is disabled at Microsoft they are disabled here too. Qorionix is the service provider, the party doing the trusting.

Outbound — you vouch for your people

Your staff have Qorionix accounts, and you want them to sign in to some other product with those. Qorionix is the identity provider, the party being trusted. Covered in Registering an application for sign-in and Setting up single sign-on from the catalogue.

Most people arriving at this article want the inbound half. Here is the whole set, in one table, with the column that usually gets left out of documentation like this.

SSO Providers: the screen to leave alone

This is the one we owe you a straight answer about. Identity → SSO Providers presents a competent-looking form. It asks for the protocol, then the right fields for that protocol — entity ID, sign-on URL and an X.509 certificate for SAML; issuer URL, client ID and client secret for OIDC — plus an optional list of allowed email domains. It validates them. It saves them. You can configure the record afterwards, disable it, delete it.

And then nothing happens, because no sign-in path reads those records.

If you have already put a provider here, nothing bad is happening — the records are inert, not dangerous. Recreate the provider on Federated providers or SAML providers, confirm a real sign-in works, then delete the record here so the next administrator does not have to work out which of the two is live.

Federated providers: start here

Described on the page as Let your people sign in with the accounts they already have — Entra ID, Google Workspace, Okta, or an on-premises AD FS. This is the screen with the complete sign-in path behind it: a start, a callback, and the WS-Fed variant Microsoft needs for AD FS.

Three things about it are worth knowing before you start.

• It asks which provider first, and then only shows the fields that provider needs. The catalogue behind that first question carries operational notes written for each provider, and they are shown as written rather than summarised — that GitHub is an OAuth2 provider rather than a workforce identity system, that Apple's client secret is a signed token that expires rather than a fixed string, and so on. Read them; they are the traps people otherwise meet in production.
• The account-linking choices are spelled out beside the switches, not hidden in tooltips. They are the difference between our staff can sign in and anybody who can make this provider assert an email address owns an account here. Choosing to link by email address forces on the requirement that the address be verified, because the other combination is not a configuration, it is a vulnerability.
• One redirect URI covers every provider on the platform. The screen shows it under Configure this in your identity provider, with the warning that it has to match character for character, or the provider will refuse the sign-in before Qorionix ever sees it. That is the single most common cause of a federation that fails immediately.

Providers here can be edited and their client secret replaced without recreating them. Removing one is properly destructive and says so: Remove "{name}"? This also removes its email-domain routing rules and every account link made through it. Anyone who signs in this way loses that route immediately, and will need another way in.

SAML providers: for anything that speaks SAML and is not in that list

This screen registers an external SAML 2.0 identity provider and is the one behind the real inbound SAML sign-in path. Its first question is where to get the configuration from, and the answer is nearly always a URL:

Paste your identity provider's metadata URL

The usual path. We fetch the document and read the entity ID, sign-on URL and signing certificate out of it, so there is nothing to type. Choose this unless you cannot.

Upload or paste the metadata XML

For an identity provider on a private network, or an air-gapped environment where we cannot reach the URL ourselves. Nothing is fetched over the network in this mode.

Enter the details by hand

The escape hatch. Only needed if your identity provider publishes no metadata document at all. Typing an entity ID and pasting a certificate is the most error-prone way to establish a trust and the least necessary one.

Whichever you pick, the wizard shows you what it read before it saves anything, under the heading This is what you are about to trust: Assertions from this entity ID, signed by this certificate, will become sign-ins in this tenant. Confirm it is the right identity provider before you continue. That confirmation step is the whole point of the screen. An entity ID and a certificate are the two values that decide whose word becomes a login here.

It finishes on two values you have to paste back into your identity provider — the service provider entity ID (the Audience) and the assertion consumer service URL (the ACS or Reply URL) — under the heading Now finish the trust in your identity provider, with the warning that until you do, every sign-in through it will be rejected.

Domain routing: the piece that makes the sign-in page work

A provider on its own does not put a button on the sign-in page. Domain routing is what connects an email domain to a provider: somebody types [email protected] at the prompt, and the platform sends them to whoever owns contoso.com rather than asking for a password it should not be holding. The identifier-first sign-in flow explains what the person sees.

Ownership of a domain is proven, not asserted — you publish a DNS TXT record containing a token issued for your claim, and an unproven claim routes nothing. That is enforced on the server, not by the screen. The screen also distinguishes not verified from we could not check, because a DNS timeout displayed as you do not own this domain would be a lie told on the backend's behalf. Federated domains and domain verification covers it properly.

The outbound screens, briefly

If what you actually want is your people signing in to another product with their Qorionix account, none of the above applies. Three surfaces do that job, and two of them are the same records seen twice.

• OIDC clients — registers a relying party and issues its client ID and secret. Templates for known applications pre-fill the redirect URIs. This is where credentials are minted.
• App catalog — the same underlying registrations, plus the one thing OIDC clients cannot do: edit an existing one. Correcting a mistyped redirect URI anywhere else means deleting and recreating, which changes the client ID and forces a reconfiguration at the far end. It is also the launcher your ordinary staff see.
• Integrations → the Set up button — the template-driven path for the twenty-one applications that ship with one. This is the only way to set up outbound SAML, and it is the shortest route for anything on the list.

Deciding in thirty seconds

1. 1

   Do your people sign in to Qorionix, or out of it?

   Into Qorionix with an existing account: inbound, keep reading. Out of Qorionix into something else: go to OIDC clients, or Integrations if the application is one of the twenty-one with a template.

2. 2

   Inbound: is your provider Entra ID, Google Workspace, Okta, AD FS or a social login?

   Then Federated providers. It has a guided flow, per-provider warnings, an edit form and a secret-rotation path, and it is the one with the most complete sign-in handling behind it.

3. 3

   Inbound, something else that publishes SAML metadata?

   Then SAML providers. Paste the metadata URL, confirm what it read, and paste the two values back into your identity provider.

4. 4

   Either way, add the email domain under Domain routing and prove it

   Without a proven domain claim, the provider exists but the sign-in page has no reason to send anybody to it.

5. 5

   Test with a second account before you tell anybody

   Use a private window and an account that is not yours, and keep one local administrator account that does not depend on the federation. A misconfigured trust that locks out the person who configured it is the expensive version of this mistake.

What to do next

1. Pick the screen from the table above, and if you already have records on SSO Providers, plan to move them.
2. Set the provider up: Single sign-on with SAML for a metadata-based trust, Single sign-on with OIDC for Entra ID, Google Workspace or Okta.
3. Claim and prove the email domain, or the sign-in page has nothing to route: Federated domains and domain verification.
4. Read what your people will see, so you can tell them: The identifier-first sign-in flow.
5. If a sign-in then fails, the error usually names the layer — SAML sign-in fails and OIDC sign-in fails are written around the specific messages.