HTTP 401 Unauthorized：意味と解決方法

このエラーの意味と見分け方

• ブラウザ、APIクライアント、監視ツール、Webサイトチェッカーが401 Unauthorizedを報告する。
• 保護されたページまたはAPIルートでサインインを求められる、セッションが拒否される、または認証エラーのレスポンス本文が返される。
• 同じホストで一部の公開URLは正常に提供される一方、特定のルートまたはリクエストメソッドだけが401を返すことがある。
• DNSの名前解決とTLSネゴシエーションが正常でも、リクエストがHTTP 401を受け取ることがある。
• レスポンスヘッダーから、認証要件、リダイレクト、キャッシュの動作、プロキシまたはCDN、場合によってはリクエストIDや相関IDを確認できることがある。
• ブラウザのセッションから送信したリクエストは、APIクライアントや監視サービスから送信したリクエストとは異なる動作をする場合がある。

可能性の高い順の主な原因

1. 認証情報の欠落または無効 — リクエストに認証情報がない、セッションの有効期限が切れている、トークンが無効、パスワードが間違っている、またはAuthorizationヘッダーの形式が正しくない。
2. リクエストコンテキストの誤り — クライアントが間違ったURL、HTTPメソッド、ホスト、audience、scope、Cookie、APIキー、環境を使用しているため、別の場所では有効な認証情報がここでは受け入れられない。
3. アプリケーションの認証ルール — ミドルウェア、ルートガード、セッション検証が、アプリケーションのハンドラーが実行される前にリクエストを拒否する。
4. Webサーバー、リバースプロキシ、CDN、WAFのルール — インフラストラクチャのレイヤーが認証を要求している、または不完全・変更済み・欠落した認証情報を転送している。
5. キャッシュまたはルーティングの動作 — キャッシュされたレスポンス、予期しないリダイレクト、古いルート、ホストやプロトコルの不一致によって、認証要件の異なるエンドポイントへクライアントが送られる。
6. 上流の設定またはサービス変更 — デプロイ、IDプロバイダーの変更、シークレットのローテーション、プロキシの変更、環境の不一致によって、それまで有効だったリクエストが失敗する。

修正方法

訪問者向け

1. 正確なアドレスを確認し、何度も再読み込みせずに1回だけ再試行します。
2. リソースにアカウントが必要な場合は、サイトの通常の画面からサインインして再試行します。セッションの有効期限が切れていないか確認してください。
3. 1つのリンクだけが失敗する場合は、サイト全体が利用できないと判断せず、その特定のURLを報告します。
4. おおよその時刻、ページまたはAPIエンドポイント、表示された401メッセージを記録します。パスワード、Cookie、アクセストークンなどの秘密情報は送信しないでください。
5. 通常は公開されているページが401を返す場合、またはサインインに成功しても保護されたリソースにアクセスできない場合は、サイト所有者に連絡します。

APIクライアントと開発者向け

1. 失敗したクライアントが使用したものと同じHTTPメソッド、URL、ホスト、クエリパラメーター、ヘッダー、本文で失敗を再現します。可能であれば、本番環境以外のアカウントまたはテスト用認証情報を使用してください。
2. 認証情報が存在し、有効期限内で、形式が正しく、このホスト、ルート、環境向けであることを確認します。認証システムで使用している場合は、トークンのscopeまたはaudienceも確認してください。
3. 秘密情報を公開せずに、ステータス、レスポンスヘッダー、レスポンス本文を取得します。認証チャレンジ情報、リダイレクト、キャッシュヘッダー、リクエストIDに特に注意してください。
4. 正常なリクエストと失敗するリクエストを、1回に1つの違いだけ比較します。Cookie、Authorizationヘッダー、プロキシ転送、リダイレクト、リクエストメソッドを確認してください。
5. レスポンスを生成したコンポーネント（アプリケーション、Webサーバー、リバースプロキシ、CDN、WAF）を特定します。レスポンス本文、特徴的なヘッダー、レイヤー固有のログが識別に役立ちます。
6. タイムスタンプ、ルート、クライアント、リクエストIDを使って対応するログを調べます。最近のデプロイ、IDプロバイダーの変更、シークレットのローテーション、ルーティングの更新、プロキシ設定を確認してください。
7. 認可された最小限の修正（たとえば、ルート固有の認証情報や転送ルールの修正）を行い、同じリクエストを再テストします。最初の対応として認証を無効化したり、非公開レスポンスを公開キャッシュしたり、広範な権限を付与したりしないでください。
8. 関連する公開・保護ルート、該当するHTTPメソッド、想定される未認証時の動作をテストし、修正によってアクセス制御の問題が発生していないことを確認します。

近いエラーとの違い

• 401 Unauthorized: 認証情報がない、無効である、またはエンドポイントに受け入れられていない。
• 403 Forbidden: サーバーはリクエストを理解したものの、アクセスを認可しない。有効な認証が存在する場合もあります。
• 404 Not Found: その場所ではルートまたはリソースを利用できない。ただし、保護されたリソースを意図的にこの方法で隠すシステムもあります。
• 5xxレスポンス: 認証を単に拒否したのではなく、サーバー側の処理に失敗している。

予防と修正確認

• ルート、メソッド、クライアント種別、デプロイごとに認証失敗を監視し、特定ルートの問題と広範なインシデントを区別できるようにします。
• 認証、ルーティング、プロキシ、キャッシュの設定をバージョン管理し、リリース前に変更をレビューします。
• 重要なWebルートとAPIメソッドについて、想定される未認証、認証済み、権限不足時のレスポンスをテストします。
• 開発、テスト、本番で別々の認証情報と設定を使用し、管理された手順でシークレットをローテーションします。
• アクセストークン、Cookie、パスワードがアプリケーション、プロキシ、監視、サポートのログに記録されないようにします。
• サニタイズ済みのリクエストID、タイムスタンプ、レイヤー固有のログを、認証失敗の調査に必要な期間保存します。
• どのルートが意図的に公開、保護、またはメソッドやクライアント種別によって制限されているかを文書化します。

よくある質問