サードパーティのアプリケーションと統合されたアプリケーションを作成しています。
これを行うには、ログインしたユーザーがサードパーティ統合のAPIキーを送信します。
彼らが送信したAPIキーが無効な場合（そしてサードパーティから401を返した場合）、どのHTTP応答を返す必要がありますか？
私のアプリケーションから401を返すのは、フロントエンドの観点からは、それらが私のアプリケーションによって認証されていないのか、サードパーティのアプリケーションによって認証されていないのかが不明であるため、混乱を招きます。
ちょうど400を与えたくなります-まるで、彼らが無効なメールアドレスなどでフォームを送信したかのようです。
回答:
コードを選択する必要がある場合は、403 Forbiddenを返すことを選択します。
RFC 7231§6.5.3は、403コードを次のように説明しています。
403（禁止）ステータスコードは、サーバーが要求を理解したが、承認を拒否したことを示します。要求が禁止された理由を公開したいサーバーは、その理由を応答ペイロード（存在する場合）に記述できます。
要求で認証資格情報が提供された場合、サーバーはそれらをアクセスを許可するには不十分であると見なします。クライアントは同じ資格情報でリクエストを自動的に繰り返すべきではありません。クライアントは、新しいまたは異なる資格情報で要求を繰り返すことができます。ただし、資格情報とは無関係の理由により、要求が禁止される場合があります。
禁止されているターゲットリソースの現在の存在を「非表示」にするオリジンサーバーは、代わりにステータスコード404（Not Found）で応答する場合があります。
このステータスコードは、一般的な「認証失敗」応答として一般的に使用され、401がブラウザにユーザー名/パスワードプロンプトを表示させるなど、特定の認証メカニズムをトリガーする可能性は低いです。認証が失敗した特定の理由は、機械で読み取り可能な形式（JSONやXMLなど）または人間が読み取り可能なドキュメント（HTMLなど）のいずれかで応答本文に記述できます。
コード400は、ここで考えられる最悪の選択肢ではありませんが、汎用的です。
ステータスコードHTTPステータスコード-407（プロキシ認証が必要）を使用できます。Mozilla Developers Referenceから：
HTTP 407 Proxy Authentication Requiredクライアントエラーステータス応答コードは、要求されたリソースにアクセスできるブラウザーとサーバーの間にあるプロキシサーバーの有効な認証資格情報がないため、要求が適用されなかったことを示します。
バックエンドアプリケーションはサードパーティAPIのプロキシのように機能しているため、この場合は407を使用しても問題ありません。
407不正解です。この場合、コードはプロキシであり、認証されます。認証されていない外部システムです。
401妥当ですが、クライアントがシステムに対して認証されているため、認証されていないものについては誤解を招きます。これは、100Continueの後まで外部認証が延期された場合にも機能しません。
400 リクエストはフォーマットとしては有効でしたが、外部エージェントで認証が失敗したため、正しくありません。
4xxここでは該当しないため、他のすべての応答は簡単に却下されます。
したがって、これは403Forbiddenを残します。私の意見では、これはこの場合の唯一の実際の選択肢です。
403禁止クライアントにはコンテンツへのアクセス権がありません。つまり、許可されていないため、サーバーは要求されたリソースの提供を拒否しています。401とは異なり、クライアントのIDはサーバーに認識されます。この場合も、失敗の「根本的な原因」を示すステータスメッセージで応答するのが適切な場合があります。それは実際にはアプリケーションのセキュリティ処理に依存します。
私の$ .02
400にすると、セマンティック要件を満たします。ユーザーがいくつかの不良データを提供しました。あなたが言うように、401/403はユーザーとあなたのサイトの間の問題を意味し、あなたのサイトや他のアプリケーションではありません。
HTTP 1.1 RFCのセクション1は次のように述べています。
前書き
各ハイパーテキスト転送プロトコル（HTTP）メッセージは、要求または応答のいずれかです。サーバーは接続で要求をリッスンし、受信した各メッセージを解析し、識別された要求ターゲットに関連してメッセージのセマンティクスを解釈し、1つ以上の応答メッセージでその要求に応答します。クライアントは、特定の意図を伝える要求メッセージを作成し、受信した応答を調べて意図が実行されたかどうかを確認し、結果の解釈方法を決定します。このドキュメントは、[RFC7230]で定義されたアーキテクチャーの観点から、HTTP / 1.1要求および応答のセマンティクスを定義します。
Ergoステータスコードの定義は、クライアントとサーバーの間です。私にとってそれは、他の（サーバーからサーバー、バックエンドなどの）相互作用に最適なものを選択することを意味します。
ここで提供される他のすべてのエキゾチックは、サービスの消費者を混乱させるだけです。
403を送るのはいつも良い
しかし、必要に応じてjson情報を追加できます
[Serializable]
[DataContract]
class Response
{
[DataMember]
public bool IsSuccess { get; set; }
[DataMember]
public string Message { get; set; }
[DataMember]
public object ResponseData { get; set; }
public Response(bool status, string message, object data)
{
IsSuccess = status;
Message = message;
ResponseData = data;
}
}
そして、応答に次の情報も追加します
return Json(new Response(false, "Login Failed, The user name or password provided is incorrect.", null));
リクエストが行われると、ログインボタンを無効にできます。更新が行われた場合にのみ、ボタンを有効にできます-クライアント側のロジック。
424 - Failed Dependencyこの場合、非常によく似合います。
ステータスコード424（失敗した依存関係）は、要求されたアクションが別のアクションに依存していてそのアクションが失敗したため、リソースでメソッドを実行できなかったことを意味します。
私は407に傾けます 。407プロキシ認証が必要ですこのコードは401（無許可）に似ていますが、クライアントが最初にプロキシで自身を認証する必要があることを示しています。プロキシは、要求されたリソースのプロキシに適用可能なチャレンジを含むProxy-Authenticateヘッダーフィールド（セクション14.33）を返す必要があります。クライアントは適切なProxy-Authorizationヘッダーフィールド（セクション14.34）を使用してリクエストを繰り返すことができます（MAY）。HTTPアクセス認証については、「HTTP認証：基本およびダイジェストアクセス認証」で説明しています。イスカンデルが述べたように。
問題が何であるかについてユーザーに最もよく示唆します。また、仕様に完全に一致するように、proxy-authorizationヘッダーを実装することもできます。
400を使用すると、クライアントは要求を作成するときに間違っていることを探して頭を悩ませるでしょう。
401または403を使用することは、独自のAPI認証および許可のためにそれらを保持する方が理にかなっています。
502は、問題が上流にあることをユーザーに示唆しているので、修正するまでハングしたままになる可能性があります。
私は401で我慢するでしょう。401 UnauthorizedエラーはHTTPステータスコードであり、ユーザーがアクセスしようとしたページは、ユーザーが有効なユーザーIDとパスワードで最初にログインするまでロードできません。ユーザーがログインして401 Unauthorizedエラーを受け取った場合は、ユーザーが入力した資格情報が何らかの理由で無効だったことを意味します。私たちの場合、彼らが提出したAPIキーは無効でした。エラーコードがわかりにくいときに使用していたアクティビティ図があります。
以下は同じリンクです：
この場合、仲介サーバーは正常にログに記録されており、上流サーバーは無効なキーによって認証を拒否しています。このコードはゲートウェイ（Yours）として機能し、上流のサーバー（サードパーティ）から無効な応答を受信しているサーバーを表すため、502コード（不正なゲートウェイ）がこの状況に適しているようです。
Proxy-Authenticate正しく認証する方法に関する情報を含むヘッダーとともに送信されます」と記載されています。何を入れるべきだと思いますか？RFC 7235には、「クライアントは、新しいまたは置換されたProxy-Authorizationヘッダーフィールドを使用してリクエストを繰り返すことができる」と記載されているため、質問者の状況には適用されない非常に具体的なメカニズムの一部のようです。