WebサービスやAPIを利用する際に「401 Unauthorized」というエラーが表示されて困った経験がある方も多いでしょう。
ステータスコード401は認証情報が不正または欠落していることを示すエラーであり、ログイン処理やAPIキーの管理と密接に関わる重要なコードです。
本記事では、ステータスコード401の正確な意味と発生原因、Basic認証・トークン認証との関係、具体的な対処法まで詳しく解説します。
Web開発者やAPIを利用するエンジニアにとって必須の知識ですので、ぜひ参考にしてください。
ステータスコード401（Unauthorized）とは？意味と403との違い
それではまず、ステータスコード401の基本的な定義と、よく混同される403との違いについて解説していきます。
「401 Unauthorized」という名称は直訳すると「権限なし」ですが、より正確には「認証されていない」という意味であり、HTTP/1.1の仕様では「認証が必要なリソースへの未認証アクセス」を示すコードです。
403（Forbidden）が「認証済みだがアクセス権限がない」場合を示すのに対し、401は「そもそも認証が行われていない、または認証に失敗した」場合に使用される点が大きな違いでしょう。
401と403の違いの整理
401 Unauthorized：認証情報が存在しない・無効・期限切れ（認証の問題）
403 Forbidden：認証済みだが、そのリソースへのアクセス権限がない（認可の問題）
401には認証チャレンジ（WWW-Authenticateヘッダー）が必要であるという仕様上の違いもあります。
WWW-Authenticateヘッダーの役割
401レスポンスには「WWW-Authenticate」ヘッダーを含めることが仕様で定められており、クライアントに対してどの認証方式を使用すべきかを伝えます。
Basic認証の場合は「WWW-Authenticate: Basic realm=”Protected Area”」、Bearer（トークン）認証の場合は「WWW-Authenticate: Bearer realm=”api”」のような形式で返されます。
このヘッダーを受け取ったブラウザは自動的に認証ダイアログを表示したり、APIクライアントは適切な認証情報を付けて再リクエストを行うことができるでしょう。
401が発生する主な原因
401エラーの代表的な発生原因としては、APIキーやトークンが設定されていない・トークンの有効期限が切れている・パスワードが間違っている・セッションが切れているなどが挙げられます。
またAPIへのリクエスト時にAuthorizationヘッダーが欠落していたり、ヘッダーの書式が正しくない場合にも401が返されることがあります。
JWTトークンを使用した認証では、トークンの署名検証失敗やexpirationの超過も一般的な401の原因でしょう。
認証方式別の401エラーの対処法
続いては、代表的な認証方式ごとの401エラー発生原因と対処法を確認していきます。
Basic認証での401エラー
Basic認証はユーザー名とパスワードをBase64エンコードしてAuthorizationヘッダーに含める認証方式です。
「Authorization: Basic [Base64エンコードされた”ユーザー名:パスワード”]」という形式でリクエストを送る必要があり、ヘッダーが欠落していたり認証情報が誤っている場合に401が返されます。
curlでは「curl -u username:password [URL]」オプションで簡単にBasic認証でのリクエストを行うことができるでしょう。
Bearer（トークン）認証での401エラー
OAuthやJWTを使ったBearer認証では、「Authorization: Bearer [アクセストークン]」の形式でリクエストヘッダーにトークンを付与します。
トークンの有効期限が切れた場合は401が返されるため、クライアントはリフレッシュトークンを使って新しいアクセストークンを取得し、再リクエストを行う実装が必要です。
トークンが正しい形式で送られているか（スペースや改行が含まれていないかなど）を確認することも重要でしょう。
| 認証方式 | Authorizationヘッダーの形式 | よくある401の原因 |
|---|---|---|
| Basic認証 | Basic [Base64(user:pass)] | ヘッダー欠落・認証情報誤り |
| Bearer認証 | Bearer [アクセストークン] | トークン期限切れ・形式ミス |
| APIキー認証 | X-API-Key: [キー]など | キー未設定・無効なキー |
| Digest認証 | Digest [パラメータ] | ノンスの期限切れ |
セッション切れによる401エラーと対処
Webアプリケーションでは、サーバーサイドのセッションが期限切れになると401エラーが返されることがあります。
クライアント側では401を受け取った際にログインページへリダイレクトする処理を実装することが一般的です。
SPAやモバイルアプリでは401レスポンスを検知してトークンのリフレッシュを自動的に試み、失敗した場合はログイン画面へ誘導するインターセプター実装が効果的でしょう。
401エラーの適切な実装とセキュリティ設計
続いては、API設計者・Webアプリケーション開発者の観点から、401エラーの適切な実装とセキュリティ設計のポイントを確認していきます。
認証ミドルウェアでの401実装
WebアプリケーションフレームワークではJWT検証やセッション確認を行う認証ミドルウェアを設定し、認証チェックに失敗した場合に401を返す実装が一般的です。
Express（Node.js）やLaravel（PHP）・Django（Python）などの主要フレームワークには認証機能を提供するパッケージが豊富に存在します。
認証が必要なルートへのアクセス制御をミドルウェアで一元管理することで、各エンドポイントでの認証チェックの記述漏れを防ぐことができるでしょう。
401レスポンスのボディ設計
401レスポンスのボディには、クライアントが次のアクションを取りやすいよう、なぜ認証が失敗したかを示すエラーメッセージを含めることが推奨されます。
ただし、セキュリティの観点からパスワードが間違っているのかユーザー名が存在しないのかを明示的に区別するメッセージは避けることが基本です。
「認証情報が無効です」「アクセストークンの有効期限が切れています」のような汎用的なメッセージが適切でしょう。
HTTPS環境での認証の重要性
Basic認証はBase64エンコードされているだけで暗号化はされていないため、必ずHTTPS（TLS）を通じて使用することが必須です。
HTTP環境でBasic認証を使用すると、ネットワーク上で認証情報が平文で傍受される危険があります。
HTTPS環境でのみ401認証を実装し、セキュアな通信経路でのみ認証情報をやり取りする設計が、セキュアなWebアプリケーションの基本要件でしょう。
まとめ
ステータスコード401（Unauthorized）は認証が必要なリソースへの未認証アクセス・認証失敗・トークン期限切れなどの状況で返されるエラーコードです。
Basic認証・Bearer認証・APIキー認証など認証方式に応じた正しいAuthorizationヘッダーの設定と、401受信時のクライアント側の再認証フローの実装が適切な対処法となります。
HTTPS環境での認証の徹底と、わかりやすいエラーメッセージ設計を組み合わせることで、セキュアで使いやすい認証システムの構築が実現できるでしょう。
