HTTP 401 Unauthorizedまたは403 "disabled"ユーザーに対して403 Forbidden？
認証サービスでは、ユーザーアカウントを無効にできます（一種のソフト削除）。
サーバーが無効なユーザーの認証要求を受信した場合、それがなければ有効になりますが、サーバーは401または403を返しますか？どちらのステータスコードでも、アカウントが無効にされたことを示すメッセージを返します。
クイックリファレンスについては、 HTTP/1.1 spec （emphasis mine）からの関連する引用符：
401 Unauthorized
要求にはユーザー認証が必要です。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション14.47）を含める必要があります。 クライアントは、適切なAuthorizationヘッダーフィールド（セクション14.8）で要求を繰り返すかもしれません。 リクエストにすでに認証クレデンシャルが含まれている場合、401レスポンスはそれらのクレデンシャルに対する認可が拒否されたことを示します。 401応答に以前の応答と同じチャレンジが含まれ、ユーザーエージェントがすでに少なくとも1回認証を試みた場合、ユーザーに応答で指定されたエンティティを提示する必要があります、そのエンティティには関連する診断情報が含まれている可能性があるため。 HTTPアクセス認証については、「HTTP認証：基本およびダイジェストアクセス認証」[43]で説明されています。
403 Forbidden
サーバーはリクエストを理解しましたが、それを実行することを拒否しています。 承認は役に立たず、リクエストは繰り返されるべきではない。リクエストメソッドがHEADでなく、サーバーがリクエストが履行されなかった理由を公表したい場合、SHOULDは拒否の理由を記述しますentity。サーバーがクライアントにこの情報を提供したくない場合は、代わりにステータスコード404（Not Found）を使用できます。
電子メール によって書かれた Roy T. Fielding に基づいて、明らかに現在のHTTP仕様には バグ があります。
仕様がintendedを読み取る方法は次のとおりです（上記の電子メールの引用符を使用）。
401 "認証されていない"：
認証されていないため、これを行うことはできません
403 "Unauthorized"：
ユーザーエージェントは有効な資格情報を送信しましたが、アクセス権がありません
したがって、無効なユーザーの場合、403が正しい応答です（および404もオプションです）。
この場合に何を返すかについて、2つの異なる答えがあります。
セマンティック選択-401不正。この場合、クライアントは資格情報を提供し、特定の資格情報に基づいて要求が拒否されました。クライアントが別の資格情報セットを使用して再試行した場合、またはアカウントが将来再び有効になった場合、同じリクエストが成功する可能性があります。
セキュリティの選択-404 Not Found。多くのサービスは、情報の漏えいを防ぐために、障害が発生した場合に404を返すだけです。 Githubはすぐに思い浮かびます。
一般的なAPI情報 から、githubの開発者ドキュメントで：
認証されていないリクエストは404を返し、個人情報の漏洩を防ぎます。
私が公共サービスとして展開していたものについては、おそらく、404を使用して、攻撃者に彼らの資格情報の試みに関する手がかりを与えないようにするでしょう。内部専用の場合、またはテスト中であれば、おそらく401を返します。
技術的には両方とも正しいです、それは本当にあなたがどれだけ明らかにしたいかに帰着します。
401を返すと、呼び出し側にアカウントが無効であると言われますが、これは正しいですが、APIを再度呼び出して同じ資格情報を持つユーザーを登録すると、呼び出しも失敗します。呼び出し側にとってはあまり使い物にならないかもしれません。
そのため、APIの使用方法とターゲットオーディエンスが誰/何であるかによって異なります。