We currently own siteA.com and have a pretty big user base.

We are now planning to introduce siteB.com and siteC.com into the mix. Since we want to end up with a "network of sites" and make things easy for the users, login credentials on siteA should work on siteB and siteC and so on.

Essentially, one login should work across all sites. If someone registers on siteC, he should be able to use the same credentials on siteA and siteB.

Since we are not ubiquitous like Google or Facebook, it is not apparent that one set of login credentials will work across all sites.

What sort of affordance can we communicate to the user during registration and login that one set of login credentials will work across all sites?

It needs to be a flexible solution as it is possible that we will introduce siteD, siteE, etc in the future.

  • 3
    I would take a leaf from how StackExchange does this :)
    – Amicable
    Nov 28, 2013 at 10:16

7 Answers 7


Dealing with usernames and passwords is a hurdle every user wants to get over as fast as possible to gain access to the thing he actually wants to use. So - in the first place - try prevent him from having to log out and in on every site.

In any case you will need some sort of icon, logo, navigation bar, login-procedure etc. with total uniqueness (in your domain) transporting your need in an unobtrusive manner so the user can focus on using your product or site. And your solution should behave and visually display redundant on every site.

My suggestion on this would be a fixed banner across the top of every webpage related to your service. It would always show the names overall service (as does "StackExchange" for *.stackexchange.com), some sort of icon visualizing this, the username, a list of the other sites related to your service and the name of the service which is in use at the moment. In that way your user can

  • switch sites using the same login credentials without having to deal with login-pages
  • be aware of your other sites/services and
  • be aware of the feature not having to log out and in again when changing services.

Don't forget to remind user at some stage (best would be during input of data) that he is using the same credentials for a different service.

  • +1 Yes, but not needing to log out doesn't mean it shouldn't be allowed. I might after all not want to use the same credentials on all sites... Also, even when using the same account on all sites, display names should be allowed to differ across sites - just like on the stackexchange network. Using the exact same profile content across all sites should however be made easy to do (like the button to save and copy on your stackexchange network profile). Nov 28, 2013 at 10:34
  • Something as in hot swapping profiles when logged in @MarjanVenema? If this is intended by the service provider and content and context allow so, sure why not.
    – uxfelix
    Nov 28, 2013 at 10:50
  • 1
    Nothing as sophisticated as that. Just that the first time you go to one of these other sites and are recognized as being logged in, you get a chance to either create a profile and link it, or create different credentials for that site. And with regard to the profile info: simply should be site specific (ie displayname and bio etc can be tailored to the site) with a simple option to copy whatever you entered/changed to all sites in the network that to which you have linked your credentials Nov 28, 2013 at 11:00
  • "as does "StackExchange" for *.stackexchange.com" - Except that StackExchange does not share credentials across multiple sites, it uses OpenID. Nov 28, 2013 at 11:56
  • @MarjanVenema "site-specific" profiles with the ability to link them to each other or copy content between them. Nice!
    – uxfelix
    Nov 28, 2013 at 12:28

More of a technical comment, but: The correct way of doing this would be do have a button similar to "Sign in with SiteA," and redirect to SiteA for login using OpenID or OAuth.

There are several reasons for this:

  • Security. If I go to SiteB and they ask me for my SiteA credentials, my immediate reaction is "Phishing Site, abort abort"! Even if it's obvious to you that SiteB is owned by SiteA, it won't be to everyone else.

  • Convenience. Requiring the users to log into a single domain means they only have to log in once at SiteA, and when they visit SiteB they can be automatically logged in.

    This is what stackexchange does.

  • Password Managers. Many users (including myself) use a password manager like LastPass, which stores passwords on a per-domain basis. Requiring me to use my SiteA credentials at SiteB means that I need to go track down my SiteA credentials every time I visit SiteB.

  • I love the OpenID principal. Way more sites should act as relying parties. Problem here is the acceptance of using this third-person authentication system. visit site > identify my self > use is an easier mental model to build as when having a third party involved.
    – uxfelix
    Nov 28, 2013 at 12:41
  • @uxfelix: There is no third-party here. SiteA is your OpenID auth-server. Nov 28, 2013 at 12:42
  • I'm not to familiar with the OpenID structure, but wouldn't new users returning to SiteA or SiteB with cleared cache and deleted cookies be forced to use OpenID, a new authentication method they are not familiar with?
    – uxfelix
    Nov 28, 2013 at 12:49
  • 1
    Personally I find the StackExchange mechanism is a really crappy user experience. The starting point (a separate account on every *.stackexchange.com) means a bunch of crappy hacks, like the "click to refresh the page" workaround you include. It'd be much cleaner if they all just shared one set of credentials to begin with, so you had proper single sign-on across the network. Dec 4, 2013 at 2:47
  • @SteveBennett: You think requiring the user to go to a login page and re-enter their credentials for every separate stackexchange site is a better user experience than being automatically logged in and having to click one button? Jun 6, 2015 at 16:34

The first thing that came to my mind when I read your question is the Single Sign-On system. You might want to read the article in Wikipedia for more information.

Please also see this link (excerpt below).

LDAP Authentication And Single Sign On

Single Sign On (SSO) systems mostly use LDAP authentication. The enterprise user logs on in the morning and sees normally a form based enterprise login screen. The user enters in their id and password. The SSO software then takes the information and sends it to the security server using an encrypted connection. The security server in turn then logs on to the LDAP server on behalf of the user by providing the LDAP server with the user's id and password. If successful, the security server then proceeds with any authorization and/or lets the user proceed to the application or resource they require.

I have already deployed systems using SSO. This works perfectly for me and I think this will also be useful to you.

  • 2
    Nice answer, but it applies to implementation and not the usability, per the original OP question.
    – Izhaki
    Nov 28, 2013 at 11:23

It is not an easy question because it is very unusual to have the same login information between many websites.

One solution would be to create a brand new and strong identity for this login module. So the user will think "Hey, I know this super-login-module, i have seen it before".

But If you really want to make it easy for the user, I think the best solutions is to have facebook/google-connect module installed on each site.


At our company (Colruyt Group) we are actually using the same system, but without any clear messages. I think 1 account is usable over 6 websites with individual corporate indentities.

I don't prefer this method, it's not so clear for our customers, and on average they have 3-4 accounts. Which is a "polution" of our database. Within our company I launched the following proposition (simplified below) which resembles what UxFelix said..

enter image description here

And I follow Renaud, you should create 1 uniform looking login system. So that users are aware they've seen it before.


Yet another confirmation supporting my opinion that username must die.

Having simple and clean Email/Password login would solve the problem.

Merge user databases and you are done!


There are three solutions here:

  1. Communicate the ability in a dialog. This introduces maintenance issues if you add more sites
  2. Use a shared login service so that is the user logged in on siteA, they dont need to login again on siteB. eg, OpenID, Facebook connect, google api or your own concoction.
  3. Use brand identity to communicate the cohesive nature of your services. This is a very subtle and powerful tool. You could brand your login system (OpenID, Google ID, Mozilla Persona, etc) or you could simply brand your domain collection (like the stackexchange network).

Option 3 can (and probably should) include option 1.

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.