Email verification for Enterprise users

Help
1

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
2

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.

3

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.

4

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.

5 Likes
5

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.

3 Likes
6

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.

2 Likes
7

Thanks for chiming in w/ agreement for the need for this feature (having a setting to edit email_verified for Enterprise users w/ SAML connection) to be builtin, Saltuk. Do you know the status of this? I know there’s the 4/30 deadline for migration to having email_verified set on the connection level, but I don’t see a way to reliably do this.

1 Like
8

Hi @sliao it is in our backlog but we don’t have an ETA. I don’t think we will have anything before 4/30 unfortunately.

9

@Saltuk Can I confirm there is still no way to set email_verified to true for SAML provider?

If so, does this mean Force Email Verification rule + Verication Email (magic link) will not work for SAML provider?

10

Hi @ton, not yet, unfortunately.

If so, does this mean Force Email Verification rule + Verication Email (magic link) will not work for SAML provider?

You may enable account linking and link users from the SAML connection with an Auth0 DB for the same email address after verifying the email for the Auth0 DB connection. Here are the steps.

1- Create the user with the management API on the Auth0 DB with verify_email set to true and email_verified set to false with long (e.g. 20 characters or more) random password. This call should send an email verification link to the user. Obviously, the random password should be different for each user created.
2- The user clicks the link and verifies the email address on the Auth0 DB.
3- Finally, perform account linking. There are a couple of ways to link accounts, so I’m skipping the details. You may find the related link here.

Please note that I assume for the SAML connection, your users’ email addresses are verified and belong to the same users you are linking with the Auth0 DB; otherwise, this may cause a security issue for you.

11

Thanks. Yes, all SAML connection users are verified.

1 Like
12

Hi @Saltuk,
We also have the same scenario where users are being authenticated through some enterprise connection e.g Open ID. But for those users (when created on Auth0), email_verified field is false. If we can handle this in rules pipeline, that would be great! If not then I think this scenario should’ve been handled or there should be some cleaner way to do it.

13

Hi, @hassan what was your business use case? Do you need to verify the emails of the enterprise connection users?

1 Like
14

@Saltuk Yes! We need to verify users coming from enterprise connections and we don’t want to proceed another email verification process, we consider all the users coming from enterprise connections as verified users.

15

IMO this is a pretty common use case:

  1. Auth0 customers want an email_verified flag in the Auth0 user profile no matter where that user came from / how that profile was created,
  2. For Auth0 user profiles created from enterprise connections, Auth0 customers want email_verified automatically set to true, under the assumption that the customer already has a trust relationship with the source of the data.

While email_verified is an OIDC thing, having it consistently set the Auth0 profile no matter the source of the user profile simplifies the login flow. E.g., no need to give special consideration to enterprise connections in a Rule that happens to check the state of email_verified.

5 Likes
16

Got it! In that case data would seem to be inconsistent (even with working functionality), as for enterprise connection users, Auth0 will be showing pending as a status for the email_verified field.

1 Like
17

Hi,

we have the same use case. We want avoid email verification for enterprise customers.

Since the last message, is there any new way to accomplish this work without mapping the email_verified or setting a “fake” mapping for it?

18

I believe in the current state this really needs to come from the FSSO partner. If they are connected using OIDC then this should just be included since email_verified is a standard OIDC claim, but the partner still needs to provide it.

For SAML partners I believe they need to include an equivalent claim in their security token that you can map to email_verified when the user first authenticates.

1 Like
19

@Saltuk / @markd

Do we have an update here. We have enterprise connections (SAML) users who are marked as email_verified=false and there is no way to mark them as true. Could the fix be prioritized ?

20

Bump. This is terrible. When will this be fixed? Azure AD Connection has a “Automatically set email to be verified” option, why has this not been extended to SAML?