HTTPステータスコード401または403？認証と認可エラーの違い

ウェブページを読み込むたび、支払いを行うたび、またはアプリにログインするたびに、デバイスとサーバーの間で見えない会話が行われています。それは、メッセージを送って返信を待つようなもので—時には「いいね」、時には「もう一度試してみてください」と丁寧に言われ、時には「ダメだ」と言われることもあります。これらの応答はHTTPステータスコードとして知られ、インターネットの無名のヒーローであり、通信の流れを静かに導き、すべてをスムーズに—あるいは少なくとも問題が発生したときに教えてくれます。

HTTPステータスコードとは何か#

HTTPステータスコードは、クライアント（ブラウザやアプリなど）とサーバーの間の会話のシグナルのようなものです。リクエストを行ったときに何が起こったかについて迅速で明確な更新を提供します—すべてがスムーズに行われたか、何かが間違っていたか、さらなるアクションが必要かについて。これは、うまく運営されているベーカリーを訪れるようなものだと考えましょう。

200: すべてが完璧#

クロワッサンを頼むと、パン職人が微笑んでそれを手渡し、「どうぞ」と言います。これはHTTP 200 OKです—リクエストは成功し、すべてが予想通りに動作しました。

200 OK HTTPステータスコードは最も一般的に使用されるコードの1つで、クライアントからのリクエストがサーバーによって正常に受信、理解、処理されたことを示しています。

301: 移動しました#

お気に入りのベーカリーに着くと、「123 New Streetに移転しました」という看板があります。これは301 Moved Permanentlyです。サーバーはブラウザに新しいアドレスに自動的に移動するよう指示します。

301 Moved Permanently HTTPステータスコードは、リクエストされたリソースが新しいURLに恒久的に移動したことを示しています。このステータスコードは、クライアント（例：ブラウザやAPIクライアント）に記録を更新し、将来のリクエストのために新しいURLを使用するように通知します。

404: ごめんなさい、それはここにはありません#

チョコレートスコーンを頼むと、パン職人は「それはここでは作られていません」と言います。これは404 Not Foundです—あなたが探しているリソースはサーバー上には存在しません。

404 Not Found HTTPステータスコードは、サーバーがリクエストされたリソースを見つけることができなかったことを示しています。この応答は、クライアントのリクエストが有効であるが、サーバーが要求されたリソースを見つけることができなかったことを意味します。

401: あなたは誰ですか？#

VIPラウンジに入ろうとすると、バウンサーがあなたを止めて「メンバーシップカードを見せてください」と言います。これは401 Unauthorizedです—リソースにアクセスする前に認証が必要です。

401 Unauthorized HTTPステータスコードは、クライアントのリクエストが有効な認証資格情報を欠いているため適用されていないことを示しています。サーバーはクライアントに要求されたリソースにアクセスするために自身を認証することを要求します。

403: あなたにはできません#

あなたはメンバーシップカードを見せますが、バウンサーは「プラチナメンバーだけが入れます」と言います。これは403 Forbiddenです—あなたは認証されていますが、リソースにアクセスするための必要な権限を持っていません。

403 Forbidden HTTPステータスコードは、クライアントのリクエストが理解されているが、クライアントは必要な権限を欠いており、アクセスが拒否されていることを示しています。これは401 Unauthorizedのステータスとは異なり、クライアントが認証されている（またはリクエストが認証を必要としない）ものの、リソースへのアクセスが明示的に拒否されていることです。

500: オーブンが火を吹いている#

注文をすると突然煙がキッチンから出てきます。パン職人は「注文を履行できません。内部で何かが間違っています」と言います。これは500 Internal Server Errorです—サーバーが予期しない問題に遭遇しました。

500 Internal Server Error HTTPステータスコードは、リクエストを履行することを妨げる予期しない状況にサーバーが遭遇したことを示しています。それは一般的なエラーレスポンスであり、何が間違っているのかについての具体的な詳細を提供しません。

503: 一時的に利用できません#

ベーカリーに行くと、「メンテナンスのため閉店」との看板があります。ベーカリーは後で再開されます。これは503 Service Unavailableです—サーバーは一時的にリクエストを処理することができず、多くの場合、オーバーロードやメンテナンスが原因です。

503 Service Unavailable HTTPステータスコードは、サーバーが一時的にリクエストを処理できないことを示しています。これはサーバーのオーバーロード、メンテナンス、または他の一時的な条件による可能性があります。500 Internal Server Errorとは異なり、503は問題がすぐに解決されることが期待されていることを示します。

HTTPステータスコードは、クライアントとサーバー間の効率的なコミュニケーションを維持するための鍵です。彼らはクライアントがリクエストが成功したか、失敗したか、または追加のアクションが必要かを迅速に知らせます。開発者やIT専門家にとって、これらのコードを理解することは、問題のデバッグ、より良いエラーハンドリングの設計、全体的なユーザー体験の向上に役立ちます。

