When users in an MVC application with Google/Facebook/Twitter authentication, register for the first time, they go to the ExternalLoginConfirmation.cshtml page. There they are asked for their username, but are only allowed to fill in an email address, according to the ExternalLoginConfirmationViewModel model.
Is it set to email for a reason? In code it's creating a new applicationuser to store the user, but it's using just-entered-email for both username & email.
Can I go horribly wrong when I allow users to enter username of their choosing, and store email address as I got it from Google/Facebook/Twitter, etc?
I think the MVC5 registration flow is flawed by default, and needs to be reworked.
by trusting the default provider's emails (set email is auto confirmed from Google+, Yahoo, MS, and Facebook).
don't let the user enter an email+username, as he can register ANY email he enters in the box, straight to the AppUsers table.
MVC5 needs to create a User if not done so already at the ExternalLoginConfirmation method.
the default login password would be set to something blank, with links to reset it if needed (or totally disabled).
This would allow the users to register on any massively trusted providers automatically, it would link accounts together as long as their email is the same, and allow to unlink accounts once again.
The way MVC5 is setup right now is half-baked and broken, for no apparent reason.
Related
I'm working on my first MERN fullstack project (an e-commerce demo). I have almost finished the authentication part, but I am having doubts about how to manage the users who have the same registration email both through custom sign-in and google login on the MongoDB database.
While doing various researches, I noticed that one of the methods used is the following:
1- If the email of the user who logs in via google login is already saved in the database as the same user had already registered via traditional sign-up, a new user will not be created in the database, but with both methods of signing -in we will point to the same user already saved with that email.
2- If there are no users saved in the database with that email (as the user logged in for the first time with google login and did not first register traditionally), once the user logged in with google login, it will be saved to the database for the first time.
However, this method presents problems with regard to the second type of users mentioned above.
In fact, if we merge the accounts with the same email on the database, if the user logs in for the first time with google, no password will be saved on the database. Therefore, if the same user decides in the future to log in in the traditional way, he will not be able to do so because he will not be able to fill in the password field.
How to solve this problem?
Usually sites with the "first Google login immediately creates an account" have 2 solutions to this problem:
As part of the "immediately create an account", they directly ask the user to choose a password.
Alternatively, their "Change password" section allows creating a password should there be none yet. Therefore the account is indeed passworld-less at the beginning, but the user can opt to add a password.
For the 2nd solution, there's the small problem that if the user loses access to their Google account and didn't set a password, they're locked out. Rare case which might not be worth looking out for. And perhaps your Customer Service can still help them out.
I maintain an app where we use Azure AD B2C to authenticate.
The flow is this:
Users are invited by email
They click a link to sign up using a B2C signin/signup flow
They fill in their info, including email address
They are redirected to our app
Now, what bothers me is that the users have to enter in their email address, even though we already know it. We just invited them using their email address.
It has been suggested that we could send people to a password reset page instead. But that doesn't seem ideal either, since they then have to verify their email address, even though we just verified it. After all, they started the flow by getting an email.
In many cases the users mis-type their email address when they are asked for it. That creates a lot of new issues, because we now have two different email addresses for the same users.
Similar question already answered # How to pass email suggestion to Azure AD B2C SignUp page. Answer https://stackoverflow.com/a/56503578/341185 describes how to send invitations.
Alternate approach using Javascript in custom policies
You can use custom policies along with Javascript to show email of the user in email address text box.
Approach:
While sending invitation link, send an extra query parameter like &email_hint=azureb2ccustomer#b2clogin.com and follow below steps to show this email_hint value in email address text box
Steps:
Enabling Javascript in custom policies https://learn.microsoft.com/en-us/azure/active-directory-b2c/javascript-samples
Change page contract to allow custom policies to run javascript https://learn.microsoft.com/en-us/azure/active-directory-b2c/page-contract
Update SignupOrSignin user journey to directly take to SignUp page https://stackoverflow.com/a/56503494/341185
Update your blob HTML page to read query parameters and put the value inside email textbox
var urlParams = new URLSearchParams(window.location.search);
document.getElementById("email").value = urlParams.get('email_hint');
Click here for example request
Add your comments if you still require any other kind of approach than described above to fit into your business model.
If you want to use custom policies, you can use the flow for password reset that has:
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=JWT
This puts the email address in a JWT so the user does not have to enter it.
On our website, we have existing users who use username(=email address) and password to authenticate. Now we also want to offer "Sign in with LinkedIn" because we know that a huge fraction of our users is also on LinkedIn. Doing this is technically not too challenging with PHP.
For new registered users via "Sign in with LinkedIn", I would store their LinkedIn ID upon registration, so this is nothing they can manipulate. So when they return, it's an easy decision: Check the LinkedIn ID, if it is known than all is good.
Now comes the tricky question: If an existing user decides to use "Sign in with LinkedIn" for the first time, is it enough to check if we have his email address in our database and then assume that it is him/her? Should we check additional data or...?
Thanks for any hints!
Since email address is unique key and it represent the username, i think you don't need any additional data to check if it is him since his/her password is equivalent to the linkedIn email address.
I'm building a web application for two different types of users, with a different registration form for each of them. I could split up those forms and send a verification e-mail after the form is validated.
But I'd prefer to have one general small form where the user enters his/her e-mail address and user type. The server then sends a verification e-mail with a link to further complete the profile, depending on the chosen user type.
Now my question is: should I include a password field in the small registration form? I have seen it before on many websites, but I can't see why I would include it. My plan is to make the user choose his/her password on profile completion. Nothing about the user will be stored until he/she completes the profile (I would securely hash the e-mail address with a timestamp in a url).
In general, the developers ask all the details including password at the time of registration and they allow to login using the same password. However, there is an open risk of unverified user can access all or some of the feature of the application. Sometimes the application also provides time frame of 24-72 hours to activate the user account, within this period user can access account with some restrictions.
For sensitive applications, you can ask for the password once the user verify the email address. So, that you are assured about the verified user.
If you are providing the feature to access the user accounts without being verified, make sure that the unverified account users can access the account with restrictions according to your application context.
Assume a new user registers today on my website today with Gmail-id and there gets an account created in OpenAM with user-name as Gmail-id.
Lets say in future the same user uses facebook account to login on my website. Taking this for granted that I know that the user has registered on the website with Gmail earlier and I precisely know his/her Gmail-id.
Is it possible that I can link both user credentials to the same OpenAM account without creating a new account ?
What could be the other alternatives ?
I'm going to assume that when you say "Gmail-id" you mean email address. Google also has a concept of a numerical ID that would not be constructive in this case.
To set this up, you'd need two OAuth 2 modules for each of Google and Facebook, with appropriate scopes to be given the email address in the user profile, and you'd need to set up the account mapping to map the email address from each of Google and Facebook to the mail attribute, and the attribute mapping would then have the same mapping (as well as other appropriate mappings to get user's name, etc).
This means that when the user returns to OpenAM an account with mail=[email from Google/Facebook] will be looked for, and if found, used. If not found, an account with that email address will be created, and would then be used in the future.
Obviously you will need to decide that you trust the email address provided by Facebook represents the identity you have from GMail, but it sounds like you're happy with that.