最初に思ったのは、「OAuth の面倒くさいところを、ちゃんとユーザー体験に落とし込もうとしているな」ということでした。
redirect URI の扱いって、ふだんは「セキュリティ上の制約だから仕方ない」で終わりがちですが、この記事はそこをもう少し丁寧にほどいています。管理者が一括で allowlist を持つだけだと、既存の大手クライアントには優しいけれど、個人が作った agent や週末に書いた MCP client は締め出される。逆に緩くすると phishing の穴になる。この二択の息苦しさは、読んでいてすごく納得感がありました。
面白かったのは、「信頼」をサーバー側の固定設定ではなく、サインイン時にそのユーザーが決める、という切り分けです。
これ、言われてみれば自然ですが、実装に落とすのは簡単ではなさそうです。登録時点では「誰がこの client を使うのか」がまだ分からないので、そこではゆるく受けて、authorize の段階で初めて“この人はこの host を信頼しているか”を見る。OAuth の危険なところって、たいてい「見た目は正しいのに、実は別の場所へ code を渡している」点にあるので、そこを user-owned な trust list で止める発想はきれいです。
ただ、読んでいて少し引っかかったのは、これでも phishing を完全には消せない、という割り切りです。
たしかに、相手に host を手で打たせるところまで誘導されたら終わりですし、そういう意味では万能ではありません。でも、少なくとも“1クリックで勝てる”状態から、“少し手数が増える”状態にはできる。セキュリティ設計って、よく「防げるかどうか」だけで語られますが、この記事は「どこまで被害を狭めるか」を正面から書いていて、その現実感は好きでした。
あと、拒否時の扱いまで気にしているのも印象に残りました。
Approve だけでなく Deny やエラーまで、勝手に attacker の redirect に飛ばさない。ここは地味ですが大事で、こういう“例外の扱い”が穴になることは本当に多いです。しかも typed host の確認や、メール通知、削除時の即時切断みたいに、人間の注意力を前提にしすぎない工夫が並んでいて、設計者がかなり執拗に攻撃経路を潰している感じがしました。そこは素直に好感が持てます。
一方で、こういう仕組みは運用の面倒さも増えるはずで、そのコストをユーザーがどこまで受け入れるかは気になりました。
「安全のために少し面倒になる」のは当然としても、どの段階で諦められるのか、どこからがユーザーにとってノイズになるのかは、実際に使ってみないと分からないと思います。そこは記事の中でも完全には見えませんでした。だからこそ、この設計がうまくいくかどうかは、理屈よりも実地の摩擦の少なさにかかっている気がします。
参考: MCP OAuth: let users trust their own redirect URIs safely
