Email Verification Protocol (EVP) を使うと、ブラウザから離れることなくメールアドレスの所有を確認することが可能になり、ユーザーの負担は大きく軽減されます。しかし、ウェブサイトが EVP に対応することは、ユーザー体験以上にパスキーの補完という意味で、アカウントライフサイクルに大きな役割を果たします。

メールアドレスは何のために確認するのか #

ユーザーアカウントを要するほとんどのインターネットサービスでは、メールアドレスの登録を前提とします。登録されたメールアドレスは、主にサービスに関わる重要な通知を送ったり、マーケティングメールを送ったりするために利用されますが、何よりユーザーがアカウントを復旧するアカウントリカバリを行うためには欠かせません。

メールアドレスの所有確認に使われるアプローチは大きく 2 つ、それぞれに一長一短があります：

  1. ワンタイムパスワード (OTP)：一定時間のみ有効な文字列をメールで送り、フォームに入力してもらう
  2. マジックリンク：一定時間のみ有効なリンクをメールで送り、クリックしてもらう
    • 長所：リンクに正規のドメインが指定されているため、フィッシング詐欺に引っかかりにくい
    • 短所：メールクライアントからリンクを開くため、アプリ内ブラウザを開いてしまうなど、ユーザーが利用していたブラウザから離れてしまうケースがある

どちらにも共通して言えるのは、ユーザーは一度アプリから離れてメールクライアントを開かなければならない、という点です。ブラウザから離れなくても入力しやすくする工夫は行われていますが、全ての環境でこのような機能が使えるわけでもないので、多くの方はこの体験の不便さに気付きつつも慣れてしまっている、というのが本当のところではないでしょうか。

Email Verification Protocol (EVP) はこの体験を大きく変えます。こちらの動画をご覧ください。

ユーザーはメールのリンクをクリックするどころか、メールクライアントを開くことなくメールアドレスの確認を完了しています。

EVP の何が魅力的なのか #

EVP がもたらす価値には、従来のメール確認が抱えていた数々の課題を、ユーザーにも開発者にも無理のない形で一掃してしまう点が挙げられます。

まずユーザー体験の観点では、 「これまでのメンタルモデルを一切壊さない」 という絶妙な美しさがあります。ユーザーは単に普段どおりフォームにメールアドレスを入力するだけで、メールアドレスの所有確認を行うことができます。メールアプリに切り替える必要もなければ、届いた OTP を暗記してコピペする必要も、マジックリンクを開いてアプリ内ブラウザに飛ばされる心配もありません。新しい操作を覚える必要はなく、「面倒な確認作業がいつの間にか終わっていた」という体験が得られます。OTP の手入力が不要になるため、入力画面を偽装したフィッシング詐欺に巻き込まれる隙も生まれません。

そして開発者やサービス運営者にとっても、導入のハードルが極めて低い設計になっています。EVP は プログレッシブエンハンスメント として機能するため、対応ブラウザや対応プロバイダであれば即座にバックグラウンド検証を行い、非対応の環境であれば従来の「確認メールの送信フロー」にそのままフォールバックさせることができます。既存の登録フローを壊すことなく、対応ユーザーから順に体験を向上させられるのです。

さらに、メールを開くために画面を離脱したきり戻ってこないというサインアップ時の離脱（ドロップオフ）や、「認証メールが届かない」というメール配信インフラの遅延・不達トラブルから解放される点も、サービス側にとって計り知れないメリットと言えます。

EVP ではメールアドレスの所有確認はできますが、疎通確認はできません。コミュニケーション目的で EVP を利用する際は、別途疎通確認を行うことをおすすめします。

Email Verification Protocol の仕組み #

EVP はどうやってメールクライアントを開くこともなく、バックグラウンドで安全にメールアドレスの所有確認を完了するのでしょうか。基本的なアイデアは、ブラウザとメールプロバイダが直接連携することにあります。

ユーザーがフォームにメールアドレスを入力、あるいはオートフィルで選択すると、ブラウザはそのメールアドレスをホストしているメールプロバイダに対して「このユーザーのアクティブなセッションが存在するか」を確認します。例えば Gmail アドレスを使った場合であれば、Google アカウントにログイン済みであるかを確認する、と言えば分かりやすいでしょうか。ユーザーがそのブラウザ上で対象のメールアカウントにすでにログインしていれば、プロバイダはメールアドレスの正当な所有者であることを証明する暗号化トークン（Email Verification Token: EVT）を発行します。

