認証
Authentication ・ にんしょう
相手が名乗りどおりの本人かを、知識・所持・生体の証拠で確かめるプロセス。認可の前段。
✦ 30秒で試す — 航海漏れたら変えられる合言葉と、一生変えられない合言葉がある攻撃者は、盗んだデータで利用者になりすませる？予想してみる概要
認証（authentication）とは、通信やアクセスの相手が「本当に名乗っているとおりの本人か」を確認するプロセスです。最も身近な例はログインで、ID とパスワードの組を提示させ、正しければ本人とみなします。英語圏では AuthN と略され、しばしば対で語られる認可（AuthZ）と区別されます。
日本語では「認証」と「認可」が字面も似ていて混同されがちですが、問うていることが違います。認証は「あなたは誰か」、認可は「あなたに何をする権限があるか」。ログイン成功はあくまで本人確認が済んだだけで、その人が管理画面に入れるかどうかは別の判断（認可）です。この区別は OAuth や JWT といった発展的な語彙を理解する入口になるので、最初にしっかり押さえておきたいところです。
認証は人のログインだけの話ではありません。API を呼び出すプログラムは APIキーやクライアント証明書（mTLS）で名乗り、サーバどうしも証明書で互いを確かめ、SSH でマシンに入るときは鍵で本人を示します。「相手が本物か」を確かめる場面のすべてに認証があり、どの場面でも「何を証拠として受け取り、何と照合するか」という同じ構造をしています。
なぜ生まれたか
コンピュータが一人一台の専有物だった時代には、本人確認の必要はほとんどありませんでした。必要になったのは、1台の計算機を複数人で共有するタイムシェアリングシステムが登場した1960年代です。誰のファイルか、誰の計算時間かを区別するには、まず「今操作しているのは誰か」を特定しなければなりません。MIT の CTSS が導入したパスワードは、コンピュータにおける認証の原点とされています。
ネットワークの時代になると問題は一段深刻になりました。対面なら顔で本人確認できますが、ネットワークの向こう側にいる相手は姿が見えません。パケットの送信元は名乗りにすぎず、いくらでも偽装できます。さらに HTTP はステートレスなプロトコルで、リクエストごとに相手を覚えていません。そこで「最初に本人確認をし、その結果をセッションや Cookie、トークンで持ち回る」という Web 認証の基本パターンが生まれました。
その後の歴史は、パスワードの弱点を1つずつ塞いでいく系譜です。平文で保存していたパスワードが漏れる事件が相次いでハッシュ化による保存が定着し、使い回しとフィッシングでパスワードそのものが盗まれるようになると、別の証拠を重ねる多要素認証が広まりました。そしていま、「人が入力する秘密」そのものをなくすパスキーへの移行が進んでいます。どれも「見えない相手を、盗聴や偽装がありうる経路越しに確認する」という難問への回答の積み重ねです。
詳細
何を証拠にするか — 認証の3要素
本人であることの証拠（認証要素）は、古典的に3種類に分類されます。本人だけが知っている「知識要素」（パスワード、PIN）、本人だけが持っている「所持要素」（スマートフォン、セキュリティキー）、本人自身の特徴である「生体要素」（指紋、顔）です。3つを分けて考えるのは、破られ方がまったく違うからです。
知識は盗み見や使い回しで漏れますが、漏れたと分かれば変更できます。所持物は盗まれたり失くしたりしますが、無効化して新しいものを登録し直せます。生体は偽造が難しい一方で、一度写し取られると取り替えがききません。このため生体は、サーバへ送る「証拠」ではなく、手元の端末の鍵を開けるための確認として使うのが今日の定石です（パスキーの指紋認証も、指紋そのものは端末から出ません）。
破られ方の違う要素を組み合わせるのが多要素認証（MFA）です。パスワード（知識）に加えて認証アプリのワンタイムコード（所持）を求めれば、パスワードが漏れただけでは突破できません。パスワードリスト攻撃が常態化した現在、MFA の有効化は個人・組織を問わず最も費用対効果の高い防御策とされています。
ログインから「持ち回り」まで
認証の本体は1回の照合ですが、HTTP は次のリクエストでもう相手を覚えていません。そこで照合に成功したら、その結果を「本人確認済みの印」としてブラウザに持たせ、以後のリクエストで提示させます。ブラウザを1人の参加者として置くと、流れは次のようになります。
サーバはパスワードを平文で保存せず、暗号化でもなく、ソルト（ユーザーごとの乱数）を混ぜてハッシュ化した値だけを保存します。ハッシュは元に戻せないので、RDBMS の中身が流出しても直ちにパスワードが漏れることはありません。照合は「入力された値を同じ方式でハッシュ化し、保存値と比べる」ことで行います。方式には Argon2 や bcrypt のような、わざと計算を重くした専用のものを使います。
照合に成功したら、その状態を次のリクエストに引き継ぎます。伝統的な方法はセッション ID を Cookie に載せる方式、もうひとつは署名付きトークン（JWT が代表）を渡す方式で、失効の管理しやすさとスケールのしやすさにトレードオフがあります。どちらにしても、ログイン後の攻撃者の狙いはパスワードではなくこの「印」に移ります。印を盗まれればログインを経ずに本人になりすまされるので、認証の強さはログインの瞬間だけでなく、印の守り方（HttpOnly・Secure 属性、短い有効期限、ログイン時のセッション ID の振り直し）まで含めて決まります。
サーバが何を預かるか — パスワードからパスキーへ
認証方式を比べるときに役立つのが、「通信路を何が流れ、サーバが何を預かり、それが漏れたら何が起きるか」という見方です。
サービスごとにパスワードを作らせる時代は終わりつつあります。ひとつの流れが「認証の委譲」で、「Google でログイン」のように、信頼できる IdP（ID プロバイダ）に本人確認を任せる方式です。裏側では OAuth の上に本人確認の層を載せた OIDC（OpenID Connect）が動いており、アプリは IdP が署名した「誰が・いつ認証されたか」の証明を受け取るだけで、パスワードを預かりません。企業では、一度のログインで複数のサービスに入れる SSO が同じ発想で実現されています。
もうひとつの大きな流れがパスキー（FIDO2/WebAuthn）です。これは公開鍵暗号を使った認証で、登録時に端末の中で鍵ペアを作り、公開鍵だけをサーバへ渡します。ログインのたびにサーバが使い捨てのチャレンジ（乱数）を送り、端末は秘密鍵で署名して返します。上の図のとおり、サーバの預かり物は公開鍵だけなので、漏れてもなりすましには使えません。フィッシングに強い理由は別のところにあります。鍵は登録したサイトのオリジン（RP ID）に束縛されていて、ブラウザは署名を依頼するときに、いま開いているページのオリジンを認証器へ伝えます。偽ドメインのページからの依頼には、本物のサイト用の鍵がそもそも応じません。人が「このページは本物か」を見分ける代わりに、ブラウザと認証器がオリジンを機械的に照合する——これがパスキーの本質です（詳しくは多要素認証で扱います）。
実務での落とし穴
認証の実装で典型的な失敗はいくつかあります。まず自作の危険性です。パスワードハッシュの方式選定、総当たりやパスワードリスト攻撃を抑えるレート制限、パスワードリセットの安全な設計など、正しく作るには考慮点が多く、実績のある認証ライブラリや IDaaS（Auth0、Amazon Cognito など）に寄せるのが現実的な判断になりがちです。
次に、ログインエラーの出し方です。「IDが存在しません」と「パスワードが違います」を区別して返すと、攻撃者に登録済み ID の探索を許します。パスワードリセットや新規登録の画面も同じ情報を漏らしやすいので、応答の文言と応答時間の両方をそろえます。見落とされやすいのが復旧経路で、「メールのリンクだけでパスワードも MFA も再設定できる」なら、認証の強さはメールアカウントの強さまで下がります。
そして、認証が済んでも認可は別問題だということです。「ログインしていれば、URL の ID を差し替えるだけで他人のデータが見られる」という脆弱性（IDOR）は、認証と認可の混同から生まれる代表例です。
試問
本人確認に使われる8つの証拠が並んでいます。証拠は、本人だけが知っているもの（知識）、本人だけが持っているもの（所持）、本人の体の特徴（生体）の3種類に分けられ、種類の違う証拠を組み合わせると、1つが漏れても突破されにくくなります（多要素認証）。
8つの本人確認の証拠を、知識・所持・生体の3種類に仕分けよ
項目を選んでから、入れる箱を選びます