メールアドレス所有確認のフォールバック設計
Email Verification Protocol (EVP) は何を証明するのか を使えない環境でも、秘密の招待 URL とは独立して「招待先メールアドレスを現在コントロールしている」ことを確認する手段はある。
重要なのは、招待 URL 自体を認証要素として数えすぎないことである。秘密の招待URLは「本人」を証明しない
1. Redemption時に新しいメールOTPを送る
最も広く使えるフォールバックは、招待 URL を開いた時点で対象メールアドレスに新しいワンタイムコードを送信し、そのコードをブラウザで入力させる方法である。
最初の招待メールに書かれた URL が漏れても、攻撃者が対象メールボックスへ新たに届く OTP を読めなければ引換を完了できない。招待メール内の URL 自体を magic link として即時ログインに使う方式とは保証が異なる。
ただしメールが自動転送されている場合や、メールボックス自体が共有・侵害されている場合には防げない。これは「メールアドレスのコントロール」を認証根拠にする方式全体の限界である。
2. OIDC / federation の verified email を照合する
Google、Microsoft Entra ID、その他の IdP でログインさせ、IdP が返す verified email と招待先メールアドレスを一致確認する方法もある。
UX は良い場合があるが、すべてのメールドメインを単一 IdP でカバーできない。企業ドメインではホーム IdP の discovery や federation 設定も必要になる。このため一般向けサービスでは OTP と併用されることが多い。
3. 既存アカウントの verified email に束縛する
サービスに既存アカウントがあるなら、ログイン済みアカウントの verified email と招待先を一致させる方法が単純で強い。
GitHub Organization のメールアドレス指定招待はこの考え方に近く、招待先メールアドレスが、その GitHub 個人アカウントに登録された verified email と一致しないと受諾できない。招待リンクとメール所有確認を分離している実例
4. 既登録のpasskey等を使う
過去に本人との関係が成立している利用者なら、メール所有確認よりも、既登録 passkey や組織 IdP で直接認証した方がよい。これは「メールを持っている人」ではなく「以前登録した主体」を再認証できる。
一方、初回の匿名ゲスト招待では通常この前提がない。
現実的な優先順位
一時ゲストを広く招待するサービスなら、当面は次のような段階的構成が現実的である。
- EVP が利用可能なら EVP
- 招待先のホーム IdP を安全に利用できるなら federation
- それ以外は redemption 時の email OTP
- リスクが低い用途に限り、明示的に bearer link 単独を許容
ここで重要なのは、EVP を「OTP を完全に置き換える完成済み標準」として扱わないことだ。2026年8月時点では対応範囲が限定されるため、EVPで招待URLを招待先メールアドレスに束縛する を実装してもフォールバック経路は必要になる。