Skip to content

Federated Email Not Verified

URI: https://docs.ankatech.co/errors/federated-email-not-verified
HTTP Status: 422 Unprocessable Entity

When you see this

A federated identity signed in for the first time and this deployment does not accept email addresses from the OIDC provider it used, so no new account could be seeded for it. The posture is server-derived: it is read from the operator's persisted email-verification trust declaration for that provider, and the email_verified claim in the token is read by nothing on the admission path. An identity provider may not vouch for its own addresses.

Common Causes

  • The provider's email-verification trust was deliberately declared as not trusted, and this is a first-time login for the subject.

Response Example

{
  "type": "https://docs.ankatech.co/errors/federated-email-not-verified",
  "title": "Federated Email Not Verified",
  "status": 422,
  "detail": "This deployment does not accept email addresses from the identity provider used for sign-in, so a new account could not be created for this identity.",
  "instance": "/api/v3/admin/s2s/auth/idp/provision",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

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

The identity provider is not the cause here and cannot be the remedy — wording that asks the person to have their provider verify the address would be false on both counts. The body names no address, no tenant and no account attribute; the actionable evidence rides the audit row and its EMAIL_NOT_VERIFIED reason, which name the tenant and the provider. This gate runs before the email-ownership check, so receiving it discloses nothing about whether the address is already taken.

How to Resolve

  1. Decide whether this deployment should trust the provider's asserted email addresses, and set the provider's email-verification trust accordingly.
  2. If the provider must stay untrusted, bind the identity to an existing account by its external subject before it signs in — the gate applies only to first-time provisioning, so a returning subject never reaches it.
  3. Note that SAML and LDAP providers hold no such declaration and are trusted by construction; only OIDC providers reach this gate.

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