Auth0のメタデータは特定のユーザーやアプリケーション等に少量の付加情報を追加できるもので、ここではこのうちユーザーのメタデータについて有効な活用方法を探っていきたいと思います。
ユーザーメタデータ概要
ユーザーのメタデータにもさらに user_metadataと app_metadta の2種類が存在します。
- user_metadata: ユーザーのための情報
e.g. 好きな食べ物、居住国 - app_metadata: システムのための情報。ユーザー自身が自由に更新することはできない
e.g. 外部サービスのID、ロール
Auth0がデフォルトで用意しているユーザーの属性は名前, Email, サムネイル画像, 最終ログイン日時といった必要最小限のもので、それ以外にユーザーの関連する属性をどこに永続化するかは悩みの種です。
ユーザーメタデータはスキーマレスな領域で、動的に属性の追加、削除が可能です。値はネストすることが可能で、深いところにある値の取得や更新が可能です。
参考:
– https://auth0.com/docs/manage-users/user-accounts/metadata/manage-metadata-rules#update-app-metadata
– https://auth0.com/docs/manage-users/user-accounts/metadata/manage-metadata-api#update-user-metadata
メタデータの情報はAPI経由で取得したりJWTに含めることができます。
その他、以下のような制限がありますのでご利用にあたってはご注意ください。詳しくは原文を参照してください。
You should only store data related to user authentication in metadata. The storage and search capabilities of Auth0 are designed for use cases that do not require heavy search and/or update frequency.
If you need to maintain detailed profile-related data for users, you should do so in an external system. You can store the user’s identifier from that system as a metadata field in Auth0.
– The app_metadata and user_metadata fields have a combined maximum limit of 16 MB total per user. There is no limit to the number of properties that may be stored in these fields.
DeepL翻訳(一部修正):
ユーザー認証に関連するデータのみメタデータに保存する必要があります。Auth0のストレージと検索機能は、検索や更新の頻度が高くないユースケースを想定して設計されています。
ユーザーの詳細なプロファイル関連データを保持する必要がある場合は、外部システムで行う必要があります。そのシステムのユーザ識別子を、Auth0 のメタデータフィールドとして保存することができます。– app_metadata と user_metadata の合計の上限は、1ユーザーあたり合計16MBです。これらのフィールドに格納できるプロパティの数には制限がありません。
引用: https://auth0.com/docs/manage-users/user-accounts/metadata/metadata-fields-data#rate-limits
また、メタデータはシステム管理者が閲覧できるため、必要に応じて暗号化するといった考慮も必要です。
メタデータ活用方法の考察
制限にあるように、詳細なユーザー情報はAuth0外のデータストアで管理するとなると、無理にユーザー情報をAuth0と外部ストアの2つに分断するのも違和感があるので、メタデータに保存することで価値が出てくるような値はそんなに多くはなさそうです。
以下、メタデータが有効活用できそうな、メタデータがなかったら面倒だなと思うケースを考えてみました。
同一ユーザーの複数端末利用を拒否する機能
現在アクセスしている端末しか知らない値と日時をメタデータに保存し、同一ユーザーが別端末からアクセスしたとき、端末を表す値が異なる場合に接続を拒否する。
ユーザー登録後7日間はアプリケーションを無料開放する機能
JWT(IDトークン、アクセストークン)の claim に事前に設定しておいた期限(app_metadata からJWTに展開)が過ぎたらUIやAPIの一部機能を無効にする。
画面初期表示の高速化
WebアプリはIdPからアクセストークンを取得し、そのトークンを使いバックエンドAPIにアクセスするのが一般的です。権限によりUIの見た目を変えたり、APIのアクセス可否を判断するために別途権限情報にアクセスするとコンマ数秒ロスしてしまうので、JWT内に権限制御に必要なユーザーのケイパビリティ(パーミッション, ロール)を app_metadata から事前すべて展開しておくことで余計な通信を削減する。
規約同意画面を表示する機能
アプリケーションに閉じた規約であれば client_metadata に規約の最終バージョンを設定しておき、user_metadata にはユーザーがどのバージョンに同意したかを持っておくことで、認証時に新しい規約がある場合に規約同意画面を表示する。※この挙動はAuth0のリダイレクトActionと合わせると、よりシンプルに実現できます。
全アプリケーションで共通のプライバシーポリシーのような規約であれば、よりIdP側に処理を集約するメリットがあります。
Posted by Yuki Sanada
今後の設計の参考に。
この記事は IDaaS Advent Calendar 2022 12日目の投稿です。
