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.
Related
I have a unique requirement for a password reset.
We have users without email(or have invalid email), they just signup using a username.
So, to reset passwords, we want to have a separate UI application for support people that will allow resetting users' passwords without needing to send the password over email or can be sent to the common support email of the organization.
Is there a way we can use Graph API for this purpose? Custom policies need email to send passwords over(don't want the user's phone numbers at this moment).
Appreciate any leads in this matter.
Thanks.
Yes, you can.
But not ideal. The support person knows the password. And how does the user get informed of the password?
The correct way is to use a magic link that contains the username and when the user clicks on the link, they get the reset password flow. That way only the user knows the password.
How can I detect if a user already singed with a social account on my website and now wants to create a normal account?
How do I detect the changes?
My personal vision on this:
Let the user sign in with social auth then add the email in the database(mongo) but with no password?
Also when the same user wants to register on the website with the same email but without the social auth and a password, i should redirect him to his profile info from the social auth like username?
An example of what I am talking about:
User signs with google+ on stackoverflow
Then after a while comes back to sign for an account with the same email but a different password.
What is the best way to deal with this situation also from the GDPR standpoint can I use passport for this?
Thank you
When a user registers with social auth, you can also prompt for password (if you wish so) or create an account without it. Next time when a user registers using the same password, you should show an error message 'Email is taken'. In that case, user should receive an automated email that there was an attempt to use his email containing information on how this account was created (e.g. with Google+) - as a reminder.
Using social accounts for auth isn't safe and asking for password (requesting long passwords with special characters, upper/lower case letters) adds a little bit to the overall security. And Two-Factor Authentication takes it to the next level. For most websites, it should be secure enough. Temporarily blocking accounts after a number of unsuccessful attempts is easy to implement and protects from brute forcing.
Alternatively, a user should have an option to restore access to his account by means of requesting a password recovery URL to be sent to the email attached to the account. Then a user is prompted to input password that will be saved for the given account. Thus a user can log in to his account using email/password or the social auth that was used to create it.
With regards to GDRP, a user should be able to:
see what social accounts are connected to the profile and be able to detach them
delete his account (the right to be forgotten)
see what data is stored on him and export it (data portability)
modify data (Right to rectification)
opt-out/in for getting promo emails
manage advertising Cookies
There should be clear T&C provided with a full description of what data is stored, why and for how long.
Additionally, security (2FA, https, etc.)
This is in a nutshell ...
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.
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.
Problem assumptions/conditions:
There exists a user with email foo#bar.com (unverified) in the system.
Visitor is not signed into the system (no current session, e.g. new browser).
Visitor signup/login using Google Account, through OAuth (user authorizes).
The system receives callback with uid and the email foo#bar.com [verified by Google].
I see three options here:
A. Sign in the visitor to the existing account with email foo#bar.com. This have some security implications.
B. Ask for a password [assuming there is a password in the system, this may not be the case with multiple OAuth providers] and sign them into existing account if it's valid.
C. Reject the login/signup, say email is already used, encourage user to login before connecting with Google.
What are the security risks with option #A?
What I've come up with myself:
'Anticipation attacks' could be performed, where an attacker anticipates a signup and creates an account on the system before the target does. After the target has signed up using OAuth he will have an active session on that account. Would be defeated by clearing all sessions on the account before doing #A.
When the user logged in through OAuth in Google, you can be sure that the email address you get back from Google really belongs to that user. So the thing you seem to worry about is that the user already known on your system by that email address does not own that email address. That should have been caught by the time he signed up, with an email conversation. But if it isn't, you might want to reset the password and send an email to the genuine user that you did so, and for what reasons. You may also want to log the user out if he is currently logged in. The user can still access his data, but only through his OAuth login session, or by responding to the email. The email should state that it is a precaution, as there is no way to find out if it really is the same person.
An "accidental attack" can happen too:
In step 1, the user who signed up with address foo#bar.com, in fact intended to type fuu#bar.com, but typed a typo: foo instead of fuu.
Now, the Google user signs up with Oauth and foo#bar.com, and in this way hijacks the account of the step-1 user. Accidentally :-) because of a typo made by the step-1 user.
So, either the step-1 user can anticipate-attack the Google user, or the Google user can accidentally-attack the step-1 user. (I cannot think of any other attacks at least not right now.)