Railsから、Frontend分離する際の認証
既存Applicationについて
Ruby on RailsベースのApplicationが存在する。
frontend フロントエンド部分は、Rails ServerがSSR Server Side Renderingして、クライアントに返している。
認証 Authentication
all Railsの場合、railsがいい感じに認証している。
deviseというライブラリが利用されていること多い。
heartcombo/devise: Flexible authentication solution for Rails with Warden.
認証
メアド、パスワード認証
メールアドレスの存在確認
SNS各種サービスアカウントを利用した認証
APIのためのトークン認証
CSRF Cross Site Request ForgeryTokenをHTMLに埋め込んで利用する
新規Applicationについて
前提
フロントエンドリアーキテクト フロリアにおいて、一部のpathをNext.jsといったアプリケーションに割り当てるようになる。
イメージ: CloudFront AWSなどで、該当URLがアクセスすべきアプリケーションを振り分ける。
あるpath以下: Next.js app
それ以外: Ruby on Rails
ログインしている状態
Ruby on Railsappでログイン済み→Next.js appにアクセス
Next.jsappでログイン済み→Ruby on Rails appにアクセス
疑問
Frontend分離時、Next.js appとRuby on Railsappのログイン状態はどうやってシームレスに合わせるのか。
そのブラウザがログイン済みであること(セッション Session webの保持)は誰がするの？
詳細: あるブラウザのアクセスがログイン済みであることを判別する。
そのリクエストに、識別するためのアクセストークン Access Tokenなどが必要。
考えるべきこと
何ログインに対応するか
メール&パスワード認証
SNSログイン
Passkeysもいつか利用したいな。
ユーザー情報は何が持ち、ユーザー識別のためのトークンはどこが発行するのか
1. Paas(Firebase Authenticationなど)が持って、Paasが判断
Client(アクセストークン Access Tokenが不正、もしくは無い。)→認証サービスでログイン→ログイン済みページへ。(Clientで、アクセストークン Access Tokenを保持)
詳細な仕組み分かってない。間違っているかも。
2. Databaseが持って、Backend Server(Ruby on Rails)が判断
Client(key)→Next.js Server→RailsServer(該当Keyが問題ないか確認)→Next.js Server →Client
※Next.js Serverから、Databaseに直接アクセスして確認出来るが、役割がおかしくなるのでやらない。
アクセストークン Access Tokenの渡し方
Cookie クッキー
Next.js ServerでFetchしたいので、第一候補
JWT Json Web Token（+ Authorization Header ヘッダ）
Server側でAPI叩く時に詰む？
疑問
メアド認証とSNS認証の違い。
Firebase Authenticationを使っていない場合の話。
並列でNext.jsServerがある時、複数Serverのうちの、１つだけで認証がされたことになっって、他のServer上では再度認証必要になったりしない？
Paasを利用していない状態から、Paasを後から利用って可能なんだっけ？
仮にできる場合はメリデメも言語化したい。
読んだ
パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
こわいよね。
いまNext.jsで新規サービスを立ち上げるときの観点（Router・CSS・認証・監視など/2023年末）
app routerにおける、認証の思考がある。
特に認証について考えるときの観点が分かりやすかった。
RailsのCSRF保護を詳しく調べてみた（翻訳）
あまり分かっていなかったことが大体分かった印象。
Microservices における認証と認可の設計パターン
分かりやすい。おすすめ。
認証基盤の統合をダウンタイムゼロで実現した6ヶ月に渡る準備
具体的な期間などわかりやすい。
思考
認証、認可するAPIなどを提供し行うのは、1つのBackend
複数台スケーリングすることは全然ある。
複数のサービス(FE app)がある。
仮で、Next.js App router構成で、FE Serverを持つとする。
その場合、Client側でAPIを叩かなくて良い。
Server Actions伝いで叩く。
その場合、Client側から行うことによるデメリットはいくつか軽減できるとする。
複数台スケーリングすることは全然ある。
FEにおいては、一貫したログイン、ログアウト体験がほしい。
一部のサイトをリアーキテクトする場合、同じような体験であってほしい。
各FE Appで、会員機能がある箇所を非ログインユーザーが実行しようとした場合、Sign-in/Sign-upできるPopupなどで、同じような体験ができ、ログイン状態は共通して欲しい。
段階的にできないのか？
0. 新アプリケーションではログイン状態を利用できない。
体験
単ログインに関する情報やユーザー情報は極力無い、見せない。
実現にあたり
ベースのアプリケーションの用意
ログインに関する情報やユーザー情報の文言は工夫する。
1. 新アプリケーションに、ログイン状態は共有できるが、ログイン/会員登録を行う際は、旧アプリケーションで行ってもらう。
イメージ
1. 新アプリケーションにて、ログインが必要な機能を利用しようとする。
2. ログイン/会員登録してねPopup出す。
ログインページ or 会員登録ページのリンクを出す。
3. 旧アプリケーションの、ログインページ or 会員登録ページで認証
4. 新アプリケーションの遷移元に、リダイレクト
実現にあたり
旧アプリケーションで、redirectさせる仕組みが必要。
同じドメイン以下の別path(別アプリケーション)で、状態を共有できる必要がある。
ユーザー情報取得API
ヘッダーなどに、ユーザー情報を表示することを想定。
2. 新アプリケーションで、ログイン/会員登録を行え、その状態を旧/その他アプリケーションに共有できる。