7

What is the best/proper technique to share login between two sites.

I have website A, and some websites B. Both types belong to the same company, but B is running on the customer premises. What I would like, is that users login in B, and when redirected to A for some reason, they don't need to login again, and they can work with their account in A.

Of course, the company will make logins for each 'B' user. The problem is that the user could initiate the login in A or B.

Would OAuth do? Or OpenID would be more suitable?

Another option is pass a GUID token in the GET string, with a sort time to live and only valid for the IP address of the requester, but it is not sure the user would access the web sites through the same gateway.

Thanks

vtortola
  • 34,709
  • 29
  • 161
  • 263
  • your use case is typical SSO Scenarios which has been discussed over many posts on this site but exact solution for each post depends upon number of factors: what is your application framework, what is architecture of your deployment, language you prefer etc....one of post I can point you to [link](http://stackoverflow.com/questions/6002519/simple-sso-using-custom-authentication-cas-or-some-oauth-or-openid-server/6054485#6054485) – ag112 Jul 29 '11 at 05:43

2 Answers2

10

OAuth is exactly what you need. OpenID offers discovery which is only useful when the user gets to choose who to authenticate with (not your use case). Also, OpenID is much more complicated and is a dying protocol.

In your scenario, Server A is the OAuth server (or authorization server in OAuth 2.0) and Server B is the client. There are many ways to implement this, but I would suggest you start by looking (and trying) how Facebook OAuth 2.0 implementation works. It will give you a good idea of what is involved and some of their extension (e.g. display) which make it more user-friendly.

Eran Hammer
  • 7,036
  • 3
  • 31
  • 23
  • "OpenID is a dying protocol". Any support for this claim? – André Caron Aug 01 '11 at 20:23
  • @andre OpenID has not seen any major adoption for 3 years, the organization behind it is completely dysfunctional with its most active members (and some founders) no longer involved. Basically, OpenID is so unusable that most sites opt to use Facebook and Twitter (and sometimes Google) and just connect directly to them. – Eran Hammer Aug 01 '11 at 21:49
  • @vtortola Depends what you are looking for. Given the significant usability issues around OpenID, most developers pick the more relevant identity providers they can (e.g. Facebook, Twitter, Google, etc.) and just use those. Once you don't need to support more, OAuth becomes a much simpler and better choice. – Eran Hammer Aug 01 '11 at 21:50
  • @Eran: The OpenID website claims to have [over 1 billion OpenID enabled accounts](http://openid.net/get-an-openid/what-is-openid/). I consider that major adoption. Moreover, most problems people experience is related to support of all identity providers simultaneously. If you implement your own provider for a custom SSO solution and only have 1 provider to support, I doubt you'll run into the same problems. – André Caron Aug 01 '11 at 22:12
  • @andre That's a lot of marketing. Of course, if you count every Yahoo, AOL, and Google account (and in some messed-up ways Microsoft and Facebook), you can claim these numbers. But in reality, it is better to connect directly to the specific providers you are going to support. Once you move away from letting people type their OpenID URI and instead click a button, Open ID lose *all* its value compared to OAuth. OpenID is very hard to implement correctly and even harder to implement securely. – Eran Hammer Aug 01 '11 at 22:38
  • what if don't want to use facebook or github or similar? Instead my own custom login – dragonalvaro Jan 25 '17 at 15:10
3

You are talking about single sign-on. Does the company who owns Website A provide remote sign-on in their api?

You need to make sure that the log-on information is encrypted when it is passed to website A. The last single sign-on I built required me to pass the user's AD name encrytped via RSA and hashed with MD5. The third party had a database of the user's AD name and their password to the third party site. When the user clicked a link, their encrypted information was sent to the log-on api of the third party and the third party redirected them to the welcome page with the log on process complete.

If you are building a single sign-on API yourself, as in you have control over website A, OAuth is a respectable choice. It is fairly easy to impliment.

Ryan Bennett
  • 3,404
  • 19
  • 32