Social Providers - Deny login/signup for specific email domains

[gyo]

Hello,

I’ve created 2 custom actions that only allow specific email domains to be used for login/signup.

Login flow

exports.onExecutePostLogin = async (event, api) => {
  const emailDomain = event?.user?.email?.split('@')?.[1] || ''
  const allowedDomains = ['mydomain.com']
  
  if (!allowedDomains.includes(emailDomain)) {
    api.access.deny(`Email domain "${emailDomain}" is not allowed.`)
  }
};

Pre-Registration flow

exports.onExecutePreUserRegistration = async (event, api) => {
  const emailDomain = event?.user?.email?.split('@')?.[1] || ''
  const allowedDomains = ['mydomain.com']
  
  if (!allowedDomains.includes(emailDomain)) {
    api.access.deny(`Email domain "${emailDomain}" is not allowed.`, 'Access denied')
  }
};

When trying to login/signup via Username-Password-Authentication with a domain other than the specified ones, Auth0 returns the error message to the login form, and everything works fine.

The problem is when users try to login/signup via OAuth2 Social Providers like google-oauth2:

• The Pre-Registration flow does not run for social providers (common Auth0 behaviour)
• The Login flow runs and it logs the “login error” in the logs, but the user is still created in the tenant

Is this the expected flow? I was expecting users to not be created in the Auth0 tenant if any of the actions fails.

Thank you in advance!

[rueben.tiow]

Hi @gyo,

Welcome to the Auth0 Community!

I understand that you have questions about using Actions with Social Connection users.

@gyo

The problem is when users try to login/signup via OAuth2 Social Providers like google-oauth2:

• The Pre-Registration flow does not run for social providers (common Auth0 behaviour)
• The Login flow runs and it logs the “login error” in the logs, but the user is still created in the tenant

Unfortunately, the Pre-Registration flow does not run for social connection users as you have found.

This is because we are not creating a new user on the Social Provider, but rather, once a user has logged in, their identity from the social provider is mapped to an Auth0 profile, and the result is sent to the application that requested login.

This creates an Auth0 user record using the identity from the selected Social Connection. (Reference: Social Connections for Partners)

In other words, we cannot prevent the creation of a Social Connection user on the Auth0 side. The best we can do here is prevent them from logging in. This is the expected behavior for this flow.

I hope the explanation was clear and helpful!

Please let me know if you have any follow-up questions.

Thanks,
Rueben