Troubleshooting SSO

Two different failures, two different causes

A failed sign-in shows up in one of two places, and which one tells you where to look.

• A Microsoft error page, with an AADSTS code, means Entra rejected the request before or during authentication itself — the client ID, redirect URI, tenant, or the user not being assigned to the app.
• Intric’s own “login failed” page means Entra accepted the sign-in and handed back a code, but the server-side exchange of that code for a token failed. That points at the client secret (wrong or expired), the app being registered under the wrong platform type, or a claims-mapping policy on the app.

So if the Entra admin center “looks right” and the failure happens on Intric’s own page rather than a Microsoft one, suspect the secret first.

In the table below, 50011, 700016, 90072, 65001, 90094 and 50105 appear on a Microsoft page. The others appear only in the sign-in logs, on the non-interactive tab — the user just sees Intric’s “login failed” page.

AADSTS error reference

Code	Cause	Fix
AADSTS50011	The redirect URI in the request doesn’t match any configured on the app.	Confirm the app has exactly https://login.intric.ai/idps/callback under Web redirect URIs.
AADSTS700016	The application isn’t found in this tenant — wrong client ID, or the request went to the wrong tenant.	Check the client ID and the tenant/directory ID we were given match the app registration.
AADSTS90072	The account signing in doesn’t belong to the tenant the app lives in.	First retry in a private window — the browser is often already signed in to another tenant or a personal Microsoft account. If it persists, check that the Directory (tenant) ID you sent us is the tenant your users actually belong to. If it is, and only some accounts are affected, they’re external accounts — add them as guests in the tenant.
AADSTS65001 / AADSTS90094	Consent hasn’t been granted, and users aren’t allowed to consent themselves.	Grant admin consent under Entra ID → App registrations → your app → API permissions.
AADSTS50105	The user isn’t assigned to the application.	Assign the user, or a group they belong to, under Entra ID → Enterprise apps → your app → Users and groups.
AADSTS7000215	The client secret sent is invalid.	Check the secret value was copied correctly — it’s easy to paste the Secret ID by mistake.
AADSTS7000222	The client secret has expired.	Create a new secret and send us the value — see the rotation steps below.
AADSTS9002327	The app is registered under Single-page application, which issues SPA-only tokens that can’t be redeemed by a server-side exchange.	Remove the SPA platform entry and add the redirect URI under Web instead.
AADSTS50146	Microsoft’s own name for this is MissingCustomSigningKey — the app needs an app-specific token-signing key. In practice this is most often caused by a claims-mapping policy assigned to the app.	Remove the claims-mapping policy (see below). If you need to keep it, contact us before changing anything else on the app.
AADSTS54005	An authorization code was already used.	Usually a symptom, not the cause. Something else failed after Entra accepted the code, and a retry then found the code already spent. The real error is in the non-interactive sign-in log for the same attempt — see below.

Note

A claims-mapping policy isn’t shown on the app’s pages in the Entra admin center. Check for one with Microsoft Graph: GET /servicePrincipals(appId='<client-id>')/claimsMappingPolicies. An empty result means there isn’t one.

Where to look: sign-in logs

In the Entra admin center, go to Entra ID → Monitoring & health → Sign-in logs, and filter by the application. Check both tabs:

• Interactive sign-ins — the user’s browser redirect and authentication.
• User sign-ins (non-interactive) — this is where the server-side code-for-token exchange shows up, and it usually carries the real error when the Interactive tab looks like a success.

Making a clean test attempt

Don’t reload the callback page or retry repeatedly — that produces AADSTS54005 noise on top of whatever the original problem was. Instead, make one attempt in a private/incognito browser window, note the time, and send us: the time, the user’s email address, and the exact URL or error text shown.

“Signs in, but has no access”

This is almost always a groups problem, not an authentication one:

• The groups claim was empty or missing on that login — see a missing groups claim removes all memberships.
• The user is a member through a nested group rather than directly, or is assigned to the app individually rather than through a group — see nested groups aren’t included.
• The user belongs to more than 200 groups, triggering Entra’s overage behavior.
• The group identifier format changed (names vs. object IDs) — see group identifiers cannot be changed.

“Account not found” or no email on sign-in

The user’s mail attribute is empty in Entra ID. Intric links accounts by email, taken from mail, not the UPN — see Entra ID setup.

Upkeep

• Rotating the client secret. Create the new secret in Entra before the old one expires, send us the value, wait for us to confirm the swap, then delete the old secret.
• Adding a new group. Assign it to the enterprise application, then send us the group’s name and object ID.
• Renaming a group. Safe on its own — Intric matches on the object ID, which doesn’t change when a group is renamed.
• Changing your Intric URL. Tell us in advance. Several things need updating on our side before the new URL works for sign-in.