マジックリンク認証の落とし穴

TL;DR

• 主にモバイル端末からの利用において、ユーザーが手間取ることが多い
• エンジニアなど、リテラシーが高いユーザー層を対象にした場合にのみ利用したほうが良さそう

マジックリンク認証、使ってますか？

マジックリンク認証とは、メール内に記載されたリンクを踏むことで認証が完了する認証方式です。パスワード流出のリスクが無いことから、パスワード認証に比べてセキュアな点が特徴です。

https://www.itmedia.co.jp/enterprise/spv/1712/05/news036_2.html

Slackが採用しているため、ユーザーの立場で使ったことがある人は多いと思います。

筆者は一時期Firebaseを多用していたのですが、Firebase Authenticationを使用すると簡単にマジックリンク認証を実装することができ、またパスワード設定/変更/忘れ等を考慮する必要がないことから実装の手間を省けると考え、個人開発のプロダクトで採用しました。

実際開発は短期間で終わり、最小限のコード量で済んだことから、便利なものがあって助かったと喜んだのを覚えています。

…リリースするまでは。

何が問題だった？

ここからは、実際にリリースしてから発覚した、マジックリンク認証の問題点を3点上げていきます。
※以下はすべてFirebase Authenticationを使用した際の内容となります。
※解決策のある方や、運用でうまくカバーしている方がいらっしゃったら、ぜひコメントください。

1. プレビュー表示で認証ロジックが動作してしまう

iOS端末でリンクを長押しすると、小さいウインドウが開き、リンク先の画面がプレビュー表示されますが、その際に認証ロジックが動作してしまいます。

結果、再度リンクを踏んだ時には、ログイン試行済みと見なされログインに失敗します。ユーザーは最初からやり直し、マジックリンクをもう一度送信する必要があります。

2. アプリ内ブラウザでログインしてしまう

メールアプリ上でリンクを踏んだ際に、アプリ内ブラウザで開いてしまうと、当然普段利用しているブラウザアプリではログイン状態となりません。

筆者は当時デフォルトでブラウザアプリに遷移するように設定していたため、この問題に気づくことなくリリースを迎えてしまいました…。

（後にユーザーから「毎回イチからログインする必要があるのか？」というお問い合わせがあり、ヒアリングを進める中で問題が発覚しました）

3. アプリ審査の際にログイン手段を提供できない

スマホアプリにおいて、マジックリンク認証の他にログイン手段がない場合、審査の際にも苦労することになります。

パスワード認証の場合は、テスト用のIDとパスワードを払い出せば良いだけですが、マジックリンク方式の場合は実際に使われているメールアドレスでなければなりません。

当然テスターが使用しているメールアドレスを事前に知ることはできないため、どうにか別の形でテスト用のログイン手段を提供する必要があります。

まとめ

3つ目の問題に関しては、テスト用のアドレスのみ別のログイン手段を提供するなどして対応することもできますが、その他に関しては認証方式固有の問題だと思います。

Slackに代表されるようなTech系ユーザーが比較的多いサービスを除いて、セキュリティを担保したいのであれば、二要素認証など別の方策を取るほうが無難かつセキュアです。

逆に、リテラシーの高いユーザー層に対して、手軽にセキュアな認証方式を提供したい場合には、マジックリンク認証はうってつけです。

皆さまにおかれましては、どうぞ適材適所な認証方式を選択ください。