I am using Google OpenID for login to my website. I am using it through Tornado's built-in auth library. I retrieve email ID, first name, last name and name from the openID data. My question is can I use email ID retrieved in this way to remain unique over time - including its case? For e.g. Is it possible that a user may have email ID John.Doe#gmail.com today, but in future it may be john.doe#gmail.com? I cannot find any other field in the returned OpenID data that I can assume unique for a given user.
Update Maybe I should also add that I was hosting my website on Google App Engine before and was using its built-in login. When I migrated to Tornado based implementation, I used email ID from the old logins as the unique identifier of the users. In most of the cases that seems to have work, but recently I ran into a case where the user's email ID returned from OpenID was different from his email ID from GAE version only in case. Therefore I am trying to understand how this can happen.
Since it's an email address, you shouldn't consider case, as for normal email case is unimportant. So, you should be able to consider that unique in a case insensitive test.
Related
I'm working on a web app where all users sign in using their Google account, using Google's OAuth2 API. I'm using ScribeJava to take care of the OAuth details.
I'm currently using the "sub" field of the user's ID token as their primary key in my database. When a new user logs in for the first time, their "sub" is stored for future logins.
I'm looking for a way for an administrator to add a user before they first log in - however, since I don't have the new user's "sub", I can't just add them to the database. Is there a way to use Google's API to look up another user's ID token (or at least the "sub" field) using their email address? Is there a better primary key that makes this easier?
Let me start by saying using the Sub id is probably a really good idea. However there is no way for you to get a users sub id from their email address. That information just isn't available until a user logs in as its part of the authentication Open Id connect claims.
Sorry but what you want to do isnt possible.
Maybe I am missing something here, or this is a flaw in Auth0? I'll give an example of my issue:
Let's say I have my Default App (client), hooked up to that I have Username-Password-Authentication (database connection) and google-oauth2 (social connection).
A user comes to my site, signs up via google-oauth2 (social connection) using joe#gmail.com. Once complete, he gets added to my users in Auth0, all great.
A few months later, Joe comes back to my site, and being a busy guy, he forgets he signed up to my site before. This time, he decides to sign up using my custom Email and Password form, that will add the user to the Username-Password-Authentication (database connection). so he signs up there using joe#gmail.com again, and everything goes well, he is now listed in my user's section in my Auth0 dashboard.
This is the problem, I now have two joe#gmail.com accounts, one with google-outh2 and one with Username-Password-Authentication. I really can't have this, I need a unique email address, regardless of the ID Auth0 supplies.
Does anyone know how I can make email address in my user section 100% unique? I'd think a rule would do this, but it appears rules only apply AFTER a user has been registered, so I can't run a rule before adding?
the only way I can see doing this right now is make my own checks and delete via the management API, but that is a really long and messy way to do it I feel.
Any help will be appreciated here!
Thanks!
Auth0's default behavior is to create a new account in the database for every unique entry. Since the user created using Google has a unique id (based on google-oauth2), and the user created using the sign-up form has a unique id - they will technically be considered two separate accounts. In order to resolve this disparity, you can establish a means with which the account data can be merged. In the documentation linked provided above, there are examples of three possible ways of doing this:
Automatic Linking - which involves creating a specific rule to merge users based on matching emails
User-Initiated Linking - which involves providing a UI for users to opt into merging users with matching emails
Suggested Account Linking - which involves setting up a rule that is linked into the UI
One important thing to consider is that the data returned from different social identity providers may not be normalized the way that data is normalized onto the Username-Password-Database. For example, while auth0's default for emails is to lowercase the information, google-oauth2 may return emails as Uppercased - creating the potential for non-matching emails when checks are made using strict equality
The option you are looking for is called account linking.
You can find more info at https://auth0.com/docs/link-accounts
The id I get from app.getUser() from the actions-on-google-nodejs app looks entirely different from the id I get from Oauth.
app.getUser() in Google Assistant
{ userId: 'KMdEs***szG-ZRQl***cU',
user_id: 'KMdEs***szG-ZRQl***cU',
userName:
{
[...]
The same id is returned with and without the app.SupportedPermissions.NAME permission.
googleUser.getBasicProfile().getId() in Google OAuth
11348***63489
Is there any way to match these users up? It's the same Google Project in the developer console, so I assume that even if Google would generate unique ID's per project it should be the same, however in this case it looks like I am getting entirely different types of id's.
They are different types of IDs.
The ID returned from app.getUser() is meant as an anonymous project-unique identifier that can be used in some of the same ways a web cookie is used. It can not be identified against a specific account - but it will be consistent across all sessions (unless reset by the user). The profile information you can get with it (their name) is also considered non-identifying. Both are intended to be used to make a more friendly interface, rather than as a firm identifier. Users are able to reset their Google Home devices, for example, and this may reset this to a different ID.
The ID returned through OAuth, however, is meant to link them to a Google Account, with all the implications that brings, including associating them with a specific identity. This Account Linking is done separately, and does not directly give you the ID - instead it gives you an OAuth Access Token (which you can get through app.getUser().accessToken) which you can use to get their Google ID and other information that you may be scoped to get.
In theory, if you have Account Linking enabled, you could match the two up. In practicality, if you have Account Linking enabled, you wouldn't care about app.getUser().userId since you have the Access Token which will get you their Google ID. If you do not have Account Linking enabled - there is no way to match up the two and you should treat the userId as an anonymous (but consistent) user.
In an ASP.NET MVC 4 application using the .NET 4.5 framework in conjunction with Azure Access Control Service (ACS), I want to provide the users multiple authentication possibilities (i.e. Google, Facebook, Windows Live, etc.). What is the "best practice" for associating a single user to multiple identity providers?
For example, say the user logs in with Google one day, then goes to another browser the next day and logs in with Facebook. How would I know to associate the Facebook login with the previous Google login to the same user?
Look no further than stackoverflow itself for a good example of this. Click your user profile and then select "my logins".
When a user creates their account, they select which identity provider you want to use to sign in. Under the hood, your application creates a new site-specific unique user ID, and links it with a 3rd party provided unique ID. (You might use email, but most identity providers will also provide a unique user ID claim that doesn't change, even if the user changes their email)
Now, after the user has signed in, they have an account management control panel through which they can establish additional links to other identity providers.
I see two options for achieving this:
Have your MVC application persist account links. When a user signs in, you query your account link store using the 3rd party unique ID claim and resolve your site specific unique user ID.
Use the ACS rules engine. You would create one rule per account link. For example, lets say I can sign in with either gmail or liveid and my unique id is 1234. Two rules look like this:
google + me#gmail.com --> output user ID claim 1234
liveId + me#live.com --> output user ID claim 1234
For the unique ID output claim type, you can pick from the available claim types or designate your own. ACS has an OData based management service which you can use to create these rules programmatically from your MVC application. Here's a code sample.
If you are using ACS, you can translate the information from each IdP (e.g. Gogle, Yahoo!, FB, etc) to a common handle using claims transformation on ACS. A common handle people use is the users e-mail. But if you want to accept many e-mails mapping to the same user, then you'd introduce your own unique id (as a claim) and map IdP supplied claims into it:
myemail#gmail.com (e-mail - Google) -> (UserId - YourApp) user_1234
myotheremail#yahoo.com (email - Yahoo!) -> (UserId - YourApp) user_1234
64746374613847349 (NameIdentifier - LiveId) -> (UserId - YourApp) user_1234
You can automate this through ACS API. You should also probably handle the first time user logs in into your site (e.g. asking user for an e-mail and sending a confirmation message that will trigger the mapping).
Presumably, you are using this information to retrieve data from a local database in your app, otherwise, you could just encode everything in claims and not worry about any equivalences. Claims are often a good place to encode common profile data. (e.g. Roles, etc)
I've discovered recently LightOpenID wich i'm going to use as a login system for all my next websites.
As i'm fetching some infos when users register/login with LighOpenID, I'd like to know if it's technically ok to use user's email as unique id in my USERS table or if it's a bad idea ?
Thanks guys ,
FX
Thinks to consider:
It isn't mandatory to have an e-mail account linked to your OpenID account.
If there is an e-mail address, you are not guaranteed to get it back from the server, even if you ask.
Even if you get the address, you'd still need to validate it (e.g., by sending an e-mail message with a random token).
Users will probably own more than one OpenID identifiers (you are in such situation as soon as you open accounts at some major services like Google or Yahoo). Some of them will share the same e-mail address, some will not, and some will not even have an e-mail address set.
When the user changes his e-mail address behind the scenes, he'll lose his account at your site.
Using the e-mail as key does not really offer any advantage I can think of.
My advice is that, if you want to use OpenID, you should do it right. Read the OpenID URL from $openid->identity() after successful validation and use that to identify the user.
Additionally:
Keep in mind that URLs can be long; don't try to stuff it into a VARCHAR(100) column.
You might want to implement linked identities as Stack Overflow does.
It depends on your service. Normally, every email-adress is only assigned to one person. If multiple accounts per user are not wanted, it's ok.
Some families have a family-email-adress. But I guess they would also use the same account.
Why don't you take the OpenID as the unique ID? OpenIDs are unique and you get the OpenID before you get the Email-Adress, if you use only OpenID for logging in.