Webサイトを開くと、ログイン画面が出てきます。

IDとパスワードを入力する。スマートフォンに届いた数字を入力する。認証アプリで「承認」を押す。最近は、指紋や顔で入れることもあります。

どれも「ログイン」と呼んでいますが、システムは何を根拠に、私たちを通しているのでしょうか。

前の「暗号化と認証」シリーズでは、通信を暗号化することと、接続相手を確かめることを分けて考えました。TLSでは、証明書や署名を使い、接続したサーバーが意図した相手かを確認しました。

今回は、立場を反対にしてみます。サイト側は、アクセスしてきた人をどう確かめているのか。そこから、ログインの仕組みを追っていきます。

ログインできることと、操作を許されることは別

城門で、門番に呼び止められる場面を考えてみます。「あなたは誰ですか？」

名前を答えたら、それだけで通してもらえるでしょうか。名乗るだけなら、他人の名前も使えます。そこで門番は、合言葉や通行証など、名乗った相手であることを確かめる材料を求めます。

Webサイトのログインでも、似た仕事をしています。IDやメールアドレスで、まず「どのアカウントとして入ろうとしているか」を示します。その上で、そのアカウントに登録されたパスワードや認証手段を使えるかを確認します。これが、ここでいう認証です。

ただし、認証できても、すべての操作を許されるとは限りません。城へ入れる人でも、書庫の本を読めるとは限らない。書庫へ入れても、貴重な本を持ち出してよいとは限りません。

サイトでも同じです。どのアカウントとしてアクセスしているかを確かめるのが認証で、そのアカウントに何を許すかを判断するのが認可です。

確認すること	例
どのアカウントとしてアクセスしているか	ログインの認証
そのアカウントで何をしてよいか	閲覧・編集・削除などの権限確認

「ログインには成功したのに、この画面は開けない」という状況は、この二つを分けると理解しやすくなります。

また、普段のログインが、毎回その人の実名や住所まで確認しているわけでもありません。多くの場合は、登録したアカウントに対応する認証手段を、今アクセスしている側が使えるかを確かめています。アカウントを作るときに現実の身元を確認する仕事と、次に利用するときにそのアカウントの利用者を確かめる仕事も、区別して考えます（米国国立標準技術研究所（NIST）のデジタル本人確認ガイドライン）。

パスワードだけで、本当に本人だと分かる？

パスワード認証の考え方は、合言葉に近いものです。「このアカウントのパスワードを知っているなら、その利用者として扱いましょう」。普段は、本人だけが知っていることを期待しています。

でも、パスワードを知っていることと、本人であることは、完全に同じではありません。誰かに教えたかもしれません。別のサービスから漏れたパスワードを使い回していたかもしれません。偽のログイン画面へ入力してしまったかもしれません。

攻撃者が正しいパスワードを入力すると、パスワードの照合自体は成功します。前の暗号シリーズで見た、「計算が正しく動いた」と「相手が本物」は別、という話にも似ています。

だから、もう一つ違う材料で確かめたい。そこで登場するのが、スマートフォンや認証機器などを使う追加の確認です。

二段階認証と多要素認証は、同じ意味？

パスワードを入力した後、スマートフォンに届いたコードも入力する。こうした操作を「二段階認証」と呼ぶことがあります。

ここで、確認の段階と、確認に使う要素を分けておきます。二段階認証は、確認を二段階で行うことです。一方、多要素認証では、異なる種類の要素を組み合わせます。

要素	確認の根拠	例
知識	本人が知っていること	パスワード、PIN
所持	本人が持っているもの	認証機器、登録された認証アプリ
生体	本人の身体の特徴	指紋、顔

このような異なる要素を組み合わせる仕組みを、多要素認証（MFA：Multi-Factor Authentication）と呼びます（NIST SP 800-63B）。

例えば、パスワードの後に別の合言葉を聞いても、どちらも「知っていること」です。入力が二回になっただけで、異なる要素を組み合わせたとは限りません。

一方、パスワードと指紋認証なら、知識と生体を組み合わせる構成です。パスワードと登録した認証機器を使って得るコードなら、知識と所持の組み合わせになります。

単に手順を増やすのではなく、一つの材料が漏れても、それだけでは入れないようにするのが狙いです。

認証アプリの数字は、なぜ一定時間で変わるのか？

Microsoft Authenticatorなどを開くと、数字が表示され、しばらくすると別の数字へ変わります。あの数字は、毎回サーバーから送られてきているのでしょうか。

時間に基づくコードの方式では、アプリ自身が計算しています。その準備として、登録時にサービス側と認証アプリが、同じ秘密の値を持ちます。登録画面のQRコードを読み取る操作は、その秘密などをアプリへ設定するためのものです。

その後は、登録時に共有した秘密と、現在の時刻から求めた値を使って、アプリがコードを計算します。サービス側も、同じ秘密と時刻を使って計算し、入力されたコードと照合します。

この方式が、TOTP（Time-Based One-Time Password）です。仕様では、標準的な時間の区切りとして30秒が推奨されています（RFC 6238）。

アプリは秘密と時計を使って計算するので、コードの生成自体には、その都度の通信を必要としません。ただし、時計が大きくずれると、サービス側とは違う時間のコードを作ってしまいます。受け付ける側は、入力にかかる時間や時計のずれを考慮した範囲で照合します。

そして「ワンタイム」にするには、数字が時間で変わるだけでは不十分です。一度認証に成功したコードを、有効時間内だからといって再び受け付けないことも必要になります（RFC 6238）。

数字だけでなく、その元になる秘密が重要

画面に出る数字は短時間で変わります。でも、その数字を作る元の秘密は、毎回変わるわけではありません。登録用のQRコードなどから秘密を取得されると、別の端末でも同じようにコードを作られる可能性があります。

