You could use a web service to handle a background authentication "handshake" between the two systems.
Background handshake:
- User is authenticated on site A and wishes to go to site B.
- Site A calls the web service on site B, passing the user's credentials.
- Web service on site B verifies the user's credentials, and creates a token (perhaps a GUID) which it puts somewhere semi-permanent. You can't use the session, because that's user specific. The data could certainly go into a database or into a application scope collection (perhaps the web cache). It would probably also be important to include a short duration timestamp with the token to allow only a short window for transfer. This interaction is happening server-to-server so a user can't see any sensitive data.
The handoff:
- Site A gets back the token from site B's web service.
- Site A redirects the browser to Site B, passing the token in the URL.
- Site B validates the token against it's "active tokens" list to verify a legitimate handoff.
- Site B automatically logs the user on using the credentials stored with the original token at site B.
Now granted, this still doesn't get us around the problem of taking a handoff URL and using it elsewhere (apart from the limited time window of handoff). But I think that short of reverse engineering how Microsoft Passport/Live (or whatever they are calling it these days) works, you have to sacrifice some security for convenience.
An easier way of at least protecting the sensitive information from being easily harvested off the querystring is to put it into a form and post it to the other site.
-
Peter