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.

16

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?

Mark.

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": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "email_verified": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
}

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.

3 Likes

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