影響を受けるテナントを確認する
Auth0 Dashboardを使用して、テナントが準拠していないユーザープロファイルを持つとしてフラグ付けされ、移行が必要かどうかを確認します。- Auth0 Dashboard > Tenant Settings > Advanced に移動します。
- Migrations セクションまでスクロールします。
- Uncapped User Profile Data トグルを確認します。
- トグルがオン: テナントは未移行であり、明示的なサイズ制限なしでユーザープロファイルにアクセスできます。2027年3月4日の期限までに移行を完了する必要があります。
- トグルがない、またはオフ: テナントでは非推奨の動作はすでに適用されなくなっており、追加の対応は不要です。
未移行のテナントにおける機能上の違い
Uncapped User Profile Data 移行トグルが有効なテナントでは、ユーザープロファイルが 10KBの制限と拡張サイズ許容量の両方を超えていても、ユーザーの作成または更新を伴う操作中にサービスでエラーが発生することはありません。テナントを新しい動作に移行した後も、拡張サイズ許容量は引き続き適用されます。サイズ超過のユーザープロファイルを特定する
関連するdepnote テナントログを確認し、新しいプロファイルサイズの上限を超えるユーザープロファイルの作成または更新の試行を特定します。これらのテナントログは、新たなログイン試行など、プロファイルの更新が必要となるユーザーアクティビティがある場合にのみ記録されます。したがって、該当するユーザーが非アクティブのままであれば、すでに上限を超えている既存のユーザープロファイルをこれらのログで特定することはできません。
上限のないユーザープロファイルデータに関する非推奨化ログの検索
この非推奨化に関連するテナントログを検索するには、次のクエリを使用します。テナントログのクエリについて詳しくは、ログ検索クエリの構文を参照してください。details オブジェクト内の user_id フィールドと projected_size_bytes フィールドを確認し、サイズ超過のユーザープロファイルとそのサイズを特定します。details オブジェクトの構造や追加のコンテキスト情報は、テナントログをトリガーした基盤となる操作によって若干異なる場合があります。
以下は、サイズ超過のプロファイルを持つエンドユーザーが Universal Login 経由でログインを完了した際にトリガーされたログエントリの例です。簡潔にするため、デフォルトのテナントログフィールドの一部は省略しています。
テナントが新しい動作に移行すると、非推奨化に関連するテナントログは使用されなくなります。ただし、
user_profile_size_exceeded テナントログタイプを使用すれば、上限を超えるユーザープロファイルの新たな発生を引き続き監視できます。ユーザープロファイルサイズの概算
サービスによる制限チェックは、ユーザープロファイルに関連付けられたシリアル化データの内部表現に基づいて行われます。このシリアル化プロセスには外部には公開されない運用フィールドも含まれるため、外部向けのユーザープロファイルデータだけに基づく概算は、サービスによるチェック結果と異なる場合があります。 それでも、Get a User エンドポイントから返されるユーザープロファイルの JSON 表現に基づく概算は、おおよその値を把握したり、異なる属性セットを持つユーザープロファイルを比較したりする際に役立ちます。これは、システム内にすでに存在するサイズ超過のプロファイルは、制限を超えているかどうかにかかわらず、取得 (GET) エンドポイントおよび一括ユーザーエクスポートジョブを通じて引き続き制限なく返されるためです。
サイズ超過のユーザープロファイルの根本原因に対処する
フラグが設定されたユーザープロファイルのサイズを縮小するために必要な手順は大きく異なる場合がありますが、一般的には次のいずれかに該当します。- 認証および認可に使用されないデータをユーザープロファイルから削除する。
- 認証および認可に必要なデータをユーザープロファイルから別のデータストアに移す。
外部アイデンティティプロバイダーから不要な属性が保存されないようにする
外部アイデンティティプロバイダーから取得した不要なユーザー属性の保存を防ぐには、Auth0 User Attributes Deny Listを使用します。この機能を使用すると、特定の属性をユーザープロファイルに永続保存しないよう明示的にブロックでき、プロファイルを簡潔に保ち、不要なデータの肥大化を回避できます。 拒否リストに追加された属性は、post-loginの拡張でも引き続き利用できるため、ユーザープロファイルのサイズに影響を与えることなく、その情報を使用したり外部データストアに保存したりできます。拡張を利用して追加のビジネスデータを動的に取得する
動的配列のようにサイズが無制限に増え得るデータ構造や、容量の大きいその他のデータは、user_metadata や app_metadata に直接保存しないでください。代わりに、独自の外部データストアで管理し、Post-Login Action を使用してauthentication中に動的に取得します。
- Post-Login Action を使用して、ユーザーのauthentication直後にカスタムコードを実行します。
- Action 内で、安全なネットワークrequest (たとえば、
axiosまたはネイティブのfetchを使用) を独自のbackend APIまたはデータベースに対して実行し、必要な属性を取得します。 - 取得したデータを使用して、発行するtokenにカスタムクレームを設定したり、認可ロジックで利用したりします。生データはユーザープロファイルに永続化しません。
Enterprise Groups を使用してグループ情報を同期する
外部アイデンティティプロバイダーのユーザーグループ情報をユーザープロファイルに直接保存する代わりに、SCIM エンドポイントを通じて利用できる Enterprise Groups を使用して、グループ情報を独立したエンティティとして管理します。この方法でプロビジョニングされたグループは、Auth0 Organizations と併用するほか、カスタムのアクセス制御や認可判断のために post-login Actions で単独で使用することもできます。複数の方法で利用できます。 たとえば、この方法を使用すると、既存の Azure AD 接続において、Entra ID (Azure AD) のユーザーグループ情報をユーザープロファイルに直接保存する方法から移行できます。移行を完了するためのオプトアウト
サイズ超過のユーザープロファイルの原因に対処し、非推奨の動作に依存しなくなったら、できるだけ早くオプトアウトしてください。これにより、テナントで新しい動作を採用するタイミングを正確に選択でき、移行をより細かく制御できます。- Auth0 Dashboard > Tenant Settings > Advanced に移動します。
- Migrations で、Uncapped User Profile Data をオフにします。
- Management API を介した管理操作
- ユーザーの作成 (
POST /api/v2/users) 。 - ユーザーの更新 (
PATCH /api/v2/users/{id}) 。 - ユーザーの一括インポート (
POST /api/v2/jobs/users-imports) 。
- ユーザーの作成 (
- 認証関連の操作
- カスタムデータベーススクリプトが過剰な属性を返すことによる、カスタムデータベース接続経由のユーザーログイン。
- アイデンティティプロバイダーが過剰な属性を返すことによる、ソーシャル接続やエンタープライズ接続などの外部アイデンティティプロバイダー経由のユーザーログイン。
- 通常のログイン処理の一環として運用属性を更新する必要があるため、プロファイルがすでにサイズ超過している場合の、あらゆる接続タイプ経由のユーザーログイン。
- Universal Login、MFA API、または My Account API を介した多要素認証 (MFA) の認証要素の更新。
- たとえば post-login Action 内での、拡張の
apiオブジェクトを介したメタデータの更新。
- ユーザープロビジョニング操作
- SCIM を介したユーザーリソースの変更リクエスト。
- Google Workspace 接続の Directory Sync。