- ブラウザURL入力今ここ
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口今ここ
- アプリ処理
- DB保存
前2回で、経路を信頼しないこと・鍵をどう共有するかを見ました。鍵が共有できたとして、次に問うべきは「話している相手は誰か」「その相手に何を許すか」です。この2つは混同されやすく、HTTPのステータスコードの名前がその混同を助けています。
まず結論
認証は「主張された属性値を検証する」過程、認可は「リソースへのアクセスを認める承認」。検証しているものが**主張**か**アクセス**かで別物です。
HTTPの 401 は名前が Unauthorized ですが、本文は “lacks valid authentication credentials” です。名前で覚えると取り違えます。**機構上の決定的な差は、401 が `WWW-Authenticate` を MUST で要求し、403 は要求しないこと**です。
RFC 9110 が定める 401 と 403 のうち、レスポンスに `WWW-Authenticate` ヘッダを送ることを **MUST** で要求しているのはどちらでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
動詞が違う
2つの定義を並べます。RFC 4949 から逐語です。
"authentication (I) The process of verifying a claim that a system entity or system resource has a certain attribute value."
"authorization 1a. (I) An approval that is granted to a system entity to access a system resource."
認証は verifying a claim(主張を検証する)。認可は an approval ... to access(アクセスへの承認)。検証の対象が「主張」なのか、承認の対象が「アクセス」なのか。動詞と目的語が違います。
順番にも意味があります。NIST用語集が引く FIPS 200 の認証の定義には “often as a prerequisite to allowing access to resources” という句が入っています。認証は認可の前提として行われることが多い。前提であって、認可そのものではありません。
「本人だと分かった」ことと「その操作を許してよい」ことは、別々に決める必要があります。本人だと分かった上で断ることがあるからです。
RFC 4949 の定義によれば、認証 (authentication) とは何を行う過程ですか。
401 という名前は、中身と合っていない
ここが本題です。HTTPのステータスコードは、この2つの区別を名前の上で取り違えています。RFC 9110 §15.5.2 の第1文——
"The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource."
名前は Unauthorized(認可されていない)なのに、理由は authentication credentials を欠くこと。しかも同じ節の第2段落では——
"If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials."
今度は authorization の語が出てきます。RFC自身が両方の語を使っているので、語の印象から区別を導こうとすると必ず行き詰まります。
では何で区別するか。MUST の有無です。
401 403WWW-Authenticate MUST send 要求なし第1文の理由 認証資格情報を欠く 理解した上で拒む再試行 新しい資格で MAY 同じ資格では SHOULD NOT含意 やり直せば通りうる やり直しても通らないことが多い
1行目が決定的です。401 を生成するサーバは WWW-Authenticate を MUST で送り、そこに少なくとも1つのチャレンジを含めなければなりません。これは「認証をやり直せ、やり方はこれだ」という指示です。403 にはこの要求がありません。
RFC 9110 §15.5.4 によれば、403 を受け取ったクライアントが**同じ資格情報で**リクエストを繰り返すことについて、どう規定されていますか。
401 — 足りないものを示して差し戻す
認証資格情報が無い、あるいは有効でない状態です。だからサーバは `WWW-Authenticate` で「この方式で認証せよ」と示すことを MUST で求められます。クライアントは新しい資格情報で再挑戦してよい (MAY)。拒否と同時に、次の一手が渡されます。
WWW-Authenticate: <チャレンジ> ← MUST意味: 認証をやり直す方法はこれだ
403 — 理解した上で断る
サーバはリクエストを理解しています。その上で実行を拒みます。資格情報が提示されていた場合、サーバはそれを「アクセスを認めるには不十分」と判断しています。同じ資格情報での自動再試行は SHOULD NOT。そもそも資格情報と無関係な理由で禁じられていることもあります。
WWW-Authenticate は要求されない意味: 次の一手は示されない
401 と 403。どちらも拒否ですが、片方だけがヘッダを MUST で要求されるのはなぜでしょうか。
「やり直せば通るかもしれない」拒否と、「やり直しても通らない」拒否。クライアントに渡すべき情報が違います。
この章のまとめ
- 認証は「主張された属性値を検証する」過程、認可は「リソースへのアクセスを承認する」こと(RFC 4949)。動詞が違う。
- FIPS 200 の認証の定義には “often as a prerequisite to allowing access” とあり、認証は認可の前提として位置づけられている。
- 401 の名前は Unauthorized だが、第1文は “lacks valid authentication credentials”。 同じ節で authorization の語も使われる。名前と語では区別できない。
- 機構上の決定的な差は
WWW-Authenticateの MUST。 401 は送らなければならず、403 には要求が無い。再挑戦が意味を持つかどうかの差。 - 403 は同じ資格情報での自動再試行が SHOULD NOT。資格情報と無関係な理由で禁じられている場合もある。
- Bearer トークンは持っているだけで使える(RFC 6750)。信頼しない経路と組み合わせたときの危うさは、この性質から導ける。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「401 Unauthorized は認可(権限)の不足、403 Forbidden は認証の失敗を表す」——この説明の評価はどれですか。
用語集(5語)
- 認証 (authentication)
- システム実体やシステムリソースが、ある属性値を持つという主張を検証する過程(RFC 4949)。識別(主張の提示)と検証(証拠の提示)の2段階からなる。
- 認可 (authorization)
- システム実体にシステムリソースへのアクセスを認める承認、またはその承認を与える過程(RFC 4949)。読み・書き・実行といったアクセス方式を指定しうる。
- 401 Unauthorized
- 対象リソースに対する有効な**認証**資格情報を欠くためにリクエストが適用されなかったことを示す(RFC 9110 §15.5.2)。生成するサーバは `WWW-Authenticate` を **MUST** で送る。
- 403 Forbidden
- サーバがリクエストを理解した上で実行を拒むことを示す(RFC 9110 §15.5.4)。同じ資格情報での自動再試行は SHOULD NOT。資格情報と無関係な理由で禁じられている場合もある。
- Bearer トークン
- そのトークンを所持する者は誰でも、他の所持者と同じように使えるという性質を持つセキュリティトークン(RFC 6750 §1.2)。暗号鍵の所持を示す必要がない。