401は認証されていないこと、403は認証済みだが許可されていないことを意味します。リクエストについて4つの質問に答えると、正しいステータスとヘッダー、コードがわかります。
トークンがない、セッションが期限切れ、署名が不正など、リクエストに有効な認証情報がない場合は401 Unauthorizedを返します。ログインすれば解決する可能性があり、レスポンスにはWWW-Authenticateヘッダーが必須です。呼び出し元が誰かわかっていて、それでもその操作が許されない場合は403 Forbiddenを返します。再ログインしても何も変わりません。
UnauthorizedとForbiddenの違い
サーバーが拒否しているリクエストについて、4つの質問に答えてください。返すべきステータス、それに付けるヘッダー、コードコメントに書ける1行の理由が表示されます。リソースの存在自体を明かしたくない場合にも対応しています。
401は、サーバーがあなたを誰か知らない、または送った証明を受け入れなかったことを示します。403は、誰かはわかっているが、それでも答えはノーであることを示します。
はい。RFC 9110によると、401レスポンスを生成するサーバーは、トークンAPIならBearerのようなチャレンジを含むWWW-Authenticateヘッダーフィールドを少なくとも1つ送らなければなりません。
401です。認証情報はもう有効ではなく、新しいものなら解決します。Bearerチャレンジでerror="invalid_token"を付けてそれを伝えられます。
はい。仕様では、リソースが存在するかどうかを隠すために、403の代わりに404を送ることが認められています。他のユーザーに属するIDではよく使われる選択です。
その可能性はあります。サーバーは、IPルール、ファイル権限の不足、ファイアウォールのルール、ロールのチェック失敗など、そのリクエストに対して最終的と判断したあらゆる拒否で403を送ります。どれかは、たいていレスポンス本文かサーバーログに書かれています。
verifyTokenは、自分のセッションやJWTのチェックの代わりです。順序が重要で、まず認証、次に認可です。
一方の処理はユーザーをログインへ案内し、もう一方は拒否の理由を説明します。
はい
いいえ
リクエストに認証情報（セッションCookie、トークン、Authorizationヘッダー）が含まれていましたか？
その認証情報は有効で、期限切れではありませんでしたか？
この呼び出し元は、このリソースに対してこの操作を行うことが許可されていますか？
アクセス権のない呼び出し元に、リソースの存在を知られないようにすべきですか？
返すもの
誰もログインしていません。チャレンジを付けて認証情報を求めましょう。
認証情報は届きましたが、拒否されました。新しいものなら解決します。
呼び出し元はわかっていますが、権限がありません。再ログインしても解決しません。
呼び出し元には権限がなく、リソースの存在を明かさないほうが望ましい状況です。
認証済みで、許可もあります。リクエストを処理しましょう。
前の回答ですでにステータスが決まったため、質問していません。
無料で始める · クレジットカード不要