401 Unauthorized

使い方

401 Unauthorized エラーが届いたとき、クライアントは、要求したリソースへのアクセスが許可される前に有効なログイン資格情報が必要であると理解します。クライアントはまずログインするか、HTTP リクエストの一部として資格情報を提供する必要があります。リクエストとともに送信された既存の資格情報も有効ではありません。このステータスは、資格情報にかかわらずその操作が許可されないことをクライアントに伝える 403 Forbidden とは異なります。

注意

「Unauthorized」という名称は歴史的に誤解を招きます。401 はクライアントが未認証であること、つまり資格情報が欠落しているか無効であることを意味します。認証済みでも要求された操作を実行する権限がないユーザーには、代わりに 403 Forbidden が返されます。この名称は当初の HTTP/1.0 仕様から残り続けています。

サーバーが 401 Unauthorized レスポンスを送信する際には、WWW-Authenticate レスポンスヘッダーが含まれます。これにより、許可されている認可方式がクライアントに伝えられます。IANA は標準的な認証スキームの一覧を管理しており、それらは安全性と普及度の点でさまざまです。一般的な認証スキームは次のとおりです。

Basic

資格情報を ID とパスワードの組として送信します。

Bearer

トークン認証としても知られ、サーバーが生成しログイン成功後にクライアントへ返すセキュリティトークンに依存します。クライアントは保護されたリソースにアクセスするため、以降のリクエストでこれらのトークンを送信します。サーバーは必要に応じてエラーの詳細を含めます。例：WWW-Authenticate: Bearer error=“invalid_token”, error_description=“Token expired”。

Digest

リソースのリクエストを認証するために使われるチャレンジ・レスポンス型のプロトコルです。

HOBA

HTTP Origin-Bound Authentication の略で、サーバーがパスワードを保存する必要のないスキームであり、フィッシング攻撃に対する耐性があります。

Mutual

双方向認証としても知られ、basic や digest のスキームに似ていますが、サーバーがクライアントの暗号化されたパスワードを確実に把握している点が異なります。やり取りを続ける前に、クライアントとサーバーが互いを認証します。

AWS4-HMAC-SHA256

Amazon Web Services AWS S3 API Reference に認証情報を提供する認証アルゴリズムです。

サーバーは複数の認証方式を、複数行または1行のカンマ区切りで指定します。クライアントが必要な資格情報を持っている場合、それらは Authorization リクエストヘッダーを使って送信されます。

SEO への影響

Google のような検索エンジンは、401 Unauthorized ステータスを返す URL をインデックスしません。以前にインデックスされていた URL がこのステータスコードを返すようになると、検索結果から削除されます。このコードを返すページはクロールバジェットを消費しません。Googlebot の速度を落とすために 401 を使わないでください。クロール頻度を低下させるのは 429 だけです。

例

クライアントがリソースを要求し、サーバーはそのリソースが保護されていることを示すために 401 Unauthorized で応答します。サーバーは Basic と Mutual の両方の認可をサポートしていることを示します。クライアントは Authorization ヘッダーで指定した Basic 認証プロトコルを使い、username:password の組で応答します。その後、サーバーは要求されたリソースを送信します。

最初のリクエスト

GET /documents/tech-news HTTP/1.1
Host: example.com

最初のレスポンス

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Documents"
WWW-Authenticate: Mutual

Authorization を含む次のリクエスト

GET /documents/tech-news HTTP/1.1
Host: example.com
Authorization: Basic RXhhbXBsZTphaQ==

最終レスポンス

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 25000

<PDF document included in message body>

対処方法

401 Unauthorized は、アクセスを許可する前にサーバーが有効な資格情報を要求していることを意味します。

レスポンスの WWW-Authenticate ヘッダーを確認します。このヘッダーは期待される認証スキーム（Basic、Bearer、Digest など）を指定します。クライアントのリクエストを必要なスキームに合わせます。ブラウザの DevTools を開き、Network タブを選択して、Response Headers の下の WWW-Authenticate の項目を探します。

資格情報を検証します。ユーザー名とパスワード、API キー、またはベアラートークンが正しいことを確認します。Authorization ヘッダーの値に1文字の打ち間違いや空白があるだけで拒否されます。アプリケーションレベルの問題を切り分けるため、curl -H “Authorization: Bearer ” で資格情報を単独でテストします。

トークンが期限切れでないことを確認します。ベアラートークンやセッショントークンには有効期間があります。JWT をローカルのデバッガーでデコードして exp クレームを確認します。認証プロバイダーを通じてアクセストークンを再生成するかリフレッシュします。

Authorization ヘッダーの形式をスキームに合わせます。Basic は Base64 エンコードされた username:password の組を期待します。Bearer は生のトークン文字列を期待します。形式が誤っていると、有効な資格情報であっても 401 が発生します。よくある誤りは、スキームの接頭辞を省略すること（Bearer を付けずにトークンだけを送信すること）です。

必要に応じて資格情報を再生成します。API キーをローテーションするか、認可サーバーから新しいトークンを要求します。失効または無効化された資格情報は、常にこのステータスを生じさせます。

ブラウザのキャッシュとクッキーを消去します。古いセッションクッキーやキャッシュされた Authorization ヘッダーは、更新後の資格情報と衝突します。保存されたデータを消去して再認証します。

サーバー側の認証設定を確認します。Apache の .htpasswd ファイル、nginx の auth_basic ディレクティブ、.htaccess の AuthType ルールがアクセスを制御します。資格情報ファイルのパス、realm 名、ユーザーのエントリが存在することを確認します。nginx では次のようにします。

auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;

Apache では次のようにします。

AuthType Basic
AuthName "Restricted"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

OAuth のスコープと audience クレームを検証します。資格情報は正しくてもスコープが誤っていたり、aud クレームがリソースサーバーと一致しなかったりするアクセストークンは、やはり 401 を発生させます。そのトークンが対象の API 向けに発行されていることを確認します。

コードリファレンス

.NET

HttpStatusCode.Unauthorized

Rust

http::StatusCode::UNAUTHORIZED

Rails

:unauthorized

http.StatusUnauthorized

Symfony

Response::HTTP_UNAUTHORIZED

Python3.5+

http.HTTPStatus.UNAUTHORIZED

Java

java.net.HttpURLConnection.HTTP_UNAUTHORIZED

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_UNAUTHORIZED

Angular

@angular/common/http/HttpStatusCode.Unauthorized