If I were to run a service that allowed users to authenticate via “local” username/password combinations and ALSO any number of OAuth services – what might that user data model look like?
Usually, if I were handling all logins myself, in the “user” database (assuming MySQL), the username and password fields would be required as non-null. But, if my users just wanted to log in with Facebook, I’d just store the Facebook auto token, and not have any username/password locally.
Further, what if they want to log in with Twitter creds, and then tumblr, and then whatever service-of-the-day? I could keep a field for each type, but that might get a little unwieldy. Would I be better off keeping another table of “authentication methods” for lack of a better term, so I could have a one-to-many relationship between users and how authenticate them?
Basically, I’m asking if anyone knows of an industry standard best practice for this scenario, or can point me in the right direction (or if someone has implemented something like this that works well for them). One user, multiple methods of authenticating – what’s the best way to hold that info?
If any of the assumptions I’ve made are invalid, I apologize, please correct me.
I have no idea if my solution comes close to any sort of industry standard but I’ve done this in several apps before.
Identity within your application should be abstract from the authentication source.
What I ended up setting up is something like this:
[ For further normalization, make service its own table with service meta fields. ]
User table: id int username varchar email varchar password varchar Authentication profile table: user_id int service enum('website','google','facebook') token varchar
Then your auth script does something like this:
- Look for username / email
- Identify known authentication profiles
- See if the input validates for any known authentication profiles and auth, or return invalid credentials
In cases of some services, you will either need to autogenerate some of the user field values, or prompt the user to enter during the first authentication, depending on what sort of data is available to you from the service.
I think what you want is a local authentication system (possibly for legacy reasons?) as well as support for users logging in using delegated authentication. The standard for delegated auth is OpenID. You might want to look at OpenID consumer libraries and samples, which should give you an idea of storing OpenID credentials. Unfortunately Facebook and Twitter do not support OpenID, but the flow is pretty much same, i.e. your data model will not change. We have implemented an OpenID consumer to support OpenID based login and registration. In order to support the local authentication, we have used an OpenID provider. In other words, we are both a consumer and a provider. That way, even the local auth system is standards based. Now to answer your question about schema – We have the source (local, twitter, facebook, google, yahoo, AOL) and the email as a composite key, along with the token and/or password in the authentication table. We let users change their display names, and have a unique vanity URL which is also a part of this schema. Users have an option to set up a password when coming in through OpenID, as for Mobile they’d need a password (not a whole lot of OpenID support on mobile). OAuth solves a little different use case where you’re dealing with authorization more than authentication. Does this help? If you have any questions feel free to comment and I’d be glad to provide more details – I just do not want to confuse you with too much information at this point.