For name+password users I disabled sign ups ( Disable Sign Ups is now ON).
However, when users choose a social login (Google in our case) they are able to create accounts and log in!
How to make sure social login users cannot become users unless they are created by an admin?
There’s no way of stopping signup of social logins, because conceptually the signup does not happen at Auth0, but at the external identity provider. Under the same premise, an administrator can’t create a social login user at Auth0 directly.
What you might be after is, instead, some kind of authorization control. I.e. when you say “Authenticate with Google” the user will be able to do so (they already have their Google account!), but then you can say “O.K. John Doe, you are not allowed into this application”.
This authorization will involve checking some kind of identifier (most likely the email address) of the user that just logged in against a list of “approved users” (this can be in any database). This authorization policy can be in two different places:
At an Auth0 rule, where you can flat out deny authorization based on this condition. The application that requested the authentication will instead receive an error (that will need to present to the user somehow, explaining the situation).
function(user, context, callback) {
// this function will need to be defined based on
// based on your requirements. Can go to an external
// web service or database.
checkIfUserIsAllowed(user, function(err, isAllowed) {
if(isAllowed) {
// business as usual
callback(null, user, context);
} else {
callback(new UnauthorizedError("The user is not allowed to log in.");
}
});
}
Directly at the application, after receiving the authentication result from Auth0 (in this case, from the Auth0 perspective, it will look as a regular login).
Hi @nicolas_sabena - thanks for the clear answer. Two follow-up questions.
Is this as clearly or even better explained in the online documentation and if not, could it be added.
My use case is simple: I have an e-mail address corresponding to a name/password account in auth0, and if somebody comes in via social login only that e-mail address may go through. Is there a snippet for Rules that you can share that allows just that? It’s a very simple use case that many users will benefit from.
I’m not sure. I’m curious if you can think of any of the documents you went through while researching this that would be a good place to clarify it.
My use case is simple: I have an e-mail address corresponding to a name/password account in auth0, and if somebody comes in via social login only that e-mail address may go through. Is there a snippet for Rules that you can share that allows just that? It’s a very simple use case that many users will benefit from.
Where would you have this list of users that can login with a social identity? In an external database?
For cases like ours, where social login should be allowed for the ease of the login process but only for previously registered users, it should be enough that a stranger clicks on social login button and gets an error unless an admin had created an username/password account on beforehand with the same e-mail address. Where do I have this list of users - in Auth0 database, that is in https://manage.auth0.com/dashboard/eu/vacilando/users
Linking of accounts seems to exist as well. albeit with separate accounts (there go the stats) and a very complicated setup.
For cases like ours, where social login should be allowed for the ease of the login process but only for previously registered users, it should be enough that a stranger clicks on social login button and gets an error unless an admin had created an username/password account on beforehand with the same e-mail address. Where do I have this list of users - in Auth0 database, that is in https://manage.auth0.com/dashboard/eu/vacilando/users
The concept of creating the users in advance for social connection does not exist in Auth0 as of now.
You can create database users in advance, but they would still be completely separate entities from social logins, even if the email match, so you would need to create a rule to handle the additional logic.
The strategy then could be:
Create database users in advance (no public signup allowed)
Add a rule that checks if the user logging in is a social connection user. If so:
If this user is already linked to a db user, allow the log in normally.
Check if there’s a user with the same (and verified) email address in the DB connection (you can use API v2’s search-by-email endpoint for this).
If found, link the identities making the db connection user the primary identity
Creating users manually and then letting them use social login sounds like what I would like to do. Do you have a rule to share with me?
How does this idea relate to these:
Also, I get this error when running Account link:
**invalid_request** : Invalid parameter: client_id must be a string
I can see the admin is able to block a SSO user. Could we have all SSO login blocked by default, until admin approve/unblock it, or link it to an existing DB user?
Edit: I archived by defining a customer field user_metadata.allowed. New user will not have this metadata field denied, so they are denied. The admin needs to manually set allow:true to accept this user.
Configure Login flow with following code:
exports.onExecutePostLogin = async (event, api) => {
if (!event.user.user_metadata.allowed) {
api.access.deny("User metadata allowed is not set");
}
};