タラバガニー設計局stalins.clubNOTE/notes/invite-link-is-a-bearer-capability

秘密の招待URLは「本人」を証明しない

秘密の招待 URL は、通常は URL に含まれる十分にランダムなトークンを知っていることをアクセス条件にする。この設計は便利だが、そこで証明されるのは招待された人物であることではなく、そのトークンを現在所持していることである。

つまり秘密 URL は bearer capability として振る舞う。転送、チャットへの貼り付け、Referer やログへの漏えい、スクリーンショット、誤配送などで別人が URL を取得した場合、その別人も原理上は同じ権限を行使できる。

「メールで送った」ことと「メール所有者が操作した」ことは違う

alice@example.com に秘密 URL を送ったとしても、サイトが観測できるのは「その URL がブラウザから開かれた」という事実だけである。HTTP リクエストそのものには、そのブラウザを操作している人が alice@example.com をコントロールしているという証拠は含まれない。

この差が問題になるのは、たとえば既存ユーザーが外部の相手を一時的に招待し、招待された相手にアカウント作成を要求したくないケースである。URL だけで権限を与えると、招待 URL の転送先も同じ権限を得られる。

何を追加すればよいか

必要なのは、招待トークンとは独立した別の証明を redemption 時に要求することである。

  • 招待先メールアドレスを現在コントロールしていることを確認する
  • 既存の IdP で認証し、verified email が招待先と一致することを確認する
  • 既存ユーザーなら passkey など既登録の認証器で本人確認する

EVP は一つ目を、メール送信を伴わずブラウザ仲介で実現しようとする仕組みである。具体的な組み込み方は EVPで招待URLを招待先メールアドレスに束縛する を参照。

限界

メールアドレスのコントロールを確認しても、「本来招待したかった自然人」であることまでは証明できない。共有メールボックス、転送設定、委任アクセス、侵害済みメールアカウントなどでは複数人が同じアドレスを事実上コントロールしうる。

したがって、要求する保証が「そのメールアドレスを現在使える人」なのか、「特定の自然人」なのかは分けて考える必要がある。EVP が扱うのは前者である。Email Verification Protocol (EVP) は何を証明するのか

▸ ノート一覧に戻る