Découvrez comment identifier, examiner et migrer les profils utilisateur Auth0 surdimensionnés avant l’application de la limite de taille de 10 Ko.
Auth0 a instauré une limite de 10 Ko pour la représentation sérialisée des données de profil utilisateur. Auparavant, les données de profil utilisateur étaient limitées uniquement par la taille des documents du moteur de base de données sous-jacent.Afin de réduire au minimum l’incidence fonctionnelle de cette nouvelle limite, Auth0 applique une marge de taille étendue en plus de celle-ci. Les opérations sur des profils utilisateur qui dépassent la limite de 10 Ko, mais restent dans cette marge étendue, continuent de réussir, mais génèrent des avertissements dans les journaux du tenant. Pour l’instant, cette marge est considérable, soit environ 10 fois la limite, afin de laisser suffisamment de temps pour assurer la conformité lorsqu’un profil utilisateur dépasse 10 Ko.Les tenants existants comportant un ou plusieurs profils utilisateur qui approchaient ou dépassaient déjà la limite de 10 Ko ont bénéficié d’une période de migration pendant laquelle le comportement d’origine, sans limites explicites, demeure disponible. La période de migration prend fin le 4 mars 2027. Après cette date, ces tenants commenceront à appliquer la limite de 10 Ko, en plus de la marge de taille étendue.Pour en savoir plus sur les échéanciers de migration, consultez l’entrée Dépréciations et migrations.Suivez les étapes ci-dessous pour déterminer si vos tenants ont été signalés en raison de profils utilisateur dépassant la limite de 10 Ko, examiner les profils utilisateur non conformes et renoncer au comportement obsolète.
Les administrateurs de tenant Private Cloud peuvent suivre ces instructions si leur déploiement Private Cloud est à la version 202635 ou ultérieure, car c’est à partir de cette version que la bascule de migration correspondante et les journaux du tenant deviennent disponibles dans les tenants concernés. Pour en savoir plus sur les versions de déploiement Private Cloud, consultez How to Check the Auth0 Private Cloud’s Release Number and Deployment Date.
La bascule est activée : votre tenant n’est pas migré et a accès à des profils utilisateur sans limite de taille explicite. Vous devez terminer la migration avant l’échéance du 4 mars 2027.
La bascule est absente ou désactivée : votre tenant n’applique plus le comportement deprecated; aucune autre action n’est requise.
Différences fonctionnelles dans les tenants non migrés
Dans un tenant où la bascule de migration Uncapped User Profile Data est activée, le service ne génère pas d’erreur lors des opérations qui dépendent de la création ou de la mise à jour d’utilisateurs, même si le profil utilisateur dépasse à la fois la limite de 10 ko et la marge de taille étendue. Cette marge de taille étendue demeure applicable même après la migration d’un tenant vers le nouveau comportement.
Consultez les logs de tenant depnote associés afin de repérer les tentatives de création ou de mise à jour de profils utilisateur dépassant la nouvelle limite de taille de profil. Ces logs de tenant se déclenchent uniquement lorsqu’une activité de l’utilisateur exige une mise à jour du profil, comme une nouvelle tentative de login. Par conséquent, ils ne permettent pas de repérer les profils utilisateur existants qui dépassent déjà la limite si les utilisateurs concernés demeurent inactifs.
Interroger les logs de deprecation liés aux données de user profile non plafonnées
Utilisez la query suivante pour rechercher les tenant logs propres à cette deprecation. Pour en savoir plus sur l’interrogation des tenant logs, consultez Log Search Query Syntax.
type:depnote AND description:Uncapped\ User\ Profile\ Data*
Une fois les résultats de la requête obtenus, examinez les champs user_id et projected_size_bytes de l’objet details afin de repérer les profils utilisateur surdimensionnés et leur taille. La structure de l’objet details, tout comme les informations contextuelles supplémentaires, peut varier légèrement selon l’opération sous-jacente ayant déclenché le journal du locataire.Voici un exemple d’entrée de journal déclenchée par un utilisateur final dont le profil est surdimensionné et qui s’est connecté au moyen de Universal Login. Certains champs par défaut du journal du locataire ont été omis de l’exemple par souci de concision.
{ "date": "2026-08-12T10:41:05.694Z", "type": "depnote", "description": "Uncapped User Profile Data: This feature is being deprecated. Please see details.feature of this log for more information.", "connection_id": "", "client_id": "Bd5rq9AlKTuOIUCc1JWB5WfmsTmN6iCf", "client_name": "example-app", "ip": "165.85.168.10", "user_agent": "Chrome 153.0.0 / Mac OS X 10.15.7", "details": { "feature": { "projected_size_bytes": "37581", "operation": "users.save", "user_id": "auth0|6a7c4da311eb043fbeed60f3", "id": "allow_oversize_profile", "name": "Uncapped User Profile Data", "description": "User profile data will be limited to 10KB. User profiles above that limit are deprecated." }, "path": "/u/login", "method": "POST" }, "log_id": "90020260812104105751616000000000000001223372045702376794"}
Dès qu’un tenant adopte le nouveau comportement, les tenant logs propres à la deprecation ne s’appliquent plus. Vous pouvez toutefois continuer à surveiller les nouveaux cas de profils utilisateur qui dépassent la limite grâce au type de tenant log user_profile_size_exceeded.
Calcul ponctuel de la taille d’un profil utilisateur
Les vérifications de limites effectuées par le service reposent sur la représentation interne des données sérialisées associées à un profil utilisateur. Comme ce processus de sérialisation inclut des champs opérationnels qui ne sont pas exposés à l’externe, les calculs ponctuels fondés uniquement sur les données de profil utilisateur visibles à l’externe peuvent différer des vérifications effectuées par le service.Cela dit, les calculs ponctuels fondés sur la représentation JSON du profil utilisateur retournée par le endpoint Get a User demeurent utiles pour obtenir une valeur approximative et pour comparer des profils utilisateur dont les ensembles d’attributs diffèrent. Cela fonctionne parce que les profils surdimensionnés déjà présents dans le système continuent d’être retournés sans restriction par les endpoints de récupération (GET) et par les jobs d’exportation d’utilisateurs en bloc, qu’ils dépassent ou non la limite.
Traiter la cause fondamentale des profils utilisateur trop volumineux
Les étapes exactes pour réduire la taille d’un profil utilisateur signalé peuvent varier considérablement, mais elles se rattachent généralement à l’un des scénarios suivants :
Retirer des profils utilisateur les données qui ne servent pas à l’authentification et à l’autorisation.
Déplacer du profil utilisateur vers d’autres stockages de données les données nécessaires à l’authentification et à l’autorisation.
Des exemples concrets d’actions pour chaque scénario sont présentés ci-dessous.
Empêcher le stockage d’attributs inutiles provenant d’identity providers externes
Pour éviter le stockage d’attributs utilisateur inutiles provenant d’identity providers externes, utilisez la liste de rejet des attributs utilisateur Auth0. Cette fonctionnalité vous permet de bloquer explicitement l’enregistrement de certains attributs dans le profil utilisateur, ce qui garde les profils allégés et évite un gonflement inutile des données.Les attributs ajoutés à la liste de rejet demeurent accessibles dans l’extensibilité post-login : vous pouvez donc utiliser cette information, ou la conserver dans un stockage de données externe, sans influer sur la taille du profil utilisateur.
Utiliser l’extensibilité pour interroger dynamiquement des données métier supplémentaires
Pour les structures de données non bornées, comme les tableaux dynamiques, ou les autres données volumineuses, évitez de stocker ces valeurs directement dans user_metadata ou app_metadata. Conservez plutôt ces données dans vos propres stockages de données externes et récupérez-les dynamiquement pendant l’authentification à l’aide d’une Action post-connexion :
Utilisez une Action post-connexion pour exécuter du code personnalisé immédiatement après l’authentification d’un utilisateur.
Dans votre Action, effectuez une requête réseau sécurisée (par exemple, à l’aide de axios ou de la fonction fetch native) vers votre propre API backend ou base de données afin de récupérer les attributs requis.
Utilisez les données récupérées pour définir des revendications personnalisées dans les jetons émis ou alimenter la logique d’autorisation, sans enregistrer les données brutes dans le profil utilisateur.
Ce modèle permet de maintenir vos profils utilisateur sous la limite de 10 Ko, tout en permettant à votre application de continuer à recevoir les données contextuelles nécessaires. Pour en savoir plus, consultez Auth0 Actions.
Utiliser les Enterprise Groups pour synchroniser l’information de groupe
Plutôt que de stocker directement dans le profil utilisateur l’information sur les groupes d’utilisateurs provenant d’identity providers externes, servez-vous des Enterprise Groups, accessibles par des endpoints SCIM, pour gérer cette information comme une entité distincte. Vous pouvez ensuite utiliser les groups ainsi provisionnés de plusieurs façons : en complément des Auth0 Organizations ou de manière indépendante, dans des post-login Actions, pour vos décisions personnalisées d’access control et d’autorisation.Par exemple, cette approche vous permet de cesser de stocker l’information sur les groupes d’utilisateurs Entra ID (Azure AD) directement dans les profils utilisateur dans le cadre des connections Azure AD existantes.
Une fois que vous avez corrigé la cause des profils utilisateurs surdimensionnés et que vous ne dépendez plus de ce comportement obsolète, désactivez-le dès que possible. Vous pourrez ainsi choisir précisément quand votre tenant adoptera le nouveau comportement et garder davantage de contrôle sur votre migration.
Sous Migrations, désactivez Uncapped User Profile Data.
Si vous rencontrez des problèmes, vous pouvez temporairement réactiver la bascule afin de rétablir le comportement précédent pendant que vous les corrigez. Les opérations les plus susceptibles d’être soumises à la vérification de la limite, et qui peuvent échouer si un profil utilisateur dépasse la taille maximale étendue autorisée, comprennent :
Opérations administratives via la Management API
Création d’utilisateurs (POST /api/v2/users).
Mise à jour d’utilisateurs (PATCH /api/v2/users/{id}).
Importation en bloc d’utilisateurs (POST /api/v2/jobs/users-imports).
Opérations liées à l’authentification
Connexions d’utilisateurs par l’intermédiaire de connexions à une base de données personnalisée, lorsque les scripts de base de données personnalisée renvoient trop d’attributs.
Connexions d’utilisateurs par l’intermédiaire de fournisseurs d’identité externes, comme des connexions sociales ou d’entreprise, lorsque le fournisseur d’identité renvoie trop d’attributs.
Connexions d’utilisateurs par tout type de connexion, si le profil est déjà surdimensionné, en raison de la nécessité de mettre à jour des attributs opérationnels lors d’une connexion standard.
Mise à jour des facteurs d’authentification multifacteur (MFA) via Universal Login, la MFA API ou la My Account API.
Mises à jour des métadonnées via l’objet api d’extensibilité, par exemple dans une Action post-login.
Opérations d’approvisionnement des utilisateurs
Requêtes de modification de ressources utilisateur via SCIM.
Directory Sync pour les connexions Google Workspace.
Assistant
Responses are generated using AI and may contain mistakes.
Authenticate
Manage Users
Customize
Platform