Given two companies managing two separate websites, the client wants the user to be able to log in to one website, and then click a link to navigate to a certain part of the second website. The client wants to eliminate the need to log in a second time upon arriving on the second website.

I'm thinking the solution is

  1. Rather than linking directly to the second website, link to a redirect page within the first site.
  2. The redirect page would generate a random string, and notify the second website what the random string is, and which user ID and IP address it is for.
  3. The user would be redirected to the second website with the random string included in the URL.
  4. The second website would check the random string + IP + date/time.
  5. Once validated, the second website would initialize a login session giving the user appropriate access.

Caveats I am aware of are

  • The second website's security is limited to that of the first website.
  • If the user logs out of one site, they would not automatically be logged out of the other one.

So my question is

  1. Is this solution a good one, would it be secure if properly implemented?
  2. Is there another obvious/better solution I should be reviewing?
  3. Please let me know if there are any other caveats I should know of, or things to watch out for during implementation.

1 Answer 1


Using something like oauth would probably be easier and safer. The main issue with it is that you can't use the user password for user level encryption, but if that isn't needed by the site the user isn't logging in to directly, then you are fine.

You have the basic idea right, in that you want the one server to be responsible for the login and the other to trust that server, but I would suggest that you want a system that relies on trusted communication between the two servers rather than a string to validate the session. That's basically the idea with oauth, where the one system has the other system process the login and return a validation that the user authenticated. You could hide the oauth process because the user is already logged in to the site that will validate their identity, so it could be done behind the scenes.

  • "a system that relies on trusted communication between the two servers rather than a string to validate the session" Well, the system I outline does rely on trusted communication between the two servers (notify the second website, is done server to server), the random string is used to identify the user, since the cookie cannot be accessed by the second website, the string in the URL is used instead. If you have a better idea, then please clarify? Jan 6, 2014 at 14:57
  • 1
    "Using something like oauth would probably be easier and safer." Can you outline how that would work, how it would be better or different from what I proposed? That way I know I'm on the same page. Jan 6, 2014 at 14:59
  • 1
    @GeorgeBailey - ok, that's fairly close to oauth then but flipped around. In oauth, the system that want's to use the other's authentication provides a redirect with an identifier, the client then authenticates with the service providing the authentication and the service that provides the authentication then communicates with the other service that the user is who they claim to be. Read up on OAuth, it is the standard you want for this. You can actually also see how oauth works by looking at the signons for SE. Jan 6, 2014 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .