SSRなNuxt .js×FIrebaseのユーザー認証（ログイン周り）の個人的ベストプラクティス

どーも、ぐるたか@guru_takaです。

SSRモードのNuxt.jsとFirebase Authenticationにおけるユーザー認証のベストプラクティスを自分なりに模索しました。

色々と試した結果、個人的に１つの答えにいきついたので、以下にまとめます。異論もあるとは思いますが、私の一意見として、ご覧いただければ幸いです。

スポンサードリンク

結論：Cookie Storageを使ってユーザー情報を永続化する

結論からまとめると

やり方は以下の記事に全て書かれているので、ぜひ参考にしてみて下さい。vuex-persistedstateとjs-cookieで簡単に実現できます！
参考 Nuxt.js で SSR 時にも永続化された store の値を使う - Qiita

ただし、Cookie Storageにstoreのデータを保存する場合は、サイズも重要になってくるので注意しておきましょう。
参考 cookieでvuexのstoreをリロードしても維持する方法 - Qiita

ここからは、なぜ、Cookie Storageによるユーザー認証がベストプラクティスという結論に至ったのか、私なりの道のりを紹介していきます。

色々と調べてみると、sessionやcookieで、認証情報を永続化する方法が出てきます。

結論、自力で実装するとなると、かなり大変で工数がかかります。また実装の難易度も跳ね上がるので、一旦保留にしました。

SSRなNuxtとFirebase Authのユーザー認証周りで、よく出てくるのがService Workerのセッション管理を使用する方法です。公式含め、色んな方々が有益な情報を残しています。

私も実際にやってみて、やり方を記事にまとめています！

ただ実際にやってみると、ユーザー認証がサーバー側でできるのですが、以下の問題点が残って解決できませんでした。

ハードリロード, スーパーリロード時は、ユーザー認証できません。なぜなら、Service Workderを通じて、リクエストされないからです。

その結果、クライアント側でのFirebase Authの認証によって、ユーザー認証されます。ここで、サーバー側と描画が異なった場合（例えば、ヘッダーにユーザー名が表示される等）、コンソールログでエラーが吐き出されます。

また、私の観測範囲ですは、Service Workerのセッション管理をする際に、process.env.~~~~が使えないので、ビルドした際に、重要なキーが漏洩してしまう恐れがあります。

そのため、実際に使用するわけにはいかないと思い、Service Workerを利用したユーザー認証を断念しました。

Service Workerのセッション管理で、ハード/スーパーリロードに対応する方法を模索していたところ、Cookie Storageという手段を見つけました。

ここで、「そもそも、セッション管理さえいらないじゃん！」となったわけです。

ベストプラクティスと感じた理由は

が挙げられます。APIキーも外部に漏れる心配もないので、セキュリティ面も安心です！

以上になります。Nuxt×Firebase Authが絡んでくると、色々と複雑になるのですが、Cookie Storageでスッキリ解決できました。

もちろん、これ以外にもベストプラクティスはあるかもしれないので、その時はぜひコメントにてご教授いただきたいです！

そして、SSRなNuxtアプリとFIrebaseのユーザー認証の方法で悩んでいる方の参考になれば幸いです。

スポンサードリンク