Best way to seamlessly & silently authenticate with a second webapp while logged in to a first?

Third party app (A) needs to link users to our app (B) and log them in behind the scenes.

Both apps work independently with their own auth systems. Users share a common unique ID, but have different authentication tokens (username/password/key etc) at each app.

The two complicating factors are as follows:

1. One app B user may associate with two app A users (e.g. both accounts at app B would redirect and login to the same app A account)
2. The app B user may not actually have any existing auth tokens, only their personal record and user ID, but we still want to be able to log them in if they are coming from app A.

My first thoughts were OAuth - but I don't think it will work as some users don't have app B accounts and thus won't be able to log in to grant app A access (see point 2 above).

The simplest way I have come up with is:

1. Each app has a pre-shared key e.g. "LOLS"
2. Common hash algo generates indepentent identical tokens e.g. hash(PSK + UID)
3. App B stores hashed tokens for each user
4. App A sends POST with UID and hashed token to App B, which uses it to identify and auth against a user

The problem with this is that it's hideously insecure. Anyone with knowledge of the pre-shared key (any system admin开发者_开发知识库) and a user's ID (once again, any system admin) would be able to authenticate as ANY user, which is unacceptable.

Does anyone have any solutions? I'd prefer existing standards but am open to customised implementations. We can't really do much to app B other than to get them to use whatever API we provide.

I've faced situation similar to this many times. There have been a variety of solutions we've explored, here's one of them.

You produce a webservice for them to call. This could be something you lock down however you like, including by limiting access to their IP address at the firewall. They post the UID to your webservice, which inserts into a table on your end and hands back some sort of random token (we randomly generated a guid). Your table associates the token with the UID (in plaintext) they sent and a datestamp.

Their application sends the random token to you instead of the UID, you use it to look up the UID, and use the timestamp to make sure the random tokens are expired after a minute or so. Even if someone looks through your table somehow to get the list of UID's recently attempted, it doesn't let them authenticate unless they can pull it off real fast!