HTTP 401と403の違い｜認証とアクセス拒否を切り分ける

HTTP 401と403は、どちらもアクセスできなかったときに見かけるコードです。ただし、次に確認する内容は同じではありません。

401では有効な認証資格情報が不足していること、403では要求を理解したうえで実行を拒んでいることが出発点になります。ここでは番号から原因を断定せず、調査先を絞る方法を整理します。

401と403の標準的な意味を比較する

RFC 9110の401・403の定義を、調査時の観点とともにまとめると次のようになります。

コード	標準的な意味	先に読む情報
401	対象に対する有効な認証資格情報がなく、要求が適用されていない	WWW-Authenticate、認証方式、APIの説明
403	要求を理解したが実行を拒否した	エラー本文、アクセス条件、応答元

401の応答には、対象に使える認証方式のチャレンジを含むWWW-Authenticateヘッダーが必要です。403は資格情報の不足に限らず、別の理由による拒否もあります。「401ならパスワード間違い、403ならログイン済み」と一律には判断しません。

アプリへ届く前に、入口の認証機能やアクセス制御が応答している可能性も考えます。ブラウザの表示だけでなく、対象URL、時刻、要求ID、ヘッダーやエラー本文の形式を記録します。

仮に同じ利用者が画面は開けるのに、特定APIだけ401になる場合、画面用のセッションとAPIの認証方式が一致するかを調べる必要があります。これは原因の断定ではなく、仕様と記録を照合するための仮説です。

確認表には、情報の値ではなく、適用条件を書きます。トークンやCookieの実値を共有する必要はありません。

SSO連携を使っている場合も、ログイン成立と個別操作の許可は分けて考えます。仕組みの整理はSSOの基本を参照してください。

403では、同じ資格情報による自動的な再試行を標準にしません。設定や権限の問題が残ったまま要求を増やしても、調査記録を複雑にするだけです。

401で認証情報を更新する場合も、正しい提供元と手順に従います。失敗を解消するために管理者権限へ広げたり、アクセス制御を外したりする前に、必要な操作と拒否理由を確認します。

問い合わせでは「403です」だけでなく、環境、対象操作、発生時刻、再現する範囲、機密値を除いたエラー内容を伝えます。同じ利用者の全操作か、特定リソースだけかも切分けの材料です。

コードは調査の入口であり、原因そのものではありません。 応答元と利用条件を対応させ、確認できた事実から次の担当へ渡しましょう。