Question: I have a user on website A and I need to log him to website B (not under my control) but without jeopardizing his password on website B. Website B doesn't have an API which is what's making this more complicated than should be. 

My first option is to render my own form on website A, user enters his website B password into my form, and I somehow securely pass his website B password to website B to log him in. This means I have to first pass the password securely from the client to my server, then pass it again securely from my server to the end website. That's what I'm guessing I have to do, but I don't have a plan for how to implement these 2 hops securely, so I worry that I might expose the user's password somehow.

So I thought of the second option which is to render the same website B from website B onto my website. But the form on website B is part of a larger page, so can this be done?

* How would I isolate the code for the form itself from the code for the full page
* how to present the form on my website. I want the user to see it. iframe comes to mind but never worked with it
* will the form still be valid when the user clicks the submit button or does rendering the form on my website somehow invalidates it

These are the 2 different solutions I thought of. I welcome answers for each of them, and also welcome answers that suggest an alternate third approach that may be easier.

Answer: 
I'll try to outline a solution, but it may not be correct, or even what you wanted and it definitely is impractical.

From what I know about XSRF if the destination site did its homework you will not be able to mimic a form submit from your domain.

The only one that has access to the user credentials, apart from the target site, is the browser. So what you actually need to do is *become a browser*. This means that you must convince the user that he can hand you his login information to the other site. I have no idea how you can do that, I for one wouldn't trust something like that. (Another option would be to trick him (phishing), but that is illegal and I don't think you would even consider it.)

After you manage to convince the user to give you his data you'll still have to act like a browser. You'll have to implement a system for storing cookies for each user so that a session can be created when you log in.

After doing so you will be logged in with the user's data, **but the user won't be**. So you will need to implement any other operation the user would need through your site as well.

---

**What I recommend:**

Either contact the destination site and set up a protocol that you can use to authenticate the user from your site. There are some really cool iframe techniques to do that. Read this article for a competent presentation <http://softwareas.com/cross-domain-communication-with-iframes> .

Or make the user open a popup with the login page to that site. Make sure the popup has the address bar visible.
**See: [Sockets](http://php.net/manual/en/book.sockets.php)**

1. Study SiteB's login form HTML to gather a list of field names, expected values, and action url.
2. Remake the form on your own site, using same field names. Action url should point to a handling script on your own server. A caveat at this point is if Site B uses some special token field or cookie set when their login form page loads. If that's the case, use sockets to connect to and get a new copy of Site B's login page. You'll need to know [HTTP message standards and proper request body structure](http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html) to pull this off. Then, parse the retrieved text for the token field or cookie names and values to be used on your own page.
3. User inputs their username and password for Site B on your form. On submit, form results are passed to your handler script.
4. Your handler script uses Sockets to connect to Site B's action url target as a regular POST request. This POST request includes any cookies and token names/values Site B gave it in the previous few steps. You'll need to follow HTTP protocol message structure guidelines again to pull this off.
5. Site B authenticates using your user's info. Your handler script is sitting there waiting for a response.
6. Site B responds to handler script. You'll need to study typical responses Site B returns to know how to parse any response text (and again learn how to parse HTTP messages), including returned cookie headers.
7. Your handler script needs to keep a log somewhere matching the user with any cookie values returned after successful authentication by Site B. On any future requests to Site B, use sockets again to mascaraed as the user, passing the cookie header/val used to ID their (IE: *your*) login session to Site B.

Keep in mind you may want to keep an open and honest dialog about what you're doing with Site B, or you could be [liable for civil action](http://bits.blogs.nytimes.com/2009/01/02/facebook-sues-powercom/).