ritou です。
いわゆるマジックリンク方式ってのは「メールなどで推測困難なURLを送ってクリックさせたらあれこれする」ものです。 最近のパスワードレスを目指す風潮の中で、様々な人がこの方式をログインに利用することを検討したり話題に出したりしています。
個人的にはこの方式はなかなかクセが強く、 ログイン方法としての採用できるサービスを選ぶもの だと思っています。 今回は、このような検討の際にどの辺を意識したらいいかについて整理しましょう。
最近の関連記事
最近はこんな記事が出ていました。
マジックリンク方式を唯一のログイン方法に使うべきではない4つの理由 ですね。
- 複数デバイスでの利用
- リンク送信時の遅延
- モバイルアプリのあたりの使い勝手
- 仕事用端末で個人用のメールにアクセスする必要が出てきたりしそう
みたいな理由でパスキー認証を使えやという主張です。最後のは必ずしも混ぜるな危険にならない使い方はある気がしますが、概ね同意です。
その続きのように、自分のマジックリンク方式に対してのお気持ち、そしてマジックリンク方式とパスキー認証の組み合わせみたいなとこに触れている記事が出ていました。
この記事で +1 したい部分は 「Passkey Autofillを使ってメアド入力フォームでパスキー認証を利用可能にする、使えない場合でも既存の認証方式にフォールバックできる」 ってところで、ログイン方法としてのマジックリンク方式の考察はそんなにでもないです。
そして、この記事で参照されている404の記事ですね。
マジックリンクは完全ではないことは知ってる、けどパスワードは絶対使わないマン です。
全体を見ると、 パスワード認証やめてマジックリンク方式、そこからパスキー認証を導入する流れについての考察 というところでしょう。
自分の考えともそんなに変わりませんが、ここで今一度マジックリンク方式の特徴、ログイン機能との相性みたいなところを整理してみましょう。
特徴
今回はこの辺りに注目します。
- 利用対象
- 導線
- 外部ネットワークの利用による遅延や障害
- フィッシング耐性
利用対象
当然ですが、サービスがリンクを送信する方法、つまりEmail/SMSなどが利用可能であることが条件となります。 Emailは一般的と言えますし、既存の認証方式に比べて対象者を制限してしまうことはないでしょう。 SMSでリンクを送るとなると、これまでライトな複数アカウント対策などで使われていたようにSIMを準備できる環境という制限があること、送受信に伴う費用についても考慮は必要です。
導線(動線か?わからん)
この方式でログインできるのは、最終的にメールを読んでリンクをクリックした環境になります。
デバイスレベルで言うと
- スマートフォンを利用していて、同一スマートフォン内のメールアプリを使っている
- スマートフォンを利用していて、別のスマートフォンやPCで動作するメールソフトやWebメールを使っている
- パソコンを利用していて、同一PCで動作するメールソフトやWebメールを使っている
- PCのブラウザやソフトを利用していて、スマートフォンや別のPCで動作するメールソフトやWebメールを使っている
となり、さらにリンクをクリックする挙動としても
- Webメールでクリックしてそのままブラウザで開く
- メールソフト、メールアプリ内で開く
- URLをコピペして...
というところで、なかなかのバリエーションが出てきます。これが良いか悪いかの判断について、提供するサービスの特性の考慮が必要です。
- サービスの多数派ユーザーが上記のどのケースに当てはまるのか
- リンクが開かれた場所とログインしたい環境が一致するのかどうか
- 一致しない場合、どのようにフォールバックするのが適切か
などを見極める必要があります。
外部ネットワークの利用による遅延や障害
これは英語の記事と同じですね。届かなかったり遅れたりします。
フィッシング耐性
この方式では、最終的にアクセスするのはサービスの正規のURLとなります。
攻撃者としては、そのURLをユーザから共有してもらえたら、それを使って攻撃者のパスキー登録できる状態になる。 が、通常のログインにおいて、URLをフォームに入力するとか、不自然すぎるからなのか、みたことない。 Emailだったら、HTML mailにしたらURLは簡単に取れないし、さらに難しくなるだろね。
最後のリンククリックの際に正規のURLとなるところで、シンプルにパスワードを奪いにくるレガシーなフィッシング攻撃、URLだけ違うリアルタイムなフィッシング攻撃がそれだけでは通用しないよねという話です。
この辺の過激派としての意見としては、世の中のより広義のフィッシング対策の 怪しいメールのリンクはクリックしない という啓蒙と、この送られてきたメールのURLをクリックするというお作法の相性が気になります。 個人的には別の方法に変えていく必要がありそうですが、難しいところです。
ログイン機能との相性
パスワードリセットとの相性
ログイン機能との相性を考える前に、パスワードリセット機能においてマジックリンク方式が採用されてきました。これはなぜでしょうか？ それは、パスワードを再設定したい環境とログインしたい環境が必ずしも一致する必要がない ためです。
一般的なパスワードリセット機能は 身元確認 と パスワードの再設定 によって構成されます。
メールを受信したことを持ってユーザーとみなす ことが身元確認であり、そのURLから パスワードの再設定 を行うというのが自然に出来上がったわけです。 サービスによって、上記の処理に加えてログイン状態にしたりもします。
特にこれまではパスワードは 記憶する 前提でした。推測困難、サービスごとに別、正規のサービスのみに入力する という要件を人類が満たせるとは思いませんが、できる場合は「パスワードの再設定」を行う環境に制限はなくなります。 これが、幅広く利用されてきた理由と言えるでしょう。
しかし、今後はどうでしょうか。いつも言っているように、人類はパスワードを記憶するのではなく信頼するシステムに任せることが重要であり、パスキーもその延長です。 ユーザーが登録できるパスワードは一つなのが一般的です。パスワードマネージャーを利用しているユーザーは、いつものパスワードマネージャーが動作もしくは同期する環境で パスワードの再設定 を必要とします。 これを考えるとマジックリンク方式との相性はこれまでよりも悪くなる可能性もある気がしています。
新規登録、ログイン機能との相性
新規登録機能についての考え方はパスワードリセットと似ています。
一般的な新規登録機能は 身元確認 と パスワードの設定 によって構成されるのでそこまでは一緒です。
メールを受信する環境と新規登録したい環境の違い については次のような設計、実装があります。
- マジックリンクをクリックした環境で登録処理を完了させ、元々使いたい環境では一度ログインして使わせたらOK
- 裏で状態管理とかポーリングの仕組みを用意しておき、マジックリンクをクリックした環境で登録処理を完了したら元々使おうとした環境が「登録完了するの待ってるね」から「ログイン状態」にする
ログイン機能についてはより、メールを受信する環境とログインしたい環境の違い が無視できません。 そして、新規登録と同様に マジックリンク方式を使いつつログインしようとした環境をログイン状態にしたらいいじゃないか というわけでもありません。 それをしてしまうと、通知を受けた認証アプリで「ログインする」というボタンをクリックすることでログイン状態にする方式に寄っていき、フィッシング耐性のところで触れた特徴がひっくり返ってリアルタイムなフィッシング攻撃に弱い方法となってしまいます。
英語の記事では色々書いていましたが、やはりこの環境の違いを考慮することが一番重要だと思います。 統合IDや認証基盤といったところになると、それを使うサービスの特性がこの辺りの判断に影響します。 個人的にはログイン方法としてはマジックリンク方式の採用を避けるお気持ちになることが多いです。
マジックリンク方式とメールOTPのハイブリッドな方式
話は少し逸れますが、マジックリンク方式とメールOTPのハイブリッドな方式ってもあります。しかも結構前から。 こちらは頼まれてもいないのにリリース直後の他社サービスの新規登録/ログイン機能を解説した記事です。
(最近は見てないので当時の)bosyuでは、ブラウザの環境(PC/Mobile)によって、マジックリンク方式なのかOTPとのハイブリッドなのかを判断しているように見えました。 環境が異なるときはURLをコピペさせる案内もしています。クロスデバイスやモバイルアプリの利用についても、この辺りはよく考えられた設計といえます。マジックリンク方式を早い段階で採用したmediumもこんなだった気がしましたが、忘れました。 当然、考慮しなければいけないことも増えるわけですが、頭の中で マジックリンク方式はこういうフローで、ダメならやり直し だけではなく組み合わせるという柔軟さは持っていたいところです。
まとめ
まとめです。
- 最近、パスキー絡みでマジックリンク方式のログインについて書かれることが増えてきた
- 特徴を見ると、やはり認証フローを開始した環境とメールを受信する環境の違いの部分が重要
- パスワードリセット、新規登録、ログインという代表的な機能との相性を見ていくと、ログインとの相性が良くないと判断されるケースが一番多そう
- メールOTPとのハイブリッドな方式の採用例もある
検討時のポイントを書いたつもりが自分が採用しない理由になっている気がしますが、やはりUXは重要です。
開発者観点ではつい こうすればできる を考えてしまいがちですが、様々な状況が考えられる中で ユーザーがうまくやる ことを前提にするのはとても危険な思考であることはこれまでの状況を見てわかるはずです。 パスキー認証と同様、認証方式においては 大多数のユーザーが特に意識せず、あまり頑張らずに使える方法 を用意することが重要です。 要は個別具体で考えるしかないおじさん と言ってしまうとそれまでですが、この辺りを考える際は意識しておきましょう。
ではまた。