この時、メールプロバイダ側には「どの Web サイトが検証を要求しているか」という情報は一切伝わりません。ブラウザが仲介役となり、プロバイダから受け取ったトークンに対して、リクエスト元のサイトのオリジンやnonceをバインドした上でサイト側へ渡します。

サービス側は受け取ったトークンの署名をサーバーで検証するだけで、ユーザーがそのメールアドレスの正当な持ち主であることを確認できます。メールの送信を待つ時間も、受信トレイを開いてリンクを探す手間も、OTP のコピペも一切発生しません。

詳しいプロトコル仕様や実装手順については、Chrome for Developers のドキュメントやWICG の Explainerを参照してください。

そんな EVP ですが、実はパスキーによって大きく改善した認証機能を保管することで、アカウントライフサイクルの重要なピースを埋めるものと期待されています。それが何かを説明する前にはまず、パスキーが何を変えたのかを振り返ってみましょう。

パスキーは何が革新的だったのか #

アカウント乗っ取りの脅威が当たり前の近年、パスワードは長く複雑、かつサイトごとに異なるものが利用されなければなりません。しかしそんなことは普通の人間には当然不可能なわけで、だからこそパスワードマネージャーの利用が推奨されるのですが、ウェブサイト側から強制できない以上、別の方法でユーザーを守る必要があります。そこで、従来のパスワードに加えてメールや SMS でワンタイムパスワードを送信・入力してもらう多要素認証という方式が普及してきましたが、攻撃者はそれすらも乗り越えてたくさんのアカウントの乗っ取りを実現してきました。これがフィッシング攻撃と呼ばれるものです。人間が騙されて入力してしまう以上、フィッシングを防ぐには人間にクレデンシャルを入力させない、という選択をするしか方法はありません。

そこで登場したのがパスキーです。パスキーは公開鍵ペアを作り、パスワードマネージャーに秘密鍵（パスキー）を、サーバー側に公開鍵を保存します。認証時、ユーザーはクレデンシャルを自分で入力する代わりに、生体認証などでデバイスの持ち主であることを証明することをトリガーにパスワードマネージャーに保存されたパスキーで作った署名を送ります。サービスはサーバー側で公開鍵を使ってその署名の検証を行うことで認証します。この署名を作成する際、ブラウザがアクセス中の正規ドメイン（オリジン）の情報を認証器に渡し、その情報を含めて署名を作成するため、仮にユーザーがフィッシングサイトに引っかかってしまったとしても、サーバー側でドメインの不一致を検知して悪意のあるログインを防ぐことができる、という仕組みです。

パスキーがこれまでの認証方法と比較して革新的なのは、クレデンシャルの管理を強制的にパスワードマネージャーに任せることで、安全性と利便性のバランスが取れたフィッシング耐性のある認証方法を実現した、という点にあります。

パスキーにおける課題 #

パスキーによってログインのフィッシング耐性は手に入りましたが、実はアカウントライフサイクル全体にはいまだ解決されていない致命的な課題が横たわっています。それが 「パスキーが手元にないときの復旧（アカウントリカバリ）」 の問題です。

パスキーはデバイスやパスワードマネージャー内の安全な領域に秘密鍵を保持することで強固なセキュリティを実現しています。しかし、端末の故障や水没、紛失、あるいは異なるプラットフォーム間（例えば iPhone から Windows PC、Android から Mac など）の同期の壁によって、ユーザーがパスキーを使えない場面は必ず生じます。

手元にパスキーがない以上、サービス側はどうしても代替の認証手段（フォールバック）を提供せざるを得ません。しかし、現在世の中に存在する代替手段といえば、従来のパスワードや SMS、メールのワンタイムパスワード、マジックリンクといったものばかりです。

セキュリティの強度は「最も弱い部分」で決まります。どれだけログインの正面玄関をパスキーで固めたところで、裏口の認証手段やアカウントリカバリにフィッシング耐性のない手段を残していれば、攻撃者は当然そこを狙って攻撃を仕掛けてきます。パスキーを導入しても、代替手段が存在する限りアカウント全体のフィッシング耐性を保証することはできないという、根深いジレンマが存在しているのです。

EVP がアカウントリカバリを救う理由 #

ここで、EVP の話に戻ります。

多くの人は EVP のデモを見たとき、「フォームでメールアドレスを入力するだけで認証が終わるなんて、サインアップの手間が減って便利だな」という登録体験の改善に目を向けがちです。もちろんそれだけでも素晴らしい進歩ですが、EVP の本当の凄さはそこにとどまりません。

EVP が真に革命的である理由は、 「誰もが持っているメールアドレスを使って、フィッシング耐性のあるアカウントリカバリを実現できる」 という点にあります。

現在、多くのコンシューマー向け Web サービスでは、メールアドレス（地域によっては電話番号）が本人確認の主軸です。しかし、従来のメール確認や SMS によるワンタイムパスワードの所有確認は、中間者攻撃に弱く、フィッシング耐性を持たせることができません。

かといって、フィッシング耐性のある本人確認を行おうとしても、現実的な選択肢がほとんどありません。ID 連携をリカバリ手段として活用する設計は一般的ではありませんし、マイナンバーカードのような公的デジタルクレデンシャルによる身元確認にも期待は寄せられていますが、金融機関ならともかく、一般的な Web サービスで求めるにはユーザー心理的にもハードルが高すぎるでしょう。

「手軽だけどフィッシングに弱いか、堅牢だけど日常的なサービスには大げさすぎるか」。これまでのアカウントリカバリは、まさにそんな極端な二者択一を迫られていたと言えます。

そういった意味でも EVP は、この長年の難問に終止符を打つ可能性を秘めていると言えます。EVP で発行される EVT は、ブラウザによってアクセス中のオリジンと暗号学的にバインドされているため、攻撃者がどれだけ精巧なフィッシングサイトを用意しても、偽のドメインに対して有効なトークンが発行されることは原理的にあり得ません。

つまり、世界で最も普及している「メールアドレスの確認」というシンプルな手続きそのものにフィッシング耐性が宿るのです。ユーザーは専用アプリをインストールする必要も、身分証を提供する必要もなく、ただ普段使っているブラウザにメールアドレスを入力するだけで、安全に新しいデバイスへパスキーを再発行し、アカウントを取り戻すことができます。

日常の認証はパスキーで行い、有事のリカバリや新しいデバイスのセットアップは EVP で行う。これによって、ログインから復旧に至るアカウントのライフサイクル全体から、フィッシング耐性のない「脆弱な抜け道」の排除に一歩近付くことができます。 これこそが、EVP がパスキーによる新しいアカウントライフサイクルをより安全なものへと導く本質的な理由なのです。

残された課題 #

とはいえ、これはあくまで EVP が普及し当たり前に使えるようになった世界の話です。EVP はまだ Chrome にしか実装されていませんし、ステーブルで利用できるようになったわけでもありません。すでに Gmail が EVP をサポートしていますが、より多くのメールプロバイダーがサポートする必要もあるでしょう。そういう意味で、Chrome 以外のブラウザを使っている人や、Gmail 以外のメールアドレスを使っているユーザーは引き続きフィッシングに気をつけていかなければなりません。

また、フィッシング耐性のある本人確認のアプローチとして考えられているのは EVP だけではありません。例えば Firebase Phone Number Verification は、モバイルキャリアと直接連携することで、その端末に紐づく電話番号を検証済みのデータとして安全に取得することができます。他にもいくつかフィッシングに強い本人確認のアプローチが検討されています。

まとめ #

パスキーの登場によって、Web の認証は長年囚われてきた「パスワードの呪縛」からようやく抜け出し始めました。しかし、アカウントリカバリというピースが埋まらない限り、真のパスワードレスが完成したとは言えません。

Email Verification Protocol は、単にメール確認をスムーズにするための便利な機能にとどまりません。パスキーが抱えていた最大の弱点であるアカウントリカバリのセキュリティとユーザー体験のトレードオフを解消し、認証エコシステム全体を完成形へと導くための重要な一歩です。

各ブラウザやメールプロバイダにおける実装と普及はこれからの課題ですが、認証の未来を大きく前に進める一手として、今後の動向に大いに注目していきたいと思います。