Let's say my web app is acting on behalf of users who give their credentials to my app so the app can make API calls to a third party service. Incidentally, this is for posting product offers to this third party site (bit like eBay, but on a smaller scale).
Now one super convenient way to make this posting easy would be to reuse the sophisticated web form that third party service has to accept product offers for authenticated users. The idea is to populate their web form and redirect the client browser to it so the user can edit things there using the sophisticated and familiar web form. This would be the best user experience and the least implementation work.
However, it is not a documented way to do it. What's more, it doesn't work in the simple way, like populating the form fields from request parameters (GET or POST). The web form just doesn't work that way.
There might be an alternative. My app could open a session with the third party app on the user's behalf, submit all data so it is stored in their database, and then send the user's browser all the data it needs to take over the session that my server app opened on his behalf. Note that I haven't tried this yet; and I reckon it might fail if the third party app ties a session to an IP number (which, whether sound or not, an app might do).
So in other words, is it technically possible to pass a session from the server to the client?
Okay, giving up. What I want to do is not possible. The reason for this is the so-called same-origin policy to make browsers a safer place. See this other answer for some pointers. And it appears I was wrong on my assessment of the W3C working draft on Cross-Origin Resource Sharing, which is there to allow exceptions from the same-origin policy. So if this were widely implemented it might be viable. But overall there are too many ifs and uncertainties in this attempt.
The cookie and the session ID contained therein weren't needed after all. I've figured out how to obtain all the parameters needed for that request, and I'm providing them to the client by sending him an auto-submitting form:
<body onload="document.forms.submit()"> <form action="..." method="post"> ...
The client then enters his own session. Works great. As long as they don't change the interface. I set up tests to monitor their form and alert me to take action they change stuff in incompatible ways.