Skip to content

Identity Provider Email Unverified

URI: https://docs.ankatech.co/errors/identity-provider-email-unverified
HTTP Status: 422 Unprocessable Entity

When you see this

A federated login authenticated successfully at your identity provider, but the provider did not confirm the email address it asserted for that identity. No account is provisioned, and the login does not complete.

This is the one federated refusal whose remedy belongs to the identity provider's administrator rather than to the ANKASecure operator. Nothing in the platform's admission rules, group mappings or tenant configuration is wrong when this is returned — the sign-in was refused on the strength of the provider's own assertion.

Where it appears

This type is returned by the authentication service on non-navigation surfaces — that is, to a programmatic caller that consumes JSON. The browser-facing federation legs never render it: they redirect to the console login screen carrying the query parameter error=identity_provider_email_unverified, documented in Federated Login Errors.

The same underlying refusal is raised inside the platform, on the internal service-to-service provisioning call, as federated-email-not-verified. That internal type is not customer-observable and is not registered here; the authentication service re-renders it as the type on this page.

Not currently reachable on the LDAP leg

The only non-browser federation surface today is the LDAP credential login, and on that leg this refusal cannot fire: the email address is read from a bind-authenticated directory entry, which is authoritative for the account, so the authentication service marks it verified unconditionally (LDAP has no email_verified concept). The mapping is registered anyway, as defence in depth — the alternative is a refusal whose rendering on a future non-browser leg depends on an argument about reachability continuing to hold. Registered and unreachable is the deliberate state; unregistered would mean this refusal answered a generic 500.

Common Causes

  • The OIDC provider returned an email claim without email_verified: true.
  • The account at the identity provider was created with an address the directory administrator never put through verification.
  • A provider profile that suppresses or omits the verified-email signal for the requesting application.

Response Example

The instance below is a placeholder, deliberately not a real route. Every non-browser federation surface that exists today is the LDAP credential login, and the note above records that this refusal cannot fire there — so quoting that path would depict a response no code path emits. instance carries the request path of whichever non-navigation surface answered.

{
  "type": "https://docs.ankatech.co/errors/identity-provider-email-unverified",
  "title": "Identity Provider Email Unverified",
  "status": 422,
  "detail": "The federated login could not be completed because the identity provider did not confirm the email address for this identity.",
  "instance": "/api/v3/auth/idp/<non-navigation-surface>",
  "timestamp": 1730000000
}

Content-Type: application/problem+json — the response follows RFC 7807 Problem Details.

The example omits one member the service does serialize

The authentication service emits a seventh member on this response, "extensions": null — the optional extension bag, which this refusal never populates. It is null rather than absent because that service applies no null-suppressing inclusion to the field, so the bag is present and always null here. The example leaves it out to match every other page in this reference, none of which shows it; that is a documentation convention, not a claim that the member is absent from the wire. A client that rejects unrecognised members must expect it, and a client must not read a null bag as "the request produced no detail" — this refusal carries none by design.

The detail is a fixed, server-authored sentence. It never echoes the submitted address, the tenant identifier, or any provider response, because this edge is reachable by an unauthenticated caller. Do not parse it: branch on type, per Dispatch on type.

No correlation member in the body

The authentication service does not put a correlation identifier inside its problem documents — it carries no top-level correlationId and writes no extensions.requestId. Correlate a support request using the X-Correlation-Id response header instead. Which services put the identifier where is tabulated in Where extension members live.

How to Resolve

  1. Confirm at the identity provider that the account's email address is marked verified — in OIDC terms, that the email_verified claim is true.
  2. Have the directory administrator complete the provider's own verification flow for that account, then retry the sign-in.
  3. If the provider is expected to assert a verified address for every account and does not, review the application/client profile registered at the provider: some profiles omit email_verified from the released claim set.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.