问题
We're considering an authentication system for a very temporary website that needs to authenticate from another site. To sum it up here, we have two sites on completely different domains. foo.com is the main site that will always exist (and already does). This is the main place where users go and log into that site, and do things in their logged in state there. That site will get modified soon to have a link to bar.com. When a user that's logged in on foo.com clicks the link to bar.com they need to be magically logged into bar.com. (I know this sounds like a security nightmare but bar.com is just a temporary site for a short window that people on foo.com will be using for a day or two). We are not allowed to log people in on bar.com, it must all happen on foo.com. We've tried to figure out solutions here and want some more if there are any good ones. He are ours:
On bar.com, check the referrer, if its foo.com, make the user logged in. This is very insecure and can easily be spoofed. We know.
When logged in on foo.com, have the link to bar.com have a special encrypted query string that represents the user's session on foo.com. When the link is clicked to bar.com, have bar.com take that query string and use a web service to pass it back to foo.com, for which foo.com will respond whether or not that's a legit session or not. This is more secure than 1 above because the query string session info is encrypted and the web service call makes sure its a legit session.
Are there any other options here? Let me re-iterate that we'd like a good solution that's more secure that 1 above but this is for a temporary site that only certain people will have access to. We understand it sounds like an odd arrangement but its for a very specific site that will have a short life for a specific purpose. Per requirements, we need users to log into only the originating site. Thanks in advance for any tips or pointers on this.
回答1:
I would venture to say that option 2 is your best bet, given that:
- foo.com holds the originating session information
- foo.com has a secured service exposed for an authenticated call that can be made from bar.com for verification purposes
- bar.com is passed a token that contains some form of authentication token
- the token is then passed off to a secured call back to foo.com using predetermined credentials that only are authentic to a connection between foo.com & bar.com
Good example of SSO (Single Sign-On) across domains: Part 1 & Part 2
回答2:
I think the second option is a good solution, you could even do without the web service: Make the link to bar.com include query parameters containing the username (or whatever context you need for the user), a nonce (e.g. a random number), and an authentication code (e.g. a HMAC or a digital signature) of a concatenation of the username, the user’s IP address, and the nonce. Then, you do not need to communicate between the two servers, you only need to preshare the verification data (HMAC key/signature-verification public key), and you can verify the information directly on the second server (keeping note of once-used nonces to prevent replay attacks, however they are probably not a great concern in your scenario, I guess).
来源：https://stackoverflow.com/questions/4961291/cross-site-authentication-options-on-separate-domains