Titus,

> Yep.  I imagine a link like this:
>
> Go to site B.
>
> Then when site B is entered, it knows (e.g. from the referrer URL) that
> you're coming from site A, and it knows that you're user $uuid.

Then Site B should make a web services call to Site A to check that the
user is currently logged on ok. This handles the case where the referrer
has been forged. Site B can then create it's own session cookie as
normal to confirm the user is logged onto site B.

Basically the user is doing a slightly special login to site B. Instead
of passing username and password it passes username and the id of the
site they are currently logged onto. Site B can then call that site to
check this is true instead of checking the password itself.

Note that you don't need to have synced passwords for this to work
(although I would suggest that your change password code does sync them).

You can also make it so that it works even if the user does not yet have
an account on site B bu creating them as needed. You would need to have
a web services API so that B can get all the details it needs from A to
create it's own user record.

Hope this helps.

Dave
--
Dave Warnock: http://42.blogs.warnock.me.uk