これらは、インターネットの継続的な会話におけるプロフェッショナルで標準化されたシグナルと見なしてください。

この記事では、認証（AuthN）と認可（AuthZ）に密接に関連する401および403エラーに焦点を当てたいと思います。

401 Unauthorizedをいつ使うべきか？#

401 Unauthorized HTTPステータスコードは、クライアントのリクエストが認証を必要としているが、不足している、無効である、または失敗しているときに使用されます。クライアントに対して、要求されたリソースにアクセスするために認証が必要であることを通知します。認証と401 Unauthorizedステータスコード間の関係は、リクエストが進行できるかどうかを決定する認証の役割にあります。

401 Unauthorizedには、認証方法の詳細を提供するWWW-Authenticateヘッダーが含まれている必要があります。

では、401 Unauthorizedを使用する一般的なシナリオは何ですか？

1. 認証が不足している

   リクエストに必要な認証資格情報が含まれていません。例：認可ヘッダーなしで保護されたAPIエンドポイントにリクエストが行われている。

2. 無効な認証資格情報

   クライアントが資格情報を提供するが、それが間違っているか、またはサーバーが期待するものと一致しません。例：無効なAPIキーまたは不正なトークンを送信するユーザー。

3. 認証トークンの有効期限切れ

   認証トークンは有効ですが期限が切れており、クライアントは再認証する必要があります。例：過去の有効期限（expクレーム）を持つJWTトークン。

4. 認可ヘッダーが不足または不正

   認可ヘッダーが必要ですが、提供されていないか、形式が正しくありません。

5. 認証スキームがサポートされていない

   クライアントが提供する認証方法がサーバーでサポートされていません。例：クライアントがBasic認証ヘッダーを送信していますが、サーバーはBearerトークンのみをサポートしています。

6. 無効なセッションまたはトークンの取り消し

   ユーザーのセッションが無効にされているか、トークンが取り消されています。例：ユーザーがログアウトしても、同じトークンが保護リソースへのアクセスに使用されています。

例のレスポンス

403 Forbiddenをいつ使うべきか？#

403 Forbidden HTTPステータスコードは、サーバーがリクエストを理解し、クライアントの身元（認証されている場合）を認識しているが、不十分な権限によってアクセスを拒否することを意味します。これは明確に「これをすることは許可されていません」と伝え、明確なアクセスの境界を保証し、セキュリティポリシーを強化します。

401 Unauthorizedと403 Forbiddenの違いは、認証と認可のコンテキスト内での役割にあります。

認可は認証とは別のメカニズムです。認証はあなたが誰であるかを確認し、認可は特定のリソースにアクセスできるかどうか、どのようなアクションを実行できるかを決定します。

AuthNとAuthZについての詳細な違いを確認するには、次の記事を参照してください。

What is AuthZ

What is AuthN

では、403 Forbiddenを使用する一般的なシナリオは何ですか？

1. 認証済みだが権限が不足している

   クライアントはログインまたは認証されていますが、必要な権限や役割を持っていません。例： "viewer"の役割のユーザーがファイルの削除を試みるが、「editor」権限が必要です。

2. リソースアクセス制限

   リソースへのアクセスが特定のユーザーまたはグループに意図的に制限されています。例：特定のユーザーに共有されているプライベート文書にアクセスしようとしているも、アクセスリストにないユーザー。

3. IPまたは地理的ブロッキング

   クライアントのIPアドレスまたは地理的な場所がサーバーによってブロックされています。例：制限された地域からサービスにアクセスしようとしているもので、そのサービスが特定の国だけで動作している。

4. ポリシーによるアクションのブロック

   クライアントがサーバー側のポリシーやルールで禁止されているアクションを試みています。例：リソースを「読み取り専用」とマークしているもののために変更を試みるユーザー。

5. ブロックされた静的リソース

   サーバーがセキュリティ上の理由で特定の静的ファイルまたはディレクトリへのアクセスを拒否しています。

   例：.htaccessファイルまたはサーバーの構成ファイルにアクセスを試みるユーザー。

6. アカウントの停止または無効化

   クライアントのアカウントが違反または非活動のために無効化またはブロックされています。例：停止されたアカウントのユーザーがログインまたはリソースにアクセスしようとしています。

7. 高度な権限が必要なアクション

   要求されたアクションに特別な権限（例えば、管理者またはスーパーユーザー）が必要です。例：標準ユーザーが管理者専用のエンドポイントにアクセスしようとしている。

例のレスポンス

401 Unauthorizedエラーをトラブルシューティングするにはどうすればいいか#

