Identity Lifecycleを意識したID管理機能の設計

f:id:ritou:20201207033809j:plain

おはようございます。ritouです。

Digital Identity技術勉強会 #iddance Advent Calendar 2020 7日めの記事です。

qiita.com

OIDCとかFIDOとかOAuthとかGNAPとかいろいろな話題の記事が書かれて素晴らしいですね。

今回はID管理の設計の話をしましょう。

ID管理機能、どう作る?

新しいサービスを作る時、必ず必要となるのがID管理機能です。

ID管理!なんていうとエンプラ臭いですが、コンシューマー向けのサービスでも

  • 認証方式どうする?ソーシャルログイン?パスワードレス?自前でパスワード認証...
  • 新規登録ではメアドやSMS確認してパスワード設定させて...
  • パスワード認証の機能作って...
  • 再認証もできないとダメだし...
  • メアドやSMS、パスワード変更も必要だ
  • リスト攻撃怖いから2要素?2段階?できます
  • リカバリーめんどくさい問題
  • 退会の時、データ消す?残す?
  • サスペンド機能が欲しい?承知しました

とかいう流れは普通にあるでしょう。

このあたり、漏れなく設計/実装するために、どんなことに気を付けたら良いでしょうか。

社内にこの辺得意そうな猫がいたらそれに任せるでいいと思いますが いわゆるWeb Application Frameworkについてくる機能に任せたり、Googleとか有名なサービスを真似してなんとなく作ったりしてるとこも多いのではないでしょうか。

そんなのサービスの本質ではない!今はIDaaSの時代!IDaaSを使え!

という流れもありつつも、IDaaSの選定をするにも必要な機能をちゃんと整理できている必要があるでしょう。 今回は、ID管理機能の設計の際に "Identity Lifecycle" というのを意識してみましょう というお話を書きます。

Identity Lifecycle @ ISO/IEC 24760-1

ID管理についての様々な定義が書かれている、ISO - ISO/IEC 24760-1:2019 - IT Security and Privacy — A framework for identity management — Part 1: Terminology and concept というドキュメントに "Identity Lifecycle" が記載されています。

www.iso.org

("The electronic version of this International Standard can be downloaded from the ISO/IEC Information Technology Task Force (ITTF) web site" ってとこから辿れば無料でダウンロードできます。)

"Identity Lifecycle" はB向けC向け関わらず、Identity Systemにおける状態と状態遷移を表現したものです。

f:id:ritou:20201206015413j:plain

5つの状態

f:id:ritou:20201206015424j:plain

ユーザーが取りうる5つの状態が定義されています。

  • Unknown : 未登録や退会して完全にデータを消去した状態
  • Established : データはあるけどまだサービスは使えない、仮登録的な状態
  • Active : 本登録が終わってサービスを利用できる
  • Suspended : 一時的に利用できない
  • Archived : データは残っているけどサービスは利用できない、論理削除の退会済み的な状態

これは割と直感的かと思います。

状態遷移

f:id:ritou:20201206015435j:plain

そしてその状態遷移として、いくつかのアクションがあります。 仮登録、本登録、登録情報更新、一時利用停止、退会など直感的なものもあれば、C向けサービスだとこれあるかな?と考えてしまうものもいくつかあります。

ID管理機能の設計にどう活かすか

新たに設計を行う際にこれを意識できれば一番良いんでしょうけれども、ある程度設計が進んだ段階で 想定している機能に不足がないかを確認する ぐらいでも良さそうです。

  1. "自サービスでユーザーが取りうる状態" を確認
  2. その状態間で取りうる状態遷移から、機能に不足がないかを確認する

ちょっといくつかのパターンでやってみます。

パスワード認証

パスワード認証を利用しつつSMSやメールでリカバリーできる、一刻も早く滅びて欲しい感じの設計です。

  • 最初にSMS/メールの確認、終わったらパスワードや属性情報登録して利用可能
  • 一時利用停止あり、退会しても一定期間データを残す

みたいな場合、こんな感じになるでしょう。

f:id:ritou:20201206022842j:plain

使わない遷移をオリジナルのやつから削ったりちょっと変えてる部分があります。

それぞれを見ていきましょう。

f:id:ritou:20201206022905j:plain

仮登録的な意味合いでまずメアド/SMSの登録ですね。

