はじめに
こんにちは！株式会社ブロードエッジ・ウェアリンク CTOの高丸です。
今回は、Qiita Advent Calendar 2024の12日目の記事です。
11日目の記事でも紹介しましたが、デザインリプレイス（アーキテクチャリプレイス）プロジェクトにおいて認証方法を変えました。
今回は、その切替にいたった背景や実装方法を詳しく解説していきます。
認証機能変更の概要
認証基盤の変更は、我々のシステム全体に大きな影響を与える重要な決断でした。
もともと弊社では、カルテのシステムに独自の認証基盤を持たせており、基本的なメールアドレスとパスワードによる認証を採用していました。
今回のリプレイスプロジェクトでは、ワインの好み診断における会員登録要件の緩和も同時に検討していました。
具体的には、これまで必須としていた会員登録を任意とする仕様変更を計画していたのです。このような大規模な変更が重なることから、我々は慎重にリリース計画を練る必要がありました。
診断機能のリプレイスと会員登録フローが密接に関連していることを考慮し、最終的に会員登録のリプレイスは後回しにして、ログイン機能の先行リリースを決断しました。
11日目の記事でも触れましたが、この移行において最も大きな技術的課題は既存ユーザーの移行でした。
既存の認証システムでは、パスワードは当然ながら暗号化して保存されていました。
これをShopifyの認証基盤に移行しようとすると、全ユーザーにパスワードの再設定を求める必要が出てきます。
一斉メールでアナウンスしてパスワード変更を呼びかけることも検討しましたが、この要請をきっかけに休眠ユーザーが増えることを懸念しました。
そこで我々は、メールリンク認証の導入を決定しました。
Shopifyでは customer_id という内部識別子が発行されますが、
これは主にAPI利用時に使用されるもので、メールアドレスでもユーザーを一意に識別できる仕様でした。
このことが、メールリンク認証への移行をより現実的な選択肢としたのです。
どう実装したか
メールリンク認証の導入を決めた後、認証基盤の切り替え設計に着手しました。
当初はShopifyが提供するメールアドレス認証機能の利用を検討しましたが、これには大きな課題がありました。認証画面が shopify.com ドメインで提供され、かつカスタマイズができないのです。
これまで我々のサービスではShopifyの存在をユーザーに意識させない設計を貫いてきました。
突然、見た目の異なる別サイトへリダイレクトされることは、ユーザーに不信感を与え、結果としてログイン離脱を引き起こす可能性が高いと判断しました。
そこで、メールアドレスのみで認証可能な別の基盤を探索した結果、Firebaseのメールリンク認証機能に行き着きました。
この方式であれば、リダイレクトは発生するものの、ユーザーに違和感を与えることなく認証フローを完結させることができます。
しかし、ここで新たな技術的課題が浮上しました。
あくまでこの認証はFirebase上での話であり、Shopifyでの認証完了を意味しないのです。
具体的には、Hydrogenで使うアクセストークンが取得できていません。
この問題に対して我々は、Shopifyが提供するMultipassログイン機能を活用することで解決を図りました。
以前のカルテシステムでも利用していた手法だったため、基本的な実装への不安はありませんでした。
ただし、今回はLiquidではなくHydrogen上での実装が必要となり、新たな挑戦となりました。
幸運にも、非公式ながらHydrogenからmultipassを実行するサンプルリポジトリを発見することができました。
これを参考に、Remixの機能を活用することで、サーバーサイドでのmultipassログインを比較的スムーズに実装することができました。
できあがった認証フロー
実際の認証フローは以下のようになります。
Firebaseを利用したメールリンク認証のイメージ
- ユーザーがログインを要求
- Firebaseのメールリンク認証を開始
- ユーザーがメール内のリンクをクリック
- Firebase認証完了後、Multipassログインを実行
- Shopifyでの認証完了
このように、複数のサービスを組み合わせることで、ユーザー体験を損なうことなく、セキュアな認証基盤への移行を実現することができました。
リリース後の影響
新しい認証システムのリリース直後は、さまざまなバグに直面しました。（現在は解消されております）
ログインセッションが予期せず切れてしまう問題でした。これは、エラーハンドリングとCookie管理の実装に起因するものでした。
また、CSRFトークンチェックに関連する問題も発生しました。
ログインを開始したブラウザと、メールリンクを開くブラウザが異なる場合、CSRFトークンが正しくセットされておらず、ログインができない状況が発生していました。
具体例でいうと、iPhoneでログインしようとした場合、ログインを開始した場合がChromeで、メールリンクをクリックしたときにはデフォルトのブラウザであるSafariが開かれる、といった事象です。
今回、割愛しましたが、カルテのシステムはこの時点では残っておりますので、新ログインでカルテもログインできている（シングルサインオン）必要がありました。これはShopifyのmultipassログインの仕組みを転用し、カルテでもセキュアにログインできるようにしてあります。
もちろん、バグだけではなく、UX面での批判的な意見も寄せられました。
「メールアプリに移動しなければならず面倒」 や、「パスワードマネージャーの自動入力が使えないため、かえって手間が増えた」 といったものです。
これらは確かに理解できる指摘です。
ただし、UIの変更には常に「以前の方が良かった」という意見が付きものだとも私は思っています。
我々は冷静にセキュリティ面を重視し、パスワード認証からの脱却という判断を堅持することにしました。
さいごに
現在、認証技術は大きな転換期を迎えています。
特にパスキーのような、パスワードを使用しない新しい認証方式が注目を集めています。
我々も、このトレンドを注視しており、次のステップとしてパスキー認証の実装を予定しています。
今回のメールリンク認証への移行は、パスワードレス認証への第一歩であり、今後のさらなる進化への布石となりました。技術の進歩は時として痛みを伴いますが、ユーザーの安全性と利便性の両立を目指し、我々は引き続き挑戦を続けていきます。
Discussion