JWTを使わないログインセッション管理

自社向けのサービスを作ってる時に、セッション管理部分で悩んだので、備忘録として残しておく。

自社向けのシステムでユーザがログインした後に、何か動作があるたびに、Cookieに置いてある、セッションIDを使って、DB(今回はDynamoDB)に照会しに行くとコストがかかる。

かといって、セッションIDの照会を減らすと、セキュリティ的な部分とユーザが利用する上で、不便な部分が出てしまう。

なので、ユーザの各操作でセッション管理しつつ、リクエストを減らしたセッション管理方法を見つけたい。

セッション情報をCookieで二つ持つ。

説明では、わかりやすくセッション情報「__Host-sid」と「__Host-auth」とする。

__Host-sidはログイン時にセッションIDとなるユニークキーを作成し、セッションの有効期限を設定し、DynamoDBに格納する。

DynamoDB格納時に使ったセッションIDをCookieに設定する。

__Host-authはログインなど含む操作などがあった際、セッションIDは持たずに署名済みのCookieに有効日時を持つセッション情報を用意する。

ユーザが何か操作をするたびに、APIサーバで__Host-authの有効日時が超えていないかを確認し、超えていなければ、セッションは有効と判断する。

超えていれば、__Host-sidのセッションIDをDynamoDBに照会をかけ、有効期限が超えているかを判定する。

超えていないければ、セッションは有効とし、新しい、__Host-authを返す。

超えていれば、セッションは無効とし、セッション切れのエラーを返す。

上記のようにすれば、__Host-sidの有効期限を超えてなければ、DynamoDBにリクエストされる回数を抑えることができる。

考えた、処理のシーケンス図はこんな感じ。

今回JWTを使っていない理由としては、セッションを最低でも24時間保ちたかったのと、各ユーザごとにロールを自前で割り当てたかったから。

ただ、管理めんどくさってなってJWTに戻る気はする。

セッション周りって考え始めると結構難しかったりするんだって気づけて、自分なりの考えをまとめられたので、よかった。