💣

セッションが確立されていないFE/BE間でトークンを用いて簡易的なセッションを実現する

2022/03/06に公開

ritouです。

何の話か？

このあたりの話です。

SPAやネイティブアプリといったフロントエンドと、バックエンドサーバーを組み合わせたサービスでID連携を行う際、バックエンドサーバーを起点、終点としたフローを考えられるとセキュアにできますよ、みたいな話を前に書きました。

次に、認可サーバー/リソオースサーバーとのやりとりを Backend Server に任せるパターンです。

リソオース...

前提として、モバイルアプリやSPAとBackend Serverの間にセッションが確立しており、Client は認可リクエストのURLにリダイレクトするだけ、認可レスポンスのパラメータを Backend Server に送るだけです。

このセッションが確立している前提について、ログイン後のID連携などではセッションが確立されているが未ログイン状態のソーシャルログインではセッションが確立されていない！どうすればいいんだ！って話もあるかと思います。

そこでこのTweetですね。

立場上、サービス間の連携などではなるべく標準化仕様になってるプロトコルを利用すべきってなことは良く言いますが、FE/BE間のやりとりは利用している仕組みに応じて危なくない方法で実装してもらえばと思っています。

という立ち位置において、セッションのない状態で簡易的なステートフルアクセスを実現するために次のような設計、実装をすることがあるのですこし紹介します。

(図をここに書くつもりだったがめんどい)

今回の話で言うと、BEはOIDCの認証リクエストを生成しつつ

といった辺りを後から確認できるようなセッショントークンも同時に生成し、FEに渡します。

FEはどうにかしてそのトークンを保持しつつ、認証リクエストをIdPに送ります。

IdPから認証レスポンスが戻ってきたら、保存していたセッショントークンと一緒にBEに送るわけです。後はもういいよね。

FEのやることはシンプルだし、BEにロジックを集約できるので個人的には満足してる設計です。

もちろん自分で実装するときはeyJなやつとデータストアの組み合わせですが、一般的なセッションの要件を満たせたら何でも良いでしょう。

この簡易なセッショントークンのしくみの用途はID連携に限りません。

といったように、ログインセッションがない状態から複数リクエストを用いて実現する処理との相性が良いでしょう。

簡易的なセッションの機能を実現するためにトークンを使うアイディアを紹介しました。
SPAではないレガシー？なWebアプリケーションをメジャーなフレームワークで動かそうと思うと

ってやって担保されてた部分をサーバーサイドをAPIベースにしたときにどう実現できるか？というお話と読み替えてみても良いかもしれません。

ではまた！