認証
「あなたは誰か」を確認するプロセス。認可と対で語られる。
概要
認証（authentication）とは、通信やアクセスの相手が「本当に名乗っているとおりの本人か」を確認するプロセスです。最も身近な例はログインで、ID とパスワードの組を提示させ、正しければ本人とみなします。英語圏では AuthN と略され、しばしば対で語られる認可（AuthZ）と区別されます。
日本語では「認証」と「認可」が字面も似ていて混同されがちですが、問うていることが違います。認証は「あなたは誰か」、認可は「あなたに何をする権限があるか」。ログイン成功はあくまで本人確認が済んだだけで、その人が管理画面に入れるかどうかは別の判断（認可）です。この区別は OAuth や JWT といった発展的な語彙を理解する入口になるので、最初にしっかり押さえておきたいところです。
認証はユーザーのログインだけの話ではありません。API を呼び出すプログラムの認証（APIキーやクライアント証明書）、サーバ同士の認証、SSH でのマシンへの接続——「相手が本物か」を確かめる場面のすべてに認証があります。
なぜ生まれたか
コンピュータが一人一台の専有物だった時代には、本人確認の必要はほとんどありませんでした。必要になったのは、1台の計算機を複数人で共有するタイムシェアリングシステムが登場した1960年代です。誰のファイルか、誰の計算時間かを区別するには、まず「今操作しているのは誰か」を特定しなければならない。MIT の CTSS が導入したパスワードは、コンピュータにおける認証の原点とされています。
ネットワークの時代になると問題は一段深刻になりました。対面なら顔で本人確認できますが、ネットワークの向こう側にいる相手は姿が見えません。パケットの送信元は名乗りにすぎず、いくらでも偽装できます。さらに HTTP はステートレスなプロトコルで、リクエストごとに相手を覚えていません。そこで「最初に本人確認をし、その結果をセッションやCookie、トークンで持ち回る」という Web 認証の基本パターンが生まれました。今日の認証技術の多くは、「見えない相手を、盗聴や偽装がありうる経路越しに確認する」という難問への回答の積み重ねです。
詳細
認証の3要素と多要素認証
本人であることの証拠（認証要素）は、古典的に3種類に分類されます。本人だけが知っている「知識要素」（パスワード、PIN）、本人だけが持っている「所持要素」（スマートフォン、ハードウェアキー）、本人自身の特徴である「生体要素」（指紋、顔）です。それぞれ弱点が異なります。知識は盗み見や使い回しで漏れ、所持は紛失し、生体は漏洩しても変更できません。
そこで異なる種類の要素を組み合わせるのが多要素認証（MFA）です。パスワード（知識）に加えて認証アプリのワンタイムコード（所持)を求めれば、パスワードが漏れただけでは突破できません。パスワードリスト攻撃が常態化した現在、MFA の有効化は個人・組織を問わず最も費用対効果の高い防御策とされています。典型的な流れは、1つ目の要素の確認が済んでから2つ目の要素を要求する二段構えです。
パスワード認証の裏側
最も普及している知識要素のパスワードは、サーバ側での扱い方が重要です。パスワードを平文で保存してはならず、暗号化でもなく、ハッシュ化して保存するのが鉄則です。ハッシュは元に戻せないため、データベースが流出しても直ちにパスワードが漏れることはありません。照合は「入力された値を同じ方法でハッシュ化し、保存値と比較する」ことで行います。
認証に成功したら、その状態を次のリクエストに引き継ぐ必要があります。伝統的な方法はセッションID を Cookie に載せる方式、もうひとつは署名付きトークン（JWT が代表）をクライアントに渡す方式で、それぞれ失効管理やスケールのしやすさにトレードオフがあります。
パスワードの先へ — 委譲とパスキー
サービスごとにパスワードを作らせる時代は終わりつつあります。ひとつの流れが「認証の委譲」で、「Google でログイン」のように、信頼できる ID プロバイダに本人確認を任せる方式です。裏側では OAuth の上に本人確認の層を載せた OpenID Connect という標準が動いています。企業システムでは、一度のログインで複数サービスに入れるシングルサインオン（SSO）が同じ発想で実現されています。
もうひとつの大きな流れがパスキー（FIDO2/WebAuthn）です。これは公開鍵暗号を使った認証で、端末内の秘密鍵で署名し、サーバは登録済みの公開鍵で検証します。サーバ側に秘密が保存されないため漏洩に強く、サイトごとに鍵が違うためフィッシングにも原理的に強い。主要プラットフォームが対応を終え、「パスワードレス」への移行が現実に進んでいます。
実務での落とし穴
認証の実装で典型的な失敗はいくつかあります。まず自作の危険性。パスワードハッシュの方式選定（Argon2 や bcrypt を使う）、総当たり対策のレート制限、パスワードリセットの安全な設計など、正しく作るには考慮点が多く、実績のある認証ライブラリや IDaaS（Auth0、Cognito など）に寄せるのが現実的な判断になりがちです。次に、ログインエラーの出し方。「IDが存在しません」と「パスワードが違います」を区別して返すと、攻撃者に登録済みIDの探索を許します。そして忘れがちなのが、認証が済んでも認可は別問題だということです。「ログインしていれば誰でも他人のデータをURLの ID 差し替えで見られる」という脆弱性（IDOR）は、認証と認可の混同から生まれる代表例です。