メール確認に関する更新(2026 年 10 月)

公開日: 2026 年 10 月 5 日

メール認証のオリジン トライアルが継続される中、皆様からのフィードバックに基づき、さらなるアップデートを実施しました。これ以上の破壊的変更は想定しておらず、この機能をリリースする準備を進めています。また、メール認証に関する新しいドキュメント セクションをリリースしました。このセクションには、検証者と発行者専用のセクションがあります。

メールアドレスの確認のオリジン トライアルが、パソコン版 Chrome 150 で開始されました。デベロッパーからのフィードバックとエコシステム全体でのテストを踏まえ、実装の改善を続けています。この記事では、Chrome 154 のアップデートについて説明します。Android のサポート、サードパーティのオリジン トライアル、トークン検証時のキー検出処理、メール プロバイダのヘッダーの更新などについて説明します。

ユーザー向けの更新

ユーザー インターフェースまたはユーザー向け動作の変更。

Android 版 Chrome のサポート

Chrome 154 以降では、Android 版 Chrome でメールアドレスの確認がサポートされます。API またはプロトコルは変更されないため、検証ツールやプロバイダは変更を行う必要はありません。ユーザーがブラウザでメール プロバイダにログインしている必要があるなど、同じ前提条件が適用されます。

設定には、[設定] > [住所など] > [確認済みのメールアドレス] からアクセスできます。

確認者の更新

メールを収集して確認するサイトの変更。

サードパーティのオリジン トライアル

Chrome 154 以降では、メールの確認にサードパーティのオリジン トライアルがサポートされています(問題 534377131 を参照)。埋め込みスクリプトまたは ID SDK を提供している場合、サードパーティ トライアル トークンを登録して、スクリプトをホストするページに挿入できるようになりました。スクリプトを埋め込むウェブサイトで、個別のオリジン トライアル トークンを登録する必要はありません。

重要な注意点として、オリジン トライアルの登録者と発行者は同じサイトである必要があります。具体的には、トライアルに登録されたオリジンは発行者のドメインと一致する必要があります。

サポートされている構成:

  • カード発行会社のドメイン: issuer.example
  • OT 登録者: https://issuer.example
  • JavaScript 生成元: https://issuer.example(または https://app.issuer.example(サブドメイン一致))

サポートされていない構成:

  • サブドメイン登録者: 発行者のドメインは issuer.example ですが、OT 登録者は https://app.issuer.example です。
  • クロスサイト登録者: 発行者のドメインは issuer.example ですが、OT 登録者は https://different.example です。

EVT で省略可能な kid を処理

メール確認トークン(EVT)を検証する際、サーバーはプロバイダの JSON Web Key Set(JWKS)を取得して、発行者の暗号署名を検証します。鍵には、必要に応じて kid 鍵識別子を含めることができます。この識別子は、トークンの署名に使用された鍵を示す JWT にも必要に応じて含まれます。トークンに kid クレームが含まれていない場合(Gmail など)、キーを反復処理して正しいキーを見つけます。ドキュメントとデモに、このためのコードが示されています。

email クレームをそのまま返す

Chrome 156 以降では、トークン内のメールアドレスは、フォーム送信で指定されたとおりに返されるようになります(問題 549217427 を参照)。以前は、発行者がアカウントの正規メールアドレスを返すことがありました(たとえば、フォーム送信に first.last@example.com が含まれている場合に First.Last@example.com を返すなど)。返されたメールアドレスに対して大文字と小文字を区別しない比較を行うことは常に良い方法であるため、これは破壊的変更にはなりません。

プロバイダの更新

メール プロバイダ向けの変更。

email クレームをそのまま返す

プロバイダ側では、この要件はより厳格です。プロバイダが提供されたメールアドレスをそのまま返さない場合、Chrome はトークンを拒否します。これにより、確認メールの送信で明らかになる以上のデータが公開されるのを防ぐことができます。メールの配信と同じ方法で、受信メールをログイン ユーザーと照合して検証します。

Sec-Fetch-Dest を email-verification に名前を変更

Chrome 154 以降では、トークン発行リクエストで送信される Sec-Fetch-Dest ヘッダーがハイフンを使用するように更新されました。

  • Chrome 154 以降: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

この変更により、ウェブ プラットフォームの命名規則に沿ってフェッチ先識別子が標準化されます(問題 546618576 を参照)。

発行エンドポイントで Sec-Fetch-Dest ヘッダーを検証している場合(CSRF と意図しないリクエスト コンテキストから保護するため推奨)、email-verification を受け入れるようにチェックを更新します。ブラウザのロールアウト中に中断が発生しないように、移行中は両方の値を受け入れます。

リソースとフィードバック