What is the standard with oAuth for remembering users?

Question

Me and my colleagues developing an application (both web application and mobile app(iPhone & android)), which includes a login process. Currently, we have our own login mechanism (where users have signed for an account on our app, and have stored their info in our Database). We are looking into integrating oAuth and allowing users to login with Facebook, Twitter, LinkedIn and Google.

Now, when the users logs with any of those, as I understand the login process occurs outside our application and basically only get permission to access their resources.

My question is this: through oAuth, how do we remember users? i.e., users who login have read /write privileges and have preferences. How do we remember those when they don't actually sign up through our app.. Can we store their email address in our "Users" table??

What are the best practices in such a scenario?

Thanks for any info you can provide.

Shill

Answer 1

Having built authentication databases for a few different OAuth-enabled web sites, I can say that I've learned a few things that you should keep in mind.

1. You should have a table of users for your site that is completely independent of which OAuth provider they used for sign-up/sign-in. This enables your site users to combine multiple accounts together under their primary identity on your site. (For example, associate both Facebook and Twitter with you.)
2. When you let a user sign up, you should get an email address from them. Whether you ask Facebook for it, or if you have to ask directly. This enables you to "upgrade" users later from depending purely on third party OAuth to setting their own password on your site. (You simply send them a link to your password reset page in order to get them started creating their first password.)
3. You don't want to use email address as your primary key. I'm not sure if that's what you're actually describing or not, but you really want them to have a local user ID that you use for maintaining their session, etc. You then associate their Facebook ID or their Twitter ID with that local ID, and use the correspondence between such identifiers to match up which of your site's users to consider logged in.

Coomb

thanks for the feedback!! A few questions: -- Regarding point#1, is that intended for cases when users log in with different OAuth accounts (Facebook, Twitter, ...), but they are still linked and regarded as ONE actual account? -- Regarding point#2, what do you mean upgrade? Can you please clarify this use-case. -- Regarding point#3, is "local user ID" generated by the system/database or is it specified by the end user? – Shill

Also, how would you handle the following use-case: User X logs in through Facebook. I store his Facebook ID and link it to a local user ID. The next time, User X logs in through Twitter. How do I determine that it's the same person (that logged in earlier through Facebook) so that I can fetch his user preferences.. is that based on the email address (which might be common between his Facebook and Twitter accounts, or it might not be)?? Thanks for the help! – Shill

How would this work with Twitter since they don't provide the email? How is there any way to know whether the twitter user is the same as the facebook user without a unique identity like email? – Tubular

+1 for "You simply send them a link to your password reset page in order to get them started creating their first password" – Megara