All users will have Username-Password-Authentication primary accounts
Some users may want to link their accounts to their Azure AD/Entra ID company accounts
They can then use a SSO Entra button to login to their account
This is setup via the common Microsoft endpoint so any user can do it.
My problem is:
Using the azure ad connection creates a empty account, I do not want any person to be able to do this. It seems the solution is an action to block these and delete the created account.
However, the flow in the front end seems to be:
User logins in via Username-Password-Authentication account
They click a button which prompts azure ad sign in
This account is then linked to the primary account
How would you distinguish between a user wanting to link their entra account and any person using the SSO button.
Any suggestions on the best and easiest way to implement this.
To prevent unwanted access, as you have mentioned as well you must implement a Post-Login Action that acts as a bouncer by evaluating the user’s identity structure before they are fully authorized. This Action is essential because it detects the “ghost” account at the moment of creation, blocks the login session, and uses the Auth0 Management API to immediately delete the unauthorized record from your database.
The distinction between a Ghost Account and a Legitimate User is found in the event.user.identities array. A ghost account appears as a standalone Entra ID profile with a single identity entry, which signals to your Action that this user has no pre-existing “Primary” account and should be deleted. For example, if identities.length === 1 and the provider is waad, the Action executes management.users.delete() to wipe the record instantly.
In order to tackle another possible distinction, once the accounts are linked, the Auth0 Action will always recognize that the user profile was originally anchored to the Username-Password-Authentication identity. Even when the user clicks the “Login with AD” button, Auth0 identifies the incoming Entra ID credentials as a “secondary” identity that belongs to the primary database account.
I hope this helps answer your inquiry and if you have further questions please let me know below!
Best regards,
Remus
The entra id account has to exist before linking. There does not seem to be any mechanism to add an account to your main account otherwise.
So how would you tell the difference between a legit entra id account that is about to be linked and ghost account inside your action to deny entra accounts.
You are asking how an Auth0 Post-Login Action can tell a user who wants to link their Microsoft Entra ID account apart from someone who clicks the Entra SSO button on the login page and creates an empty account, when the Microsoft common endpoint allows any Microsoft user to sign in.
Solution: Move account linking out of the login page and into your signed-in application. Only a user who is already authenticated with a Username-Password-Authentication account can start a link to an Entra ID identity. The login page SSO button then only signs in users who have an existing linked identity, and the Action blocks any Entra login that does not match a linked account.
Add a "Link Company account" button to the authenticated area of your application. Show this button only to users who have a valid session with their primary account.
Start the link from your backend. Your backend starts the Entra ID authentication for the secondary identity and receives the result. Do not rely on a query parameter from the browser to mark the request as a link.
Link the Entra ID identity to the primary user by calling the Management API from your backend, or by using the account-linking flow that requires the primary user's access token. The primary user's session proves which account the link belongs to.
Block unlinked Entra logins in a Post-Login Action. Check whether the authenticating user has a linked secondary identity with the waad connection. If the user has no existing link, deny the login with an access denial in the Action, rather than creating or deleting accounts inside the Action.
Clean up any empty Entra accounts created before the change with a separate scheduled script. The script uses the Management API to list users created in the Entra connection with no linked primary account, then reviews and deletes them in batches.