短い数字を守るだけでなく、その数字を作る秘密を守る必要があります。ここでも、暗号シリーズで追った共有秘密の管理が関係してきます。

SMS・メールの確認コードは、認証アプリと何が違う？

スマートフォンに届く数字でも、SMSやメールのコードは、先ほどとは動きが違います。典型的には、サービス側がコードを発行し、登録された電話番号やメールアドレスへ送ります。利用者は、それを受け取って入力します。

方法	コードを得る流れ
時間に基づく認証アプリ	アプリが、共有した秘密と時刻から計算する
SMS・メール	サービス側が発行したコードを、別の経路で受け取る

SMSなら、その電話番号へのメッセージを受け取れること。メールなら、そのメールを読めることが、確認の材料になります。ただ、受信できる経路が違えば、守るべき場所も違います。

電話番号を使える状態やメールアカウントを奪われれば、その経路での確認も影響を受けます。また、ログイン対象と確認用メールが同じパスワードに依存しているなら、パスワード一つの漏えいが両方へ波及することも考えられます。

「数字が届くから、どれも同じ安全性」というわけではありません。

一度限りでも、偽サイトに渡すと困る

短時間しか使えないコードでも、偽のログイン画面に入力し、攻撃者が直ちに本物のサイトへ転送すると、利用される可能性があります。

これは、本人が本物のサイトで認証を完了した後に、その通信を傍受する流れではありません。本人が偽サイトに入力したコードを、攻撃者が本物のサイトへリアルタイムに中継する攻撃です。

次回扱うパスキーでは、ここに別の考え方が出てきます。

スマートフォンで「承認」を押す認証は、数字の入力と何が違う？

認証アプリには、数字を見る使い方だけでなく、ログイン要求の通知を受けて承認する使い方もあります。例えば、PCでログインすると、登録済みのスマートフォンへ確認が来ます。利用者が内容を確認し、承認すると、サービス側が処理を進めます。

Microsoft Authenticatorでも、コードを表示する方式と、通知を使う方式が用意されています。同じアプリでも、認証の仕組みまで同じではありません（Microsoft Authenticator の認証方法）。

通知方式では、利用者が数字をサイトへ書き写す代わりに、今届いた要求を認めてよいかを操作で示します。ここで大切なのは、自分が始めたログインかどうかです。何も操作していないのに確認が届いたら、承認してよい理由にはなりません。

また、PCに表示された番号をアプリへ入力して照合する方式もあります。Microsoftの番号照合は、そのようにログイン画面とアプリ側の操作を結び付けます（Microsoft Entra の番号照合）。ただし、画面の番号を合わせることも、あらゆる偽サイトを見破る仕組みではありません。

認証アプリという名前だけで判断するより、コードを作っているのか、届いた要求を承認しているのか、どの操作と結び付いているのか。そこまで分けると、動きが見えてきます。

メールのリンクを開くだけで、ログインできるのはなぜ？

数字を入力する代わりに、メールに届いたリンクを開いてログインする方式もあります。「ログイン用のリンクを送りました」と表示され、メールを開いてクリックすると、サイトへ入れる。このようなリンクを、マジックリンクと呼びます（Auth0：メールのマジックリンク）。

魔法という名前ですが、仕組みとしては、受け取ったリンクを使って確認しているわけです。リンクには、一時的な認証情報などが含まれます。受け付け側がそれを検証し、対応するアカウントのログイン処理を進めます。一定時間を過ぎると利用できなくする構成があります（Auth0 Passwordless）。

ここでは、サイト用のパスワードを入力していません。代わりに、登録されたメールを受け取り、そのリンクを利用できることを根拠にしています。確認する場所がなくなったのではなく、変わっています。

そのため、ログイン用リンクを他人へ渡すことは、普通のページのURLを共有するのとは意味が違います。どんな情報がリンクに入っているのか。期限はあるのか。一度使った後も使えるのか。後のURL連携の記事では、このようなリンクを受け付ける入口を、もう少し具体的に考えます。

本人確認が終わった後、何を引き継ぐのか

ここまで、パスワード、認証アプリ、通知、メールのリンクを見てきました。やり方は違っても、システムは何らかの材料を確認し、そのアカウントとして利用を始めてよいか判断しています。

ただ、ログインはそこで終わりではありません。ログインした後、マイページを開きます。次に履歴を開きます。設定画面へ移動します。そのたびにパスワードを入力したり、認証アプリで承認したりしているでしょうか。多くの場合は、していません。

最初に確認した結果を、次のアクセスへどう引き継いでいるのでしょう。

城門で一度身元を確かめてもらった男が、夕方に戻ってきます。門番が覚えていれば、そのまま話が通るかもしれません。覚えていなければ、また「あなたは誰ですか？」となります。

Webサイトでは、この「確認済みの相手を、次のアクセスでもどう扱うか」に仕組みが必要です。ここから先に出てくるのが、Cookie、セッション、トークンです。

仕事	今回の問い
利用を始める相手を確かめる	何を根拠に、そのアカウントとして通すのか
確認した結果を引き継ぐ	次のアクセスを、どのログイン状態と結び付けるのか

本人確認を強くするだけで、ログイン後の状態まで自動的に安全になるわけではありません。

このシリーズでは、前半で本人確認の方法を追い、その後でログイン状態、URL連携、APIのトークン、SSO、WindowsやVPNの認証へ進みます。

次回

次回は「認証とセッション② ― 指紋・顔・公開鍵で、どう本人を確かめるのか」です。

指紋や顔でログインするとき、その情報をサイトへ送っているのでしょうか。パスキーやクライアント証明書を入口に、前のシリーズで学んだ公開鍵と署名が、今度は利用者側の認証でどう働くのかを追ってみます。