SSRで認証をどうするべきか？

既存プロジェクトにNext.js等のSSRを導入する場合は既存の認証機能を維持したり活かしたりする必要があります。しかしSSRの認証とCSR(SPA)の認証は同じではなく、簡単に共有できるものではありません。 ここでは複数のテックブログの事例を見ながら、この難しさと本物のウェブサービスで採用された解決策を見ていきます。 CSRとSSRの認証の違い まず最初に、CSR(SPA)とSSR[1]の認証の違いをざっくり紹介します。技術的制約を理解していただくことが目的です。 クライアント視点では、認証システムは突き詰めると、トークン(鍵)[2]を安全に保管し、必要時にサーバに渡す(鍵穴に差し込む) ことです。この２つに絞って解説します。[3] https://www.flaticon.com/free-icons/vault (by IYIKON) https://www.flaticon.com

[renowan]

セキュリティ的に別ドメインは避けたいから自分ならBFFを立てる。

[ritou]

"JWT認証"も然り、認証と言いつつ厳密にはセッション管理とリソースアクセスの手法についての話。この辺りはもう少しそれぞれの特徴、ハイブリッドにする際の検討事項などが揉まれて共通認識になると良いですね。

[tofu-kun]

一般的には同じドメイン構成が多い気がする

[prograti]

バックエンドのAPIサーバーは複数の異なるアプリにAPIを提供するからドメインが別というのは珍しくないかと

[aox]

相撲相撲レヴォリューションですね

[snowcrush]

CSRのバックエンドとSSRサーバーを分けて別ドメインで運用するパターンでの課題の話みたいだけど、この構成はあまり一般的じゃないような？界隈によってはこういう構成が多いところがあるの？