A co-worker asked me an interesting question. What would be necessary to introduce a single sign-on for multiple existing properties?

Seem like a straight forward questions, but then I started thinking about it and more questions came to mind. Well, what is you primary key? So I answered myself with email address. So, ok, I'm off to a good start, what's next.

What data exists? None, ok, well that's a problem. How do I convince users to give there information again? Not as easy, would probably be best to give them an option to port their existing data from the site they are currently using.

Ok, so now I have the data from one site, how do I get it to work with data from another site. I'll have to match up the fields. Crap, none of the fields match up and all the data is different. This means a large scale data mapping exercise. Now I'm really in trouble, because I have some idea what to expect and the last time I went through an exercise like this I had to bring eye drops to work for reviewing all the data. We'll also have to develop some kind of middle-ware that translate fields from app to app. Now this is starting to get complicated.

That was my though process and when I realized this is not going to be an easy question to answer. So I thought it was time to ask the heavy hitters and see if anyone has any experience with such a thing.

So this is my question, what is the best method(s) for creating a single sign on for multiple existing sites, each with their own unique data fields and sign on credentials? A follow up question for the really brave few would be how do you attempt the same without forcing the users to re-enter their account information?

3 Answers 3


OAUTH has become an industry standard for federated signon systems. Google and Facebook both implement the protocol. When you signon to stackexchange with Google, that is OAUTH under the covers.

As a web developer, you can either implement an OAUTH server yourself, which federates to each of your other sites, or another option is implementing Google, Facebook, or any of the other signon providers. In which case, the provider does most of the heavy lifting for you and gives you a token representing a signed in user.


Your case is all about a third party identity provider. It does all the things above and more. You don't have to worry, at all.

My banks (I have more than one) provide a Bank-ID valid for my both banks and a number of official state controlled sites. I can use my Bank-ID to sign in almost anywhere without creating an account, with the boring sign-up process, getting an actual mail by the postman, opening a skewed letter and signing in with a hard to see PIN-code. No I just use my third party provider Bank-ID.

But you can use Facebook, Google, Twitter or any other third party provider to accomplish this effect. Don't invent the wheel again unless you're making a world wide accepted third party identity provider by your own...

  • Is there a similar service that handles B2B solutions?
    – Johnny UX
    Commented Aug 6, 2014 at 15:04

The option with the least amount of work is using a third party. Google, Facebook etc. There are pros and cons to this, but from a UX perspective, this is probably the easiest and most trustworthy.

Stack Exchange does this well. You can simply create a new account on any SE site and it links your accounts. They target an identifier, in their case, it's an email address.

Unfortunately, all options are going to require some data handling. Your databases won't match and you'll need to map it accordingly.

The trick is to make the process seamless.

  • I think it's the data handling that I am most leery of. Is there a way to streamline the process? I guess I need to back up a bit. I've done this before and it was a very time intensive process and it was for one site. The biggest issue we ran into was the fields not being labeled properly so we different fields for the same value type. The scale I'm looking at is much larger.
    – Johnny UX
    Commented Aug 6, 2014 at 15:03
  • No idea without seeing your code. Commented Aug 6, 2014 at 17:03
  • It's all theoretical at this point. I'm curious to learn any potential pitfalls.
    – Johnny UX
    Commented Aug 6, 2014 at 18:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.