Organization: User onboarding - without `Enable Auto-Membership`

Get Help
,
1

I am try using Enterprise connection involved into my organization, I am using management Api to create and manage connection.

  1. After enabling a connection to an organization with HRD (eg. sample.com) → the two types of user should be logged into the application.
    1.1. user can be sent invitation with that connection and organization and once user users the invitation user can be logged in successfully.
    1.2. existing user who are not present as a SSO user, who are currently only have username and password access. can no longer use the login since HRD is enabled.

to solve these cases, we have enabled the auto-membership on login. so that existing user can onboarded. and created a post login clause to check if any of the USER_IDs with a mail has email_verified has true.

this works well, but where it breaks is, once the some random user not part of my application but part of the configured SSO, tried login
user moves to auth0-> navigate to sso via hrd → user login success → and then post login revoke access so login fails.

but user is added as a member to the organization. So, I cannot send invitation to this person again at all cases.

on these 2 cases with Enable Auto-Membership and **Disable Auto-Membership
**
give me a proper workflow on how connection and invitation can be handled for both new and existing users.

I am using /authorize call with HRD enabled connection and organization in the query param. without auto-membership and without invitation, using post login or something, can we automatically onboard that user who is already a member of that organization (same email but a DATABASE USER).

2

Hi @vignesh.ramalingam

The core issue you are facing stems from Auth0’s execution pipeline. Organization membership is evaluated before Post-Login Actions run.

If you disable Auto-Membership and a user attempts an /authorize request with the organization parameter, Auth0 will immediately block them with a “User is not a member of the organization” error. Your Post-Login Action will never trigger, making it impossible to automatically onboard them at that exact moment.

Conversely, if you enable Auto-Membership, Auth0 adds the user to the Organization before your Post-Login Action can block them, which pollutes your Organization state with random users.

[Solution]:
We must adapt your workflows. Here are the two best-practice strategies to handle this correctly:

Option 1: The “Auto-Membership + Cleanup” Strategy (If you keep Auto-Membership ON)

If you want the frictionless onboarding of Auto-Membership for your existing users, you must clean up the “random” users dynamically. You can do this by using the Auth0 Management API inside your Post-Login Action.

  1. Keep Auto-Membership Enabled .
  2. Update your Post-Login Action. When it detects an unauthorized user, it should not only call api.access.deny() , but it should also instantiate the ManagementClient and explicitly remove that user from the Organization:
const ManagementClient = require('auth0').ManagementClient;

exports.onExecutePostLogin = async (event, api) => {
  // Your custom logic to check if they are allowed
  const isAuthorized = /* your logic here */;

  if (!isAuthorized) {
    const management = new ManagementClient({
      domain: event.secrets.domain,
      clientId: event.secrets.clientId,
      clientSecret: event.secrets.clientSecret
    });

    try {
      // Remove the user
      await management.organizations.removeMember({ 
        id: event.organization.id 
      }, { 
        members: [event.user.user_id] 
      });
    } catch (e) {
      console.log("Failed to remove user from Org:", e);
    }

    // Block the login
    api.access.deny("You are not authorized for this application.");
  }
};

Option 2: The “Pre-Provisioning” Strategy (If you turn Auto-Membership OFF)

If you want maximum security and prefer to leave Auto-Membership Disabled , you cannot rely on the user’s first login to onboard them. You must proactively link their identities.

Since you are already using the Management API to create these connections, you can run a one-time migration script when you turn on HRD for a specific domain:

  1. Query your Auth0 Database for all users with that domain (@sample.com ).
  2. Use the Management API to pre-create their Enterprise SSO identities.
  3. Use the Management API to link their new SSO identity to their existing Database identity.
  4. Because their primary Database identity is already a member of the Organization, the newly linked SSO identity inherits that membership.

Kind Regards,
Nik