1

I have my site 'A'. I will have a business contract with site 'B' to enable users of site 'B' (there will be many such sites) to redirect their users to my site when the users do one of many 'A' related actions on 'B'. I can mandate passing of whatever information from 'B' to 'A' directly or through the browser of the user of 'B', but I (ie site A) NEED to validate that they indeed came from 'B' and automatically log them in into site 'A'.

I KNOW that OAuth does this well - but ONLY at the "user" level. What's happening here is a business contract between site A and site B - and there is no need of inconveniencing every user of 'B' to do the whole OAuth hoop-jumping...

Please also note that site 'B' users will be presented with a FORM that they need to click on for those actions to be transmitted to my site 'A'. Whatever secret / authentication data (if any) is being communicated to the 'B' user can be seen (and tampered) by them. My site 'A' has to protect against that.

This is close: Securely Transferring Users Between Web Sites .

Options listed there:

  1. Write a web-service call over HTTPS, at both ends, to retrieve the users details, and that only works for a specific login-pair.
  2. Take a look at "Pass-through Authentication," its a concept that allows a user's identity to be passed from one system to another.
  3. The best thing I can think of right now is passing a HASH of the user ID, or if that makes you worry, the hash of some other user data.
  4. Site B could have a web-service that allows Site A to create a session for the user.

But I'm wondering if ppl have different opinions since the Q was asked a year and a half back.

My questions:

  1. How should i implement this?
  2. Any readymade php implementations which enable this?

[I've already implemented something like this which turned out to be a flawed mechanism, so I'm curious what the correct mechanism would be.]

Community
  • 1
  • 1
siliconpi
  • 8,105
  • 18
  • 69
  • 107

2 Answers2

0

You could use a single-sign-on system like Shibboleth.

The Shibboleth System is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.

If that's overkill for you, simply grant both sites access to each other site's user data through a HTTPS API via a random hash unique for each user which is simply passed when clicking "the button".

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
0

What is the security level of these sites (i.e banking vs blogs)? For really simple cases the site B can cache the FORM data CHECKSUM. And when user is redirected to A, then A can query B directly for the checksum and validate the data. IP or key-based authentication between the sites can be set up for added security.

If you require more security, perhaps OAuth is still the best option. Keep in mind that the users are already logged in to B, so that they will not need to enter anything. And the form they submit, could actually set up OAuth at the same time, so that when user is redirected to A, A actually gets the Token and then can retrieve data from B over OAuth (thus validating that data came from B).

In addition to already mentioned Shibboleth, there is a compatible standard SAML 2.0 which might interest you and a very good PHP implementation of both of these protocols SimpleSAMLphp which comes as ready made web service as well as libraries to be used for custom applications. Learning curve of setting up such a SSO federation was not too steep and the SimpleSAMLphp is pretty well docmented.

But as such an SSO requires SAML/Shibboleth by all of the B-s and setting up and maintaining the federation metadata between the parties, OAuth might still be better choice for you.

Laas
  • 5,978
  • 33
  • 52