Integrating openID and oauth as website login, signin and authentication system

Question

First of all let me start by saying that this question is not about different openID and oAuth implementations. There are many classes about these.

My question is what to do after authenticating a user:

• How to add this user to the user table in the database?
• How to handle different logins for the same user? (Remy Sharp's example suggests something for openID)
• How to combine oAuth and openID in the database?

Any ideas?

Answer 1

Your question has to main parts to it:

1. Authentication
2. Authorization

Usually the two are not treated differently if the identity provider (IP) is your own, which has been the most common setup in web apps until now.

When using an OpenId Provider such as Google, the authentication part is seperated from your control. You will get a token back telling you if the user is authenticated or not. The token will normally contain the following claims: Name, Email and Named Identity where the last is the unique id of the identity at the IP.

So far so good.

The trick is now as you ask, how do I authorize this user?

well, there are a couple of approaches to this.

First off, when you create a local user in your system, you can prepopulate the Name and Email values based off the claims you get from the IP. In this process, you can start and say that all users that have a profile stored in your system are authorized, or you can develop further processes that will add whatever details you need to know about the user.

Then, how do you avoid that the user is not re-registered if they switch from google to facebook as the IP?

This is where things get tricky. The most common claim that Google, Yahoo, Facebook will provide to you is the email address and Name. So what you can do, is try to match the incomming claim with existing customers in your app. This is not failsafe however, as people can have different emails in different systems.

The name value is also not safe.

In our setup, we start by matching emails, as we know that most IPs validate email addresses. This will reduce duplicates a lot. After that check, we start our own validation process where the goal is to see if the person is already registered. This process looks for the customers mobile number in our database, and if a match is found, we send a one-time-password to the customer to verify correct ownership of the phone number.

Since login is a time sensitive setup, we are created a simple SQL table that maps external identities to our customer numbers. This allows us to implement this kind of validation logic outside all our web apps (and thereby reduce code redundancy)