ritouです。
Digital Identity技術勉強会 #iddance Advent Calendar 2025の12/11の記事です。
会員サービスを提供するにあたり必要となるID管理機能について、重要な考え方としてユーザーIDの状態と状態遷移を表現するアイデンティティライフサイクル(Identity Lifecycle)というものがあります。
ユーザーがとりうる状態(未登録、登録済み、サスペンドなど)とその遷移にあたる処理(登録、一時的な無効化、退会など)を意識することで、どの機能を実装すべきかの検討に役立つでしょう。
しかし、ID管理にはこれに関連しない機能がいくつかあります。 例えばログイン、ログアウトなどはユーザーの状態と無関係ではないものの、状態遷移にあたるものではありません。 これらの機能はいわゆるセッション管理に関するものであるため、別の軸としてセッションライフサイクルのようなものがあったら実装する必要のある機能を意識できるのではないか というのがこの記事の趣旨となります。
この内容はどこかのドキュメントに書かれているものではなく考えてみた程度なので、ご了承ください。
セッションライフサイクル(仮)
今回の話は、単一サービスにおけるセッション管理を想定します。 最もベーシックなクライアント-サーバ構成でセッション情報にアクセスすることを目的とします。
状態と遷移はこんな感じです。
状態は次の5つです。
- 未発行: いわゆる未ログイン状態
- 有効: ログイン状態
- 要変更: ログイン状態ではあるものの、セッション情報と実際のユーザーの情報に差異があること(セッションCookieやトークンにJWTを用いている場合などで起こりうる)
- 無効: クライアント側はCookieなりトークンといったデータを持っているが、サーバー側でセッションを無効にされている
- 紛失: サーバー側のセッションは有効であるが、クライアント側にそれに紐づくデータが存在しない
状態遷移は次のようになります。
- 未発行 -> 有効: ログイン
- 有効 -> 未発行: ログアウト
- 有効 -> 有効: 再ログイン
- 有効 -> 要変更: アカウント情報の変更
- 要変更 -> 有効: 再認証 or 情報更新
- 有効 -> 紛失: クライアント側のデータ削除
- 紛失 -> 未発行: サーバー側の無効化
- 有効 -> 無効: サーバー側でセッション情報の無効化
- 無効 -> 未発行: クライアント側のデータ削除
むかーしむかしから、セッション管理の安全な設計ってどんななのかみたいな話が続いており、JWTだと失効管理がががみたいなことがよく語られます。 その辺りも丸っと含め、セッション管理に必要な機能って？と考えた時のコアな部分はこの状態遷移に含まれていると考えます。
- ログイン
- ログアウト
- クライアント側データの情報更新(必要ならば)
- 無効なセッションに紐づくクライアント側データの削除
- 利用されていないセッション情報の手動/自動削除
漠然と考えていた内容を整理してみた段階なので過不足もある気がしていますが、こういう考え方もできそうだなというところで意識してもらえたらと思います。
なんとなくですが、ID連携でも同様の整理ができるかもしれません。引き続き考えていきましょう。
ではまた！
