HTTP仕様：Proxy-Authorization and Authorization headers
だから私は次のシナリオを実装しようとしています：
- アプリケーションは基本認証によって保護されています。
app.comでホストされているとしましょう - アプリケーションの前にあるHTTPプロキシも認証が必要です。
proxy.comでホストされています
したがって、ユーザーは同じ要求でプロキシとアプリケーションの両方の資格情報を提供する必要があります。したがって、ユーザーは異なるユーザー名/パスワードのペアを持ちます。
仕様を読んだ後、私はこれをどのように実装するべきか本当にわかりません。私がやろうとしていたことは：
- ユーザーは、認証を一切行わずにプロキシにHTTPリクエストを送信します。
- プロキシは
407 Proxy Authentication Requiredに応答し、Proxy-Authenticateの形式で"Proxy-Authenticate: Basic realm="proxy.com"ヘッダーを返します。
質問：このProxy-Authenticateヘッダーは正しく設定されていますか？ - その後、クライアントは
Proxy-Authorizationヘッダー、つまりプロキシusername:passwordのBase64表現でリクエストを再試行します。 - 今回はプロキシがリクエストを認証しますが、アプリケーションは
401 Unauthorizedヘッダーで応答します。ユーザーはプロキシによって認証されましたが、アプリケーションによっては認証されませんでした。アプリケーションは、WWW-AuthenticateのようなWWW-Authenticate: Basic realm="app.com"ヘッダーを応答に追加します。 質問：このヘッダー値は正しいですか？ - クライアントは、
Proxy-Authorizationヘッダーと、アプリのusername:passwordのBase64表現で評価されたAuthorizationヘッダーの両方を使用して、リクエストを再試行します。 - この時点で、プロキシはリクエストを正常に認証し、ユーザーを認証するアプリケーションにもリクエストを転送します。そして、クライアントは最終的に応答を受け取ります。
ワークフロー全体は正しいですか？
はい、それはあなたが説明した状況に対する有効なワークフローのように見え、それらの認証ヘッダーは正しい形式であるようです。
珍しいことではありますが、接続に複数のプロキシが連鎖している可能性があり、各プロキシ自体が認証を必要とする可能性があることに注意してください。この場合、各中間プロキシのクライアント側自体が407 Proxy Authentication Requiredメッセージとそれ自体は、Proxy-Authorizationヘッダー; Proxy-AuthenticateおよびProxy-Authorizationヘッダーは、1つのサーバーから次のサーバーに渡されないシングルホップヘッダーですが、WWW-AuthenticateおよびAuthorizationは、クライアントから最終サーバーへと見なされるエンドツーエンドのヘッダーであり、仲介者によって逐語的に渡されます。
Basicスキームは平文でパスワードを送信するため（base64は可逆エンコーディングです）、SSLで最も一般的に使用されます。このシナリオは別の方法で実装されます。これは、最終サーバーに送信されたパスワードがプロキシから見えないようにすることが望ましいためです。
- クライアントはプロキシへのSSLチャネルを開いてリクエストを開始しますが、通常のHTTPリクエストを送信する代わりに、送信します 特別な
CONNECTリクエスト （まだProxy-Authorizationヘッダー）TCPリモートサーバーへのトンネルを開く）。 - 次に、クライアントは、最初にネストされたanotherSSLチャネルを作成し、
Authorizationヘッダーを含む最終HTTPメッセージを転送します。
このシナリオでは、プロキシはクライアントが接続しているホストとポートのみを認識し、内部SSLチャネルを介して送信または受信したものを認識しません。さらに、ネストされたチャネルを使用すると、クライアントはプロキシとサーバーの両方のSSL証明書を「見る」ことができ、両方のIDを認証できます。