Authentication error codes

When a user cannot sign in, the login page shows a short message and an error code. This page explains what each code means, what to check first, and when to escalate to support.

The codes are stable across releases, so they are the fastest way to tell configuration problems apart from identity provider problems and from genuine user problems. Two codes account for most authentication tickets: OIDC_ERROR_1012 and OIDC_ERROR_2703. Both are covered in detail below.

How error codes are displayed

Where the code appears depends on which flow failed.

Sign-in flows (a user logging in to the Web administrator or Web user interface, whether by clicking a Login via <Provider Name> button or by entering a username whose domain matches an authentication provider) return the user to the login page with:

Authentication failed. Try to log in again.
(Code: OIDC_ERROR_1012).

When the identity provider or the service supplied more information, a second line follows:

Technical error detail:
user_credentials_failed

The Technical error detail line is the most valuable part of the message. Always capture it — for OIDC_ERROR_1012 in particular, the detail is what separates three completely different causes. See the Technical error detail values table below.

Authorization flows (granting the service access to a mailbox, an admin consent, or an access-control authorization — started from inside the product by an already signed-in user) return to the main page instead, with:

An error occurred during authorization. Please contact system administrator. Error code: 2708

These messages carry the bare number without the OIDC_ERROR_ prefix. The numbers themselves come from the same catalog, so a bare code on the main page and the same code with the OIDC_ERROR_ prefix on the login page mean the same underlying condition, reached from a different flow. Please quote the code exactly as it appeared, including the prefix if there was one — it tells us which flow the user was in.

Three conditions are reported in plain language with no code at all:

Message

Meaning

What to check

Session expired. Try to log in again.

The browser returned from the identity provider but the sign-in session that started the flow was no longer there.

Usually benign: the user left the provider's page open too long, or used a stale browser tab. Ask the user to start again from the login page. If it repeats for every user, escalate — see OIDC_ERROR_2703.

This login method is disabled. Please contact administrator.

The authentication method is switched off for this account.

The account's license or feature set does not include this login method. Check the account's product type.

This login method is misconfigured. Please contact administrator.

The authentication provider referenced by the login button no longer exists, is inactive, or has OIDC disabled.

Open Users → Authentication providers and confirm the provider is present, Active, and has an OIDC authentication method selected.

Login redirect

These occur when the user clicks the login button — before the browser ever reaches the identity provider. They are almost always configuration, not user error, and they affect every user of that provider equally.

Code

What the user sees

What it means

What to check first

When to escalate

OIDC_ERROR_1010

Authentication failed. Try to log in again.

The service could not work out which customer account the request belongs to, from the host name in the browser's address bar.

The host the user is on must be listed in the account's Domains. Compare the address bar with Domains on the account exactly. If the customer reaches the service through a CNAME or a reverse proxy, the externally visible host is the one that must be listed.

The domain is listed and correct but the code persists.

OIDC_ERROR_2704

Authentication failed. Try to log in again.

The login request arrived without a usable authentication provider reference, or with one that is not a number.

Usually a stale bookmark, a hand-edited URL, or a link built by an external portal. Ask the user to start from the login page.

Users hit this from the normal login button, not a bookmark.

OIDC_ERROR_2709

Authentication failed. Try to log in again.

The service could not retrieve, or could not accept, the identity provider's discovery document (/.well-known/openid-configuration).

For Generic OIDC: re-check the Well-known URL. It must use HTTPS, end in /.well-known/openid-configuration, be reachable from the service region, and its issuer host must match the well-known URL's own host. For Entra/Okta the tenant or Okta org may be unreachable or mid-change. Try saving the provider again — the form validates the URL live and will name the specific problem.

The well-known URL validates in the provider form but sign-in still fails with 2709.

OIDC_ERROR_2710

Authentication failed. Try to log in again.

The discovery document was retrieved but an OIDC client could not be built from it — typically a missing authorization or token endpoint.

Fetch the well-known URL in a browser and confirm it returns both authorization_endpoint and token_endpoint.

Both endpoints are present. This is normally a product-side condition.

OIDC_ERROR_2707

Authentication failed. Try to log in again.

The authorization link could not be built, because the client configuration for this provider could not be resolved.

Re-open the authentication provider and re-save it. For customizable OIDC, confirm Client ID, Client secret and Callback domain for custom application are all filled.

Re-saving does not clear it.

OIDC_ERROR_missing_client_id

Authentication failed. Try to log in again.

An admin-consent flow was started for a provider with no Client ID configured.

Fill in Client ID on the authentication provider before starting the consent flow.

Not needed — this is always configuration.

OIDC_ERROR_missing_callback_domain

Authentication failed. Try to log in again.

An admin-consent flow was started for a provider with no callback domain selected.

Select Callback domain for custom application on the authentication provider.

Not needed — this is always configuration.

Token exchange and sign-in

These occur after the user has authenticated at the identity provider and the browser has come back to the service. This is where the two dominant codes live.

Code

What the user sees

What it means