401エラーは通常、認証が必要であり、失敗したことを示しています。

資格情報の確認#

認可ヘッダーが存在し、正しくフォーマットされていることを確認し、資格情報（APIキー、トークン、またはパスワード）が正しく、有効期限が切れていないことを確認します。間違ったユーザー名やパスワードを入力することは、401エラーの最も頻繁な原因の1つです。

認証方法を確認#

サーバーは、提供されている認証方法とは異なるものを期待しているかもしれません。これは、クライアントとサーバーが認証プロトコルにおいて一致していない場合に発生することがあります。サーバーによって指定された方法（例：Basic, Bearer, API Key）を使用し、ヘッダーの正しい構文を確認します。

サーバーレスポンスの確認#

レスポンスボディをエラーディテールについて確認し、WWW-Authenticateヘッダーを認証指示として確認します。

リクエストの確認#

エンドポイント、クエリパラメータ、およびホストが正確であることを確認し、アクセスしているリソースが認証を必要とするかどうかを確認します。

トークン問題の確認#

トークンの有効性、有効期限、及びクレームをデコードして確認し、トークンの受信者（aud）をAPIの要件に一致させます。

403 Forbiddenエラーをトラブルシューティングするにはどうすればいいか#

403 Forbidden Errorは通常、認可プロセスが完了しているが、アクセスが拒否されたことを意味します。このエラーをトラブルシューティングするには、次の条件を考慮してください。

権限の確認#

アカウント、APIキー、またはトークンがリソースのために必要な権限を持っていることを確認してください。リソースが特定の役割またはグループに制限されているかどうかを確認します。

認証が正しいことを確認#

正しく認証されていることを確認します（例：有効なトークンまたは資格情報で）。

サーバーが必要とする認証方法を再確認してください。

リソースの確認#

リクエストされたリソースが存在し、アクセス権を持っているかを確認してください。APIを使用している場合は、ドキュメントに記載されているエンドポイントの要件を確認してください。

IPまたは位置情報のブロックを確認#

IPアドレスまたは地理的な場所がサーバーによって制限されているか確認してください。

サーバーポリシーのレビュー#

要求されたアクションがサーバー側のルールやポリシー（例：読み取り専用リソースへのアクセス）に違反していないことを確認してください。

サーバーレスポンスの確認#

403エラーの理由を説明する詳細を含むレスポンスボディを確認してください。

単一のリクエストで401と403のステータスコードを両方返すことができるか#

いいえ、単一のHTTPリクエストが同時に401 Unauthorizedおよび403 Forbiddenステータスコードを返すことはできません, HTTPレスポンスに1つのステータスコードしか含めることができないからです。

認証と認可における401と403エラーコードの実用的な使用#

現代のアプリケーション開発において、401 Unauthorizedと403 Forbiddenは開発者が頻繁に遭遇する2つのHTTPステータスコードです。これらは類似しているように見えるかもしれませんが、その意味と使用ケースは明確に異なります。その違いを明確にするために、この記事では認証、認可、マルチテナンシー、マルチファクター認証（MFA）などのシナリオにおけるこれらのコードの実際の例を探ります。

1. ログインシナリオ: ユーザーが保護されたページにログインせずまたは有効な資格情報を提供せずにアクセスしようとします。サーバーは応答し、401 Unauthorizedエラーを投げます: “このページにアクセスするにはログインするか有効な資格情報を提供する必要があります。”
2. アクセス制御シナリオ: 同じユーザーが正常にログインした後、必要な管理者権限がないまま管理者専用ページにアクセスしようとします。サーバーは応答し、403 Forbiddenを投げます: “ログインしていますが、このページにアクセスする権限がありません。”
3. マルチテナントシナリオ: 同じユーザーがログインしたが、テナントAに属するものの、テナントBのリソースにアクセスしようとしますが、そこにアクセス権がありません。サーバーは応答し、403 Forbiddenを投げます: “認証されていますが、Tenant B内のこのリソースにアクセスする権限はありません。”
4. MFAシナリオ: ユーザーがログインしようとしますが、必要な多要素認証（MFA）を完了していません。サーバーは応答し、401 Unauthorizedエラーを投げます: “認証が不完全です。続行するにはMFAを完了してください。”

認証と認可のプロバイダーとしてLogtoを使用する#

Logtoは主に認証プロバイダーであり、パスワードレスログイン、メールとパスワード、多要素認証（MFA）、企業SSO、ソーシャルログインなど、OIDC、OAuth 2.0、及びSAMLなどのオープン標準プロトコルに基づくキーを提供しています。

Logto Cloudはまた、ロールベースアクセス制御（RBAC）、組織（マルチテナンシー）、及びカスタムトークンクレームなど、さまざまな認可ニーズを満たすための重要な認可機能も提供しています。