あなたの質問から、機密データをサーバー B に渡そうとしているように聞こえますが、B は最終的な宛先ではありません。Bが宛先（またはソース）であっても、答えは同じです
これを行う方法は、HTTPS/TLS/SSL を使用することです。これにより、A の公開証明書を使用してデータが暗号化され、A だけが持つ A の秘密鍵によってのみデータを復号化できるようになります。
これにより、A の ID をクライアントに確認できるという追加の利点も得られます。A は、A の秘密鍵で署名された証明書を提供します。A の公開鍵だけがそれを適切に復号化し、A だけがその証明書を生成できた (または誰かがそれを盗んだが、そうではないと仮定します) ことを証明します。
編集：
B がページを提供するが、そのデータを読み取れないようにすることでこれを行うには、B が提供する Web ページに、A の公開鍵 (B がページに含めることができる) を使用して、クライアント側で Javascript を使用してデータを暗号化します。 . B は A の公開鍵を持っていても、JS によって暗号化されたデータを復号化することはできません。Aにのみ渡すことができます。
編集：
すべての暗号化がクライアント側で A の公開鍵を使用して行われている限り、A の秘密鍵だけがデータを復号化できるため、A 以外の当事者はデータを読み取ることができません。この方法を使用すると、リスクなしで必要な数の仲介者を持つことができます.*
*もちろん、これは安全と見なされる十分なエントロピーと長さを持つ RSA キー ペアを前提としています。最小 1024 ビット、できれば 2048 ビット。
さらに別の（そして最終的な）編集：2013年5月9日
多くの編集について申し訳ありませんが、あなたの質問は私にとって混乱を招きました. 私はあなたが求めていることを今理解していると思います。
以前の投稿で、サーバー B は、ユーザーの資格情報を収集する悪意のある試みを行わないと信頼されているという重要な仮定を立てました。私がこの仮定をしたのは、コメントでハーフがほのめかしたように、そもそも B の信頼性が限られている場合、B がユーザーの資格情報を収集できるようにすることは非常に賢明でなく、安全ではないからです。さらに、Heroku、Amazon などの悪意のないサード パーティを使用して Web アプリをホストするのは一般的なタスクであるため、この仮定を立てました (悪意のある場合、彼らは大量のビジネスを失い、彼らはまた、セキュリティ違反を検出した場合に責任を負う人がいるため、信頼できるか、そもそも使用しないでしょう)。私は今、あなたがそうではないと仮定します彼らのようなサードパーティの情報源を使用してください。
B が悪意のある可能性がある場合、クライアント側のコードで何を行っても、B はそれを変更して資格情報を傍受する可能性があります。B がクライアント側のコードを変更しないと信頼できる限り、私の以前の提案は機能します。ただし、B の信頼性が限られているというこの新しい情報を考えると、以前の提案を実行するのは賢明ではありません。
PayPal が API の構築に費やした金額が示すように、信頼されていないサード パーティを介してサービスに対してユーザーを認証することは、非常に危険な試みです。ただし、これを行う必要がある場合は、慎重に行う必要があり、PayPal に似たソリューションの実装を検討する必要があります。
サードパーティを経由する必要がある場合は、上記のコメントで @halfer が言及したのと同様の解決策が IMO です。
[おそらく]B で何かをクリックすると、A にリダイレクトされ、サイトからユーザーの許可を得て、認証トークンを使用して B にリダイレクトされます。これには、絶対に信頼すべきではないサイトでユーザーにメインのパスワードを入力するように勧めないという利点があります。
HTTPS/TLS/SSL を使用してユーザーをサイトにリダイレクトします。これにより、ユーザーの資格情報が保護され、ユーザーに対して身元が確認されるため、ファーミング攻撃に陥る可能性が低くなります。次に、十分にランダムなトークンを第三者に提供して、認証として使用できます。
ただし、このソリューションを使用しても、依然として重大なリスクがあることを理解してください。B がユーザーを攻撃したい場合でも、B はログイン資格情報を直接要求するだけで、ユーザーの一部を簡単にだますことができます。これはおそらく、セキュリティに精通していない彼らの大多数に不利に働くでしょう.
B が信頼されていない場合、私の専門的なアドバイスは、これを行わないことです。