最初にパスワードやプロフィール情報の入力も同時にやってからのメアド/SMS確認ならここでしょう。

f:id:ritou:20201206022930j:plain

メアド/SMSを確認してパスワード、プロフィール情報を登録して本登録完了。

f:id:ritou:20201206023015j:plain

メアドやパスワード、プロフィール情報は変更機能も必要です。 未ログイン状態からのパスワード変更と捉えると、パスワードリセットもここに含まれるかもしれません。

f:id:ritou:20201206023042j:plain

悪いことをしたり、されたり(不正ログイン)した場合は一時停止の機能が必要ですね。

f:id:ritou:20201206023108j:plain

退会処理も、すぐにデータを消すのではなく一旦 "Archived" な状態にしておいて、やり直しがきくようにします。 (オリジナルのやつと変えて"Restore" のところを "Archived" から "Active" に戻してるのは("Archived" -> "Established" -> "Active") の省略みたいなところです。) そして、一定期間が過ぎたり申告などで全部データを消しますよと。

こんな感じで、一通りの機能をカバーできてるかなと思います。

ソーシャルログイン

Googleでログインとかでさくっと使えるサービスの場合はまたちょっと変わりますね。

  • IdPから確認済みメアドがもらえたらそれ使う、もしもらえなかったりした場合は個別で確認もできる
  • 退会したら即データ消去。同じIdPのアカウントで再登録したら1からやり直し

みたいな場合、こんな感じになるでしょう。

f:id:ritou:20201207024802j:plain

"Unknown" から "Active" への遷移を増やしたり、"Archived" な状態を消したりしてます。

f:id:ritou:20201207024937j:plain

未登録で確認済みメアドを持ってるIdPのアカウントが来たら即登録完了、これがソーシャルログインの醍醐味でしょう。 (直接の状態遷移でなくても内部で "Established" -> "Active" と遷移してるよ、と捉えても良さそうです)

f:id:ritou:20201207024952j:plain

ざっくりソーシャルログインと言っても、

  • 認証のための識別子 : IdPの識別子 + IdPから受け取ったユーザー識別子
  • 連絡先などの確保 : 確認済みメアド
  • その他属性情報 : IdPから受け取ったプロフィール情報

と細かく整理できていれば、

  • IdPから確認済みメアドが受け取れないケースにも対応する
  • 複数IdPに対応しており、同じメアドを受け取った場合に(追加で認証するなどして)既存のアカウントと紐付ける、もしくは別ものとして連絡先を確認するかをユーザーに決めてもらう

みたいなことができます。

実際はあまり見かけませんが、確認済みメアドがなかった場合を仮登録状態として、ここから確認したら登録完了みたいな設計もありでしょう。

f:id:ritou:20201207025008j:plain

なのでこの状態遷移も残しましたよと。

f:id:ritou:20201207025024j:plain

別のIdPのアカウントと紐付け直し、メールアドレスの変更機能が必要ですね。

f:id:ritou:20201207025051j:plain

IdPのアカウント単位でブラックリストに入れたり、IdPから不正利用があったよと通知が来たりしたら一時的な利用停止もあり得るでしょう。

f:id:ritou:20201207025108j:plain

退会でIdPとの紐付けなどのデータをバッサリやっちゃうならここはシンプルになるでしょう。

どうでしょうか。このパターンも一通りカバーできてそうな気はします。

パスワード認証 + 2段階認証

追加認証があっても状態/状態遷移が増えなければパスワード認証の場合と変わらなそうです。

パスワード認証 and/or ソーシャルログイン

取りうる状態/状態遷移が異なる認証方式が組み合わされている場合、当然増えた状態/状態遷移を追加することになるでしょう。

IDaaS利用時にも参考にできる?

機能単位で使っていけるパターンなら、これまで書いてきたような考えを適用してIDaaS側、利用する側でそれぞれ機能が足りているかどうかを確認し、選定時に役立てられるのではと思います。

まとめ

  • ISO/IEC 24760-1にIdentity Lifecycleと言うものが定義されているよ
  • ユーザーの取りうる状態、状態遷移を意識することで、設計中/実装済みのID管理機能において不足してる部分がないかを確認できそうだよ

と言うお話でした。

匿名でも質問受け付けております!

marshmallow-qa.com

私のアドカレ次回作は12/15です。

qiita.com

正直そろそろしんどくなってきました!ではまた!