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.
Related
I want to get the user emails used for Azure organization on callback action of SSO web login flow.
Could you please advise which property and which API permission should I request for it? I tried upn, preferred_username, and email properties, but as I understand they can differ from the actual email.
Tried multitenant and single-tenant approaches.
Keep in mind that the user logs in with their UPN, which is typically (but isn't necessarily) the same as their email address.
The email claim should contain the user's email address if the directory is looked after by admins. That's the one you're after.
More information on the default claim set can be found here.
More information on how the UPN might be populated, including the approach of using an Alternate ID can be found here.
This is the my web-app "User Settings" page.
I have simplified it to a minimum to better highlight the problem.
To authenticate users I use Auth0, I wanted to use the sub claim user_id to identify the users inside my MySQL database for update and retrieve user's info. Unfortunately the user_id is different for each provider, for example, if the same user with the same e-mail logs-in via Auth0 he gets a user_id if he does it via google he gets another one.
I thought about using email to link logged user to his info.
The problem is in my API. Before the change it was "localhost: 8080 / api / users /: id"
each time it created a new id and in any case it was impossible to recover the data of the single user. Now that I have replaced "id" with "email" my API has also changed in "localhost: 8080 / api / users /: johnsmith#xxx.com".
Before:
After:
In a few words, the request url on the client side has also changed.
I would like to make sure that the GET and PUT requests are made based on the e-mail of the logged user without going to modify the whole back-end.
Sounds like something is wrong with how you authenticate users. If you have multiple ways to authenticate a user, those methods need to be in a one to many relation with the user. For example each user has a list of auth-methods, and whenever an authentication is made you check your table of authentication methods and find the one user it maps to.
Im not sure if you are doing this yourself or if the framework you are using is handling that, but it sounds like you need to change the model to allow many Auth methods for a single account.
Also you could use email, but that is also an "old" way of uniquely identifying users almost every single person has multiple active email accounts nowadays, so you should also have a one-to-many relation for users to emails. What if the user has different email accounts for their Facebook and Google accounts?
See account linking here: https://auth0.com/docs/users/user-account-linking
It is dangerous to trust that the external providers are truthful about what email belongs to who. What if I open a new account using someone else's email on one of the providers? Then I can log into that users account in your application, which is a pretty big security risk.
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.
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.)