Email verification for Enterprise users

I want to bypass email verification for Enterprise users (SAML, G Suite, etc.).

I have a SAML based enterprise connection set up. An example user in this connection has “Pending” status for email verification under their email address in the management console.


If I try to manually set email_verified to true via the Management API, I get:

  "statusCode": 400,
  "error": "Bad Request",
  "message": "Email verification is not supported for enterprise users",
  "errorCode": "operation_not_supported"

Does this mean email verification is not applicable to enterprise connections (in which case the Management Console UI should not show a status at all)? Or does it mean email verification is required for enterprise connections and there is no way to manually set email_verified to true meaning no way to bypass this step?

1 Like

Addendum: If I log in via my Google Apps / G Suite connection, the resulting profile has "email_verified": true. Logging in via the SAML connected IdP, there is no email_verified field in the resulting profile, and in the console it shows ‘pending’ status.

Just spit-balling but maybe this is related to G Suite using OIDC and the other connection being SAML? But this just further confuses the 400 error above… clearly email verification is supported in some sense for G Suite enterprise users.

I have the same issue. And yes, our G Suite works, and an Okta (SAML) connection does not. Should I be asking for some additional information to be provided from the Okta side maybe?

We don’t want verification emails to be sent to enterprise customers. How do we overcome this?


Hello @mcrawshaw,

Welcome to the Community! If the identity provider is an OIDC provider (e.g., Google), you should get email_verified in the security token from the provider. If it is a SAML provider, you have a couple options:

  1. Have the provider add an email_verified claim to the SAML assertion,
  2. Map some other value to email_verified.

We went with the second option. From what I can tell, because email_verified is a boolean, you can map any truthy value to it. For example, we are mapping the nameidentifier field to email_verified:

    "user_id": "",
    "email": "",
    "email_verified": ""

We know our 3rd party provider will always provide a valid nameidentifier, which in this case happens to be the user’s email address, so by mapping that string to email_verified, we get email_verified set to true at account creation time. I am submitting feedback to Auth0 to allow us to edit email_verified for Enterprise users.


Hi @markd interesting idea. Though, it might work today, I have some concerns if Auth0 does some form of type checking for SAML mappings in the future. At that point, this may become a breaking change.

I am submitting feedback to Auth0 to allow us to edit email_verified for Enterprise users.

I think it should be a builtin feature on the connection configuration. I agree with this one.

1 Like

Worth noting that the Azure AD connection type has an "always set email_verified:true" option built in. Just need to see that added to SAML, and other non-OIDC cxn types.

1 Like