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.
The scenario you are describing can be tricky to impossible. The main problem you are facing is about how you post the login credentials to site B in such a way that the cookies returned by the successful login itself end up in the user's browser and belong to site B, so that site B gets them when the user actually navigates there. 

A couple of people have suggested to have the form posted to a PHP file on your server and let that do the login from server to server. This solution almost never works. Even if site B accepts your server-server login (which it probably will, as you can fake any browser you want), it will be **your** webserver which will be getting the new cookies, and **your** webserver's IP which the session will be associated with. Even if you return the cookie to the browser, it will save it for **your** site (site A) and won't submit it to site B when the browser gets there, so the user will stay logged out of site B. 

So, the only thing you can do here is to host a login form for their site on your server. This means that you will have to send out a form to the browser which has an ACTION that points to site B's login form. This also means that whenever the user clicks the login button, the control is transferred to site B: the user will be navigating away from your site and you lose him. 

There are 2 major technical problems with this second method: one is that site B might have XSS prevention and may actually block you from posting stuff to their login page. The other problem is that if your site is on SSL, browsers will be nagging big time for you submitting a form to a different website. None of these is something you can solve yourself. 

The only clean solution would be to really sit down with site B and make some plan about a common authentication, or at least an authentication API. You can try the form crossposting solution but chances are good that you'll have problems with it you don't like.