From your question it sounds like you are trying to pass sensitive data through Server B, but B is not the final destination. Even if B is the destination (or the source), the answer is still the same
The way to do this is with HTTPS/TLS/SSL. This will encrypt the data using A's public certificate, such that the data can only be decrypted by A's private key, which only A has.
This also provides the added benefit of verifying A's identity to the client. A provides a certificate which is signed with A's private key. Only A's public key will decrypt it properly, thus proving that only A could have generated that certificate (or someone stole it, but we assume this isn't the case).
EDIT:
To do this by having B serve the page but not be able to read it's data, have the web page served by B encrypt the data using Javascript on the client side, with A's public key (which can be included in the page by B). Even though B has A's public key, it will not be able to decrypt the data encrypted by the JS. It can only pass it on to A.
EDIT:
As long as all encryption is done on the client side using A's public key, the data will be unreadable by any parties other than A, because only A's private key will be able to decrypt it. With this method you can have as many intermediaries as you want without risk.*
*This of course assumes an RSA key pair with sufficient entropy and length as to be considered secure. A minimum of 1024-bit, preferably 2048-bit.
Yet Another (and final) EDIT: 09-May-2013
Sorry about the many edits, but your question has been confusing for me. I think I understand now what you are asking.
In my previous posts I made a significant assumption, and that is that Server B is trusted not to make a malicious attempt to harvest your user's credentials. I made this assumption because, as halfer alluded to in the comments, it is very unwise and unsafe to allow B to collect your user's credentials, if B is of limited trustworthiness in the first place. Additionally, I made this assumption because it is a common task to use third parties to host your web app, such as Heroku, Amazon, etc., who would not be malicious (they would lose a ton of business if they did, and they have little to nothing to gain. Also, you have someone to hold accountable if you detect security violations. Thus they can be trusted, or you wouldn't be using them in the first place). I will now assume that you are not using a third party source like them, since it seems apparent that that is the case.
If B could potentially be malicious, then no matter what you do with your client side code, B could change it and intercept the credentials. As long as B could be trusted not to modify your client side code, then my previous suggestion would work. However, given this new information that B is of limited trustworthiness, it would be unwise to implement my previous suggestion.
Authenticating a user to your service through an untrusted third party is a very dangerous endeavor, as indicated by the amount of money that PayPal has spent building an API. However, if you must do this, then you will need to be very careful, and consider implementing a solution similar to PayPal.
If you have to go through the third party, then a solution similar to what @halfer mentioned in the comment above is the way to go, IMO.
[P]erhaps you should click on something in B, it redirects to A, gets
user permission from your site, and redirects back to B with an
authentication token. That has the benefit that you're not encouraging
the user to enter their main password in a site they should not
absolutely trust.
Have the user redirected to your site using HTTPS/TLS/SSL. This protects the user's credentials and also verifies your identity to the user so they're less likely to fall for a pharming attack. You can then provide a sufficiently random token to the third party to use as authentication.
Please understand however, that even with this solution there is still significant risk. If B wants to attack your users, B could still easily trick a percentage of them by simply asking them for their login credentials directly. This would probably work against the majority of them, who aren't security savvy.
If B is not trusted, then my professional advice is don't do this.
