SSO Sign-In Errors
Understanding Indee SSO Error Reporting
When an SSO sign-in fails, Indee reports it by email. There are two kinds of emails — a detailed diagnostic sent to the enterprise designated SSO contact, and a brief note sent to the user who was denied access. Which one goes out depends on the error.
-
A brief email to the end user, with a one-sentence body and no technical detail. This is sent only when the person was authenticated successfully with your identity provider but has no Indee account or pending invitation. Every other failure is reported to your SSO contact. Nothing is sent to the user when authentication fails. The user sees only a message on screen.
-
A detailed diagnostic email to your designated SSO contact: when the enterprise is onboarded for SSO authentication, we request an SSO contact. This contact is sent an email containing a short error label, a technical description of what went wrong, the email address that attempted to sign in, and the time of the event. Depending on the failure, the description is either your identity provider's own response passed through untouched, or Indee's explanation of what it could not do; each section below tells you which to expect. Each section covers one error, what causes it, what your user sees on screen at that moment, and how to resolve it.
1. User does not exist
Error line reads: User does not exist
Error Description reads: User with email <email> does not exist in Indee. Please reach out to support@indee.tv
What went wrong: Your identity provider authenticated this person perfectly well but the email address has no Indee user account, and no pending Indee invitation. This means somebody was given your Indee sign-in link before they were added to Indee, or was added to your IdP group for Indee without a matching Indee invite.
What your user sees: They are taken to your IdP, sign in there successfully, are redirected back to Indee — and then get refused. The message on screen is:
Account Not Found
We couldn't find an Indee account for this email. Please contact your organization administrator to request access.
User also receives an email where the body reads: "You are not authorized to sign in. Please contact your organization administrator for further details.". This is the only failure that emails the user as well as your SSO contact.
How to resolve it: Invite the user in Indee, from your Indee admin console, using the same email address shown in the Username line of the email. Once the invitation is active they can retry immediately.
2. Your identity provider refused the sign-in
Error line reads: whatever code your IdP sent us — commonly access_denied, invalid_request,
unauthorized_client, invalid_scope, consent_required, login_required.
Error Description reads: your IdP's own explanation, passed through untouched.
What went wrong: Nothing failed on the Indee side. Your IdP received the sign-in request, decided not to allow it, and returned a reason. The usual causes, roughly in order of how often we see them:
- The user isn't assigned to the Indee application in your IdP, or isn't in the group that is.
- The user canceled or dismissed the consent / MFA prompt.
- A conditional-access or device-compliance policy blocked them (unmanaged device, blocked country, IP outside an allowed range).
- The Indee app registration in your IdP has been disabled, expired, or had its redirect URI or requested scopes changed.
What your user sees:
Unable to Sign In
Unable to login. Contact your administrator for details.
How to resolve it: Read the Error Description first — it names the cause precisely. If it points at assignment or group membership, add the user to the Indee app in your IdP. If it points at a policy, either bring the user into compliance or scope the policy to exclude the Indee app. If it points at the app registration or the redirect URI, contact support@indee.tv before changing anything on your side, so we can confirm what Indee is currently configured to send. If the description says the user simply canceled, ask them to retry and complete the prompt.
3. Authentication denied due to mismatch in email address
Error line reads: Authentication denied due to mismatch in email address
Error Description reads: Authentication denied as the user's authentication email <typed> does not
match SSO provider's account details email <returned by IdP>
What went wrong: The user typed one address on the Indee sign-in page, and your IdP came back asserting a different one. Indee refuses this on purpose — allowing it would let anyone sign in as anyone else in your organization. The two addresses in the description tell you exactly what diverged. In practice this is nearly always one of:
- The user typed an alias, a distribution address, or an old domain, while your IdP asserts their primary address.
- Their primary address changed in your IdP (name change, domain migration) and they're still typing the old one.
- Your IdP is configured to send a claim other than the primary email — a UPN, a username, or a
subvalue — in the field Indee reads as the email.
What your user sees:
Unable to Verify Email
The email entered doesn't match the one you signed in with. Try again with the correct email.
How to resolve it: Tell the user to sign in with the exact address your IdP asserts — that's the one Indee will accept.
4. Call to authorization_endpoint failed
Error line reads: Call to authorization_endpoint failed
Error Description reads: a technical message explaining why the response couldn't be parsed. There's no fixed wording — it comes from the OpenID Connect exchange itself, not from a message Indee writes.
What went wrong: Your IdP redirected the user back to Indee, but the response couldn't be read as a valid OpenID Connect authorization response. Typical causes: the redirect was truncated or altered in transit (a proxy, a URL shortener, an email-security link rewriter), the user's session took so long that the response expired, or the user opened a stale or bookmarked sign-in link and completed it much later.
What your user sees:
Unable to Sign In
Unable to login. Contact your administrator for details.
How to resolve it: Ask the user to retry from a fresh sign-in — start at the Indee sign-in page rather than a bookmarked or emailed link, in a normal (non-incognito) window, and complete it without pausing. This clears the great majority of these. If the same user hits it repeatedly, check whether anything between them and your IdP rewrites URLs, and send us the email so we can confirm what arrived.
5. Call to token_endpoint failed
Error line reads: Call to token_endpoint failed
Error Description reads: the rejection your IdP returned to the token request, usually quoting its
own error body — invalid_client for a bad or expired secret, invalid_grant for a used or expired
code, redirect_uri_mismatch for a registration mismatch. Wording varies by IdP.
What went wrong: The user authenticated, your IdP issued a one-time code, and Indee's attempt to exchange that code for an access token was rejected. This is almost always a credential or configuration problem rather than anything the user did:
- The client secret for the Indee app in your IdP has expired or been rotated. This is the single most common cause, and its signature is that every user starts failing at once. If you're receiving a burst of these, start here.
- The redirect URI registered in your IdP no longer matches the one Indee sends.
- The app registration's authentication method was changed (for example to require a signed assertion or PKCE where Indee is configured for a client secret).
- The one-time code was already used or has expired — this one is transient, and usually means a double-submitted or refreshed callback.
What your user sees:
Unable to Sign In
Unable to login. Contact your administrator for details.
How to resolve it: Check the secret's expiry on the Indee app registration in your IdP first. If it has expired or been rotated, generate a new one and send it to support@indee.tv through your usual secure channel and we'll update the connection. If the secret is valid, contact support@indee.tv with this notification so we can compare the redirect URI and authentication method Indee is sending against what your IdP now expects.
6. Call to userinfo_endpoint failed
Error line reads: Call to userinfo_endpoint failed
Error Description reads: your IdP's response to the userinfo request, which usually names the missing scope or permission outright. Wording varies by IdP.
What went wrong: The token exchange succeeded, so credentials and configuration are fine, but the
follow-up request for the user's profile was refused or didn't respond. Usual causes: the Indee app
isn't granted the openid, profile, and email scopes (or your IdP requires admin consent for them
that hasn't been given), the userinfo endpoint is unreachable or timing out, or your IdP was having an
incident at that moment.
What your user sees:
Unable to Sign In
Unable to login. Contact your administrator for details.
How to resolve it: Confirm the Indee app in your IdP is granted openid, profile, and email,
and that any required admin consent has been granted tenant-wide. Check your IdP's status page for an
incident covering the time in the email. If both are clean, send us the notification — the Error
Description carries your IdP's own response, which usually names the missing scope or permission
outright.
7. Email extraction failed
Error line reads: Email extraction failed
Error Description reads: Could not extract email from userinfo or id_token
What went wrong: Your IdP authenticated the user and returned their profile, but that profile
contained no email address. Indee identifies users by email, so there is nothing to match the sign-in
against. This is a claim-configuration issue, not a per-user one: either the email claim isn't
included in the token or userinfo response for your application, or this particular user's record in
your directory genuinely has no email value populated.
What your user sees:
Unable to Sign In
Unable to login. Contact your administrator for details.
How to resolve it: In your IdP, confirm the Indee application is configured to release the email
claim, and that the user named in the notification has an email address populated on their directory
record. If only one user is affected, it's their record; if everybody is, it's the claim mapping.
Either way we can confirm from our side what we received — send us the notification.
Summary
| Error line in the email | The problem in one line |
|---|---|
1. User does not exist |
The person authenticated with your IdP successfully, but has no Indee account or pending invitation. This is the only failure that also emails the user. |
2. Your IdP's own code — access_denied, invalid_request, unauthorized_client, invalid_scope, consent_required, login_required |
Your identity provider itself refused the sign-in and told us why. Nothing failed on the Indee side. |
3. Authentication denied due to mismatch in email address |
The email your IdP returned isn't the email the user typed on the Indee sign-in page. |
4. Call to authorization_endpoint failed |
The response coming back from your IdP couldn't be read as a valid OpenID Connect authorization response. |
5. Call to token_endpoint failed |
We couldn't exchange your IdP's one-time code for an access token — usually an expired or rotated client secret. |
6. Call to userinfo_endpoint failed |
The token was issued, but your IdP wouldn't return the user's profile — usually a missing scope or consent. |
7. Email extraction failed |
Your IdP's response contained no email address for the user. |