What to check first

When to escalate

OIDC_ERROR_2706

Authentication failed. Try to log in again.<br>Technical error detail:

(text from the identity provider)

The identity provider itself refused the sign-in and returned an error. The service is only relaying it.

Read the Technical error detail — it is the provider's own message and is usually decisive (consent not granted, user not assigned to the application, blocked by Conditional Access, expired client secret). Fix it at the identity provider. For built-in local providers the detail is replaced by "User is not part of the organization." or a generic message.

The provider's message indicates the service sent something wrong, for example an unexpected redirect_uri or scope.

OIDC_ERROR_2701

Authentication failed. Try to log in again.<br>Technical error detail:

Error: <error>, Description: <description>

The authorization code could not be exchanged for tokens at the identity provider's token endpoint.

The detail carries the provider's own OAuth2 error. Most common causes, in order: (1) the Redirect URI registered at the identity provider does not exactly match https://<account-domain>:<port>/callback/oidc-login — including the port (default 8443, or no port behind a reverse proxy); (2) an expired or rotated Client secret; (3) clock skew, or a code reused after the user pressed Back. See the sibling provider pages for the exact Redirect URI patterns.

Redirect URI and client secret are both verified correct and the detail is empty or unhelpful.

OIDC_ERROR_2711

Authentication failed. Try to log in again.<br>Technical error detail:

User authentication via OIDC failed, missing required refresh_token.

Sign-in succeeded at the identity provider but no refresh token was issued, and this provider is configured in a way that requires one.

Add the offline_access scope to the provider's Scopes — it is part of the default scope list and is easy to lose when the field is edited by hand. At the identity provider, confirm offline access is permitted for the application. Alternatively configure a Service Account on the provider, which removes the refresh-token requirement.

offline_access is requested and granted but the code persists.

OIDC_ERROR_2703

Authentication failed. Try to log in again.

The callback came back without a matching one-time security token for the sign-in session that started the flow.

Check the capitalization of the account's Domains first. If a domain is stored with different capitalization than the host users actually type — for example Contoso.example.com stored while the address bar shows contoso.example.com — every OIDC sign-in on that domain fails with 2703. Re-enter the domain in lower case and retry; this resolves the majority of 2703 reports. Otherwise: a user who bookmarked the callback URL, opened the login page in two tabs and completed both, took longer than the session timeout, or a load balancer that is not keeping the user on one node.

Domains are all lower case, the user completed a single clean sign-in in one tab, and 2703 still occurs. Include the exact host from the address bar and the time of the attempt.

OIDC_ERROR_1012

Authentication failed. Try to log in again.<br>Technical error detail:

(a short keyword, sometimes absent)

The identity provider authenticated the user, but the service could not turn that into a signed-in user. This code covers several unrelated causes — the Technical error detail decides which.

Read the Technical error detail and use the table below. If the detail is absent, treat it as a product-side failure and escalate.

Any 1012 with no Technical error detail, or one whose detail is unrecognized_internal_error, user_save_failed, provider_not_healthy or token_validation_issue.

OIDC_ERROR_1904

Authentication failed. Try to log in again.

The user account is suspended at the identity provider.

Re-enable the user at the identity provider.

Not needed.

Technical error detail values

For OIDC_ERROR_1012, the Technical error detail names the cause. This table is what turns a multi-week ticket into a single check.

Technical error detail

What it means

Where to fix it

user_credentials_failed

The credentials presented were rejected.

At the identity provider. For a card, PIN or username/password login at an MFD, see Card, PIN and OTP sign-in below.

user_not_found

The user authenticated, but no matching user could be resolved in the service.

Check the provider's Custom token claim names, in particular which claim supplies the username (preferred_username by default). If the identity provider issues a different claim, sign-in succeeds upstream and fails here. With SCIM, confirm the user is in the provisioning scope.

invalid_domain

The domain part of the user's name does not match any domain on the authentication provider.

Add the domain to the provider's Domains list, or correct the claim mapping so the username carries the expected domain.

not_able_to_parse_user

The token was accepted, but the user's attributes could not be read from it.

Claim mapping. Compare Custom token claim names against the claims the identity provider actually issues. For Entra, confirm the groups claim was added under Token configuration if groups are expected.

user_expired

The user is expired at the identity provider.

At the identity provider.

mfa_failed

Multi-factor authentication did not complete.

At the identity provider. Note that Service-Account-only authentication does not support MFA; enable OIDC on the provider if MFA is required.

no_id_token_returned

The provider returned tokens but no ID token.

The application registration is not requesting, or not permitted to issue, an ID token. Confirm openid is present in the provider's Scopes.

provider_not_allowed_by_feature_flag

This provider type is not enabled for the account.

The account's license or product type.

token_validation_issue

The ID token's signature or claims could not be validated.

Escalate. Include the provider type and the well-known URL.

provider_not_healthy

The authentication provider or its service is not responding.

Check the provider's Service selection and that the corresponding authentication service is online. Escalate if the service is online.

user_save_failed

The user was authenticated but could not be written to the service.

Escalate.

unknown_credentials_type, unrecognized_internal_error, unknown_error

Internal condition with no useful classification.

Escalate.

(detail line absent)

One of: a required refresh token could not be stored; the sign-in timed out; or an unclassified internal failure.

Escalate. Include the exact time of the attempt so the server-side log line can be found.

The detail may also read exactly The authentication attempt timed out. That is a sign-in that exceeded the internal timeout, usually because the identity provider or a directory lookup was slow. Retry once; escalate if it repeats.

User and group synchronization

These appear when users and groups are provisioned into the service (SCIM, service-account sync, API, or manual editing) rather than during sign-in. With SCIM they surface as a failed entry in the identity provider's provisioning log, not as a login-page message.

Code

What the user sees

What it means

What to check first

When to escalate

1016

Cannot save user — a user with this name already exists.

Two users would end up with the same username on the same account.

The most common cause is the same person arriving from two authentication providers, or a SCIM-provisioned user colliding with a pre-existing local user. Decide which record is authoritative and remove or rename the other.

Neither record can be found in the UI.

3502

Duplicate short ID.

The short ID being written is already used by another user on the account.

With SCIM, the mapped source attribute is not unique across the provisioned population. Fix the attribute mapping or the source data.

The reported short ID is not visible on any user.

3503

Duplicate card ID.

The card number being written is already assigned to another user.

With SCIM, check the cardNumbers mapping — a Join(...) expression with a shared or blank attribute produces duplicates. Otherwise find the existing holder and unassign.

The reported card number is not visible on any user.

1011

Cannot add card to user.

A card could not be attached to the user record.

Retry, and check the card is not already assigned.

Repeatable for one user.

Card, PIN and OTP sign-in

These occur at the MFD terminal, or when a PIN is set, rather than on the Web administrator or Web user interface login page.

Code

What the user sees

What it means

What to check first

When to escalate

3400

The PIN is too short.

The PIN does not meet the account's minimum length.

The PIN policy on the account. The message includes the required length.

Not needed.

3401

The PIN must contain a letter.

PIN policy requires a letter.

The PIN policy on the account.

Not needed.

3402

The PIN must contain a number.

PIN policy requires a digit.

The PIN policy on the account.

Not needed.

3403

The PIN cannot contain a sequence.

PIN policy forbids sequential characters, for example 1234.

The PIN policy on the account.

Not needed.

1018

Too many failed login attempts.

The account-level retry limit was reached, typically after several rejected card reads.

Wait for the lockout to clear. If it triggers on a first attempt, the card is being read in a format the account does not expect — check card conversion.

The limit triggers immediately and repeatedly across a whole site.

2029

Card not recognized.

No card conversion is configured that can interpret this card's format.

Configure or correct the card conversion for the reader type in use. Different reader firmware can emit the same card in different formats.

The conversion is configured and matches a manually decoded sample.

2030

Card metadata unavailable.

The user's stored card metadata could not be read.

Re-assign the card to the user.

Repeatable for one user.

2031

(no user-facing message; appears in diagnostics only)

A failed card login could not be recorded.

No action — informational.

Not needed.

Card, PIN and username/password login at an MFD require a Service Account or SCIM on the authentication provider. If a user can sign in to the Web administrator or Web user interface by OIDC but not at the MFD, the provider most likely has OIDC only. See the sibling provider pages for how to add SCIM or a Service Account.

Configuration-time errors

Code

What the user sees

What it means

What to check first

When to escalate

2120

(the message names the specific problem)

The SAML single sign-on configuration was rejected when saved.

The message is specific — incomplete configuration, an invalid metadata URI, an unreachable or oversized metadata file. Fix what it names.

The message is generic.

1707

A custom application is required.

The account's domain does not resolve to a usable default host, so a custom application registration must be configured explicitly.

Configure a custom OIDC application for the provider rather than relying on the built-in one.

Not needed.

1708

A custom application and domain are required.

A group-sync configuration is missing its custom application or its domain.

Complete both fields on the sync configuration.

Not needed.

Before you escalate

Escalations resolve much faster with these five items. Items 2 and 3 are the ones most often missing.

  1. The full error code, including the OIDC_ERROR_ prefix if it was shown, and whether it appeared on the login page or the main page.

  2. The Technical error detail line, verbatim — or an explicit statement that there was none.

  3. The exact host from the browser's address bar, copied rather than retyped, together with the account's Domains list as configured. Capitalization matters for diagnosis; please do not normalize it when reporting.

  4. The timestamp of the attempt, with time zone, and whether it affects one user, one site, or everyone on the account.

  5. The authentication provider's type and authentication method — Entra, Okta, Generic OIDC or Google, and whether OIDC built-in, OIDC customizable, +SCIM, or +Service Account.

For a reproducible sign-in failure, a browser HAR capture of the whole flow — from clicking the login button through to the error page — lets the redirect chain be checked against the server side without further round trips.