Vous devez vous assurer que votre équipe des opérations sait comment surveiller l’état du service Auth0 et qu’elle a mis en place un moyen de s’abonner aux mises à jour de l’état d’Auth0.Le tableau de bord d’état d’Auth0, ainsi que le tableau de bord de disponibilité d’Auth0, affichent l’état actuel et passé du service Auth0 dans un format facile à consulter. Si des alertes de surveillance sont déclenchées, votre équipe des opérations doit, comme première étape du dépannage, consulter le tableau de bord d’état pour vérifier s’il y a une panne en cours. La page d’état du cloud public permet également de s’abonner aux notifications de panne, et nous vous recommandons aussi de vérifier l’état de tous les services externes tiers dont vous dépendez, comme les fournisseurs d’identité sociaux. Avoir ces renseignements à portée de main peut aider à écarter rapidement certaines causes possibles lors du dépannage d’un problème et devrait figurer en tête d’une liste de vérification de dépannage, tant pour les développeurs que pour le personnel du service d’assistance.
Les renseignements sur la façon de vérifier l’état d’Auth0 ainsi que celui de tout service dont il dépend (comme les fournisseurs d’identité sociaux) devraient figurer en tête d’une liste de vérification de dépannage, autant pour les développeurs que pour le personnel du service d’assistance, et nous vous recommandons de vous abonner à la page d’état d’Auth0 afin de recevoir des notifications pour toute mise à jour d’état.
En cas de panne du service de cloud public, Auth0 effectue une analyse des causes profondes (RCA) et publie les résultats sur la page d’état d’Auth0. Auth0 mène une enquête approfondie après une panne — y compris la détermination de la cause profonde, des facteurs contributifs et des moyens d’empêcher que le problème se reproduise — et, par conséquent, la publication d’un document RCA peut prendre quelques semaines.
Vous devriez vous assurer d’avoir configuré votre propre fournisseur de courriel pour prendre en charge les volumes de courriels de production susceptibles d’être envoyés aux clients pour l’inscription, la validation du courriel, la récupération de compte et d’autres cas semblables.Auth0 envoie des courriels aux utilisateurs pour des événements comme l’envoi du message de bienvenue à l’inscription, la validation du courriel, la détection d’un mot de passe compromis et la réinitialisation du mot de passe. Vous pouvez personnaliser les modèles de courriel pour chaque type d’événement, et il est également possible de personnaliser de façon avancée la gestion des courriels. Auth0 fournit un fournisseur de courriel de test à capacité limitée pour les tests de base, mais vous devez configurer votre propre fournisseur de courriel pour une utilisation en production, et la personnalisation des modèles de courriel ne fonctionnera pas tant que vous n’aurez pas configuré votre propre fournisseur.
Le fournisseur de courriel par défaut d’Auth0 ne prend pas en charge l’envoi de volumes de courriels de production ni la personnalisation des modèles de courriel. Vous devriez donc configurer votre propre fournisseur de courriel avant le déploiement en production.
Si du code personnalisé exécuté dans Auth0 (par exemple dans une Action, une Rule, un Hook ou des scripts de base de données personnalisés) doit appeler un service à l’intérieur de votre réseau, ou si vous configurez un fournisseur SMTP sur site dans Auth0, vous devrez peut-être configurer votre pare-feu pour autoriser le trafic entrant provenant d’Auth0. Les adresses IP à autoriser dans le pare-feu sont propres à chaque région et sont indiquées dans les écrans de configuration de Rules, Hooks, des scripts de base de données personnalisés et du fournisseur de courriel de votre .
Si votre environnement d’hébergement ne s’en charge pas automatiquement, vous devriez disposer de scripts qui redémarrent automatiquement NTP (Network Time Protocol) en cas de défaillance, ainsi que d’alertes pour avertir quelqu’un si NTP n’est pas en fonction. Les transactions d’authentification reposent sur une heure système précise, car les peuvent être considérés comme expirés au moment de leur réception s’il existe des écarts de temps entre les systèmes d’envoi et de réception.
Si vous utilisez le connecteur AD/LDAP, vous devriez vérifier les paramètres du répartiteur de charge dans votre environnement pour voir s’ils interrompent des connexions de longue durée qui sont inactives. Si c’est le cas, vous pouvez modifier les paramètres de la connexion AD/LDAP d’Auth0 pour utiliser le paramètre LDAP_HEARTBEAT_SECONDS afin d’envoyer périodiquement des signaux de pulsation et de maintenir la connexion ouverte.
Si votre application conserve l’état du serveur au point de dépendre de l’affinité de session pour acheminer les utilisateurs vers un serveur précis, il peut être utile de revérifier que la configuration de tous les répartiteurs de charge est correcte. Un répartiteur de charge désynchronisé dans un groupe peut provoquer des erreurs intermittentes difficiles à diagnostiquer. Une vérification rapide de la configuration du répartiteur de charge peut éviter ce genre de problème dès le départ.
Vous devriez vérifier que la collecte des données de journalisation est bien configurée, que les journaux sont couverts par votre stratégie de conservation des données et que vous disposez de mécanismes pour faire respecter les limites de conservation des données de journalisation. Vous devriez également vous assurer que vos équipes de développement, d’assistance et de sécurité savent comment accéder aux données de journalisation à des fins de dépannage et d’analyse forensique. L’exportation des fichiers journaux vers des services offrant des fonctions d’analyse complètes peut vous aider à repérer des tendances, comme les tendances d’utilisation et les erreurs.Auth0 offre de solides capacités de journalisation des événements, ainsi que d’analyse des journaux pour repérer les anomalies dans les événements (consultez la documentation sur les journaux pour en savoir plus). La période standard de conservation des journaux Auth0 est déterminée par le niveau d’abonnement; la plus courte est de 2 jours et la plus longue, de seulement 30 jours. En tirant parti de la prise en charge d’Auth0 pour l’intégration à des services de journalisation externes, vous pourrez conserver les journaux au-delà de cette période et agréger les journaux à l’échelle de votre organisation.
Vous devriez utiliser l’une des solutions de streaming de journaux pour envoyer les données de journalisation vers un service externe d’analyse de journaux. Cela vous permettra de conserver les données plus longtemps et de bénéficier d’analyses avancées des données de journalisation.
Vous devriez vérifier la période de conservation des données de journalisation pour votre niveau d’abonnement, et mettre en place une extension d’exportation des données de journalisation pour envoyer ces données à un service externe d’analyse de journaux. Vous pouvez utiliser l’une de nos solutions de streaming de journaux dans Auth0 Marketplace.Les équipes de développement peuvent utiliser les fichiers journaux pour le dépannage et la détection d’erreurs intermittentes qui peuvent être difficiles à repérer au moyen des tests d’assurance qualité. Les équipes de sécurité voudront probablement disposer des données de journalisation au cas où des données forensiques seraient un jour nécessaires. L’exportation des fichiers journaux vers des services offrant des fonctions d’analyse complètes peut vous aider à repérer des tendances, comme les tendances d’utilisation et les déclencheurs de la .
Auth0 fournit un code d’erreur unique pour les erreurs signalées lorsque la limite de débit est dépassée. Vous devriez configurer une analyse automatique des journaux pour repérer les erreurs de limite de débit afin de pouvoir traiter de manière proactive l’activité qui se heurte aux limites de débit avant qu’elle ne cause trop de problèmes à vos utilisateurs. Auth0 publie aussi des codes d’erreur pour d’autres types d’erreurs, et il vous sera également utile d’analyser les journaux pour repérer les erreurs d’authentification ainsi que les erreurs provenant des appels à la d’Auth0 (les codes d’erreur de la Management API sont affichés sous chaque appel dans le Management API Explorer).
Appeler la Management API pour récupérer les informations du profil d’un utilisateur à partir d’une Rule est une cause fréquente d’erreurs de limite de débit, car de tels appels d’API peuvent s’exécuter à chaque connexion ainsi que lors des vérifications périodiques de session.
Assurez-vous de mettre en place une surveillance proactive du service Auth0, ainsi qu’une surveillance de bout en bout de l’authentification dans votre application.Vous devriez mettre en place des mécanismes de surveillance des implémentations Auth0, afin que votre équipe de soutien ou d’exploitation reçoive rapidement l’information nécessaire pour gérer les interruptions de service de façon proactive. Auth0 fournit des points de terminaison de surveillance qui peuvent être intégrés à votre infrastructure de surveillance. Ces points de terminaison sont conçus pour renvoyer une réponse exploitable par des services de surveillance. Il convient toutefois de noter qu’ils ne fournissent des données que sur Auth0. Pour une surveillance complète de bout en bout, essentielle pour vérifier si les utilisateurs peuvent se connecter, nous vous recommandons de mettre en place une surveillance des transactions synthétiques. Vous bénéficierez ainsi d’une surveillance plus granulaire et pourrez détecter les interruptions non liées à Auth0 ainsi que les baisses de performance, afin de réagir de manière plus proactive.
Vous devriez mettre en place la possibilité d’envoyer des transactions de connexion synthétiques afin de faciliter la surveillance de bout en bout de l’authentification. Vous pouvez le faire avec une application simple qui utilise le Resource Owner Password Grant en combinaison avec un utilisateur de test sans privilèges, et n’oubliez pas non plus les stratégies de limitation du débit d’Auth0.
Vous devez vous assurer que votre équipe surveille tous les canaux de communication suivants d’Auth0 afin de rester au courant des annonces et des changements importants.Auth0 envoie plusieurs types de notifications que vous devriez surveiller, car elles contiennent des renseignements importants qui pourraient avoir une incidence sur votre ou vos locataires ainsi que sur votre projet.
Les notifications de sécurité proactives et les autres annonces opérationnelles sont envoyées par Auth0 aux administrateurs de l’Auth0 Dashboard. Vous devez vous assurer que les personnes qui doivent recevoir ces messages sont administrateurs de l’Auth0 Dashboard.
De temps à autre, Auth0 peut envoyer une annonce importante concernant votre locataire. Ces annonces au sujet de votre service seront envoyées dans votre Auth0 Dashboard et, selon leur gravité, par courriel aux administrateurs enregistrés de l’Auth0 Dashboard. Vous devriez prendre l’habitude de vous connecter régulièrement à l’Auth0 Dashboard et de vérifier l’icône en forme de cloche en haut de la page pour repérer tout avis important. De plus, vous devriez consulter rapidement les courriels d’Auth0, car ils peuvent contenir des renseignements importants sur des changements ou des mesures à prendre.
Auth0 effectue régulièrement divers tests liés à la sécurité et, si des problèmes sont détectés, identifie de façon proactive les clients qui doivent apporter des correctifs de sécurité et les en avise. Toutefois, en raison de la nature extensible du produit Auth0, il est possible qu’Auth0 ne puisse pas identifier tous les clients concernés; vous devriez donc consulter régulièrement les bulletins de sécurité. Vous devez vous assurer qu’une personne-ressource en sécurité pour votre organisation est indiquée dans le Support Center.
Il est recommandé de consulter périodiquement la page Security Bulletins d’Auth0 et de prendre les mesures recommandées si vous êtes concerné par l’un de ces bulletins de sécurité.
Auth0 fournit de l’information sur les changements apportés au service dans le journal des modifications d’Auth0. Vous devriez prendre l’habitude de consulter régulièrement les journaux des modifications d’Auth0 pour rester au courant des changements. Les équipes de support qui analysent un problème peuvent trouver utile de consulter le journal des modifications pour déterminer si des changements récents pourraient être en cause, surtout s’il s’agit de changements non rétrocompatibles. Les équipes de développement voudront aussi consulter les journaux des modifications pour repérer de nouvelles fonctionnalités qui pourraient leur être utiles.De plus, vous devriez consulter périodiquement la page des migrations d’Auth0 pour vous informer des dépréciations à venir qui pourraient obliger votre équipe à apporter des changements.
Bien que cela ne soit pas obligatoire, nous vous recommandons de mettre en place un déploiement automatisé avec gestion de versions. Le fait d’automatiser le déploiement ou l’annulation des modifications dans les environnements de développement, de test et de production vous permet de réagir plus efficacement aux problèmes après la mise en production.En plus d’adopter des pratiques exemplaires en matière de gestion des changements et d’assurance qualité, les clients qui réussissent intègrent également la gestion des configurations Auth0 à leur processus de déploiement automatisé. Comme indiqué dans la section Architecture, sous prise en charge du SDLC, vous devriez configurer des locataires Auth0 distincts pour les environnements de développement, de test et de production, de sorte que la configuration du locataire soit la même dans chaque environnement. L’automatisation du déploiement aide à garantir l’uniformité de la configuration du locataire d’un environnement à l’autre, ce qui réduit les bogues et autres problèmes.
Quelle que soit la façon dont vous configurez l’automatisation du déploiement, nous vous recommandons d’effectuer des tests unitaires sur vos Rules, vos scripts de base de données personnalisés et vos Hooks avant le déploiement, puis d’exécuter aussi des tests d’intégration sur votre locataire après le déploiement. Pour en savoir plus à ce sujet, consultez les directives sur l’assurance qualité.
Auth0 prend en charge les approches suivantes pour l’automatisation du déploiement, qui peuvent être utilisées conjointement au besoin :
L’outil Auth0 Deploy CLI fournit un script facile à utiliser qui s’intègre à votre pipeline existant d’intégration continue et de déploiement continu (CI/CD).
Les extensions de gestion du code source d’Auth0 offrent un processus d’automatisation de base facile à configurer et nécessitant très peu de maintenance si vous n’avez pas de pipeline CI/CD, ou dans les cas où vous ne pouvez pas vous intégrer directement à un pipeline CI/CD.
Notez que l’outil Deploy CLI et les extensions de gestion du code source peuvent tous deux entraîner des modifications destructives; les modifications manuelles apportées directement dans l’Auth0 Dashboard entre les déploiements automatisés pourraient être perdues ! Pour cette raison, si l’un ou l’autre est utilisé, toutes les modifications devraient être déployées à partir du sous-système de gestion du code source référencé par l’outil, et non effectuées manuellement.
Chaque environnement peut aussi nécessiter une configuration propre à l’environnement — les et les des applications seront différents d’un locataire Auth0 à l’autre, par exemple — vous voudrez donc disposer d’un moyen d’y faire référence dynamiquement plutôt que d’utiliser des valeurs codées en dur. Auth0 prend en charge la gestion des informations de configuration propres à l’environnement au moyen de l’une des deux approches suivantes :
Auth0 vous permet de configurer des variables accessibles à partir de l’extensibilité personnalisée; vous pouvez les considérer comme des variables d’environnement pour votre locataire Auth0. Au lieu d’intégrer en dur des références qui changent lorsque vous déplacez du code entre les environnements de développement, de test et de production, vous pouvez utiliser un nom de variable configuré dans le locataire et utilisé par le code d’extensibilité personnalisée. Il devient ainsi plus facile d’utiliser le même code personnalisé, sans modification, dans différents locataires, puisque le code peut faire référence à des variables qui seront renseignées avec des valeurs propres au locataire au moment de l’exécution :
Pour utiliser des variables dans Actions, consultez Write Your First Action pour apprendre à configurer des secrets dans l’éditeur
Il est recommandé d’utiliser des variables pour stocker les valeurs propres au locataire ainsi que tout secret sensible qui ne devrait pas être exposé dans votre code personnalisé. Si votre code personnalisé est déployé dans GitHub/Gitlab/Bitbucket/VSTS, l’utilisation d’une variable propre au locataire permet d’éviter l’exposition de valeurs sensibles dans votre dépôt.
Vous devriez disposer d’un plan et d’un mécanisme pour assurer toute fonctionnalité de sauvegarde/restauration nécessaire à votre projet. Cela peut se faire à l’aide de la Management API d’Auth0 pour les données, ainsi que des fonctionnalités de déploiement automatisé décrites dans la section sur le déploiement automatisé pour la configuration d’Auth0.Comme il est indiqué dans la stratégie de restauration des données du locataire d’Auth0 et la stratégie de transfert des données d’Auth0, Auth0 ne restaure pas les locataires supprimés et ne déplace pas de données entre les locataires. Auth0 fournit la Management API afin d’offrir aux clients toute la flexibilité nécessaire pour sauvegarder, restaurer et déplacer des données selon leurs besoins. Les clients peuvent écrire des scripts pour extraire des données d’Auth0 à des fins de sauvegarde et, de la même façon, écrire des scripts à utiliser avec la fonctionnalité de déploiement automatisé pour restaurer tout aspect de leur configuration d’Auth0.
Vous devriez vérifier de nouveau que toutes les technologies de la pile de votre application, ainsi que les versions de navigateur utilisées par vos utilisateurs, sont bien à jour, car cela peut avoir une incidence sur la capacité d’Auth0 à fournir de l’assistance si des problèmes surviennent.
Les certificats peuvent être utilisés dans les déploiements d’identité. Pour éviter qu’une expiration de certificat ne vous prenne au dépourvu, vous devriez tenir une liste des certificats dans votre environnement, ainsi que de leurs dates d’expiration, de la façon dont vous serez avisé lorsque l’échéance approchera et du fonctionnement du processus de rotation des certificats.
Pour les connexions , vous obtenez un certificat auprès de l’ et le téléversez dans une connexion SAML pour l’IdP dans votre Auth0 Dashboard. Lorsqu’un de ces certificats est sur le point d’expirer, Auth0 enverra un courriel aux administrateurs de l’Auth0 Dashboard pour les avertir de son expiration prochaine. Vous pouvez obtenir le nouveau certificat et le téléverser à l’aide de l’écran de configuration de la connexion.
Pour les connexions (WS-Fed), si vous les configurez en spécifiant une URL ADFS, toute modification sera prise en compte lors d’une mise à jour quotidienne. Vous pouvez déclencher une mise à jour manuellement en visitant la page de configuration de la connexion dans l’Auth0 Dashboard et en cliquant sur Save. Si un certificat est modifié chez l’IdP distant, Auth0 peut être mis à jour au moyen de ces mécanismes ou en téléversant un nouveau fichier de métadonnées dans le même écran de configuration de la connexion.
Plan de reprise après sinistre / plan de continuité des activités en place
Bien qu’il ne s’agisse pas d’une exigence absolue avant le lancement, il est utile d’avoir mis en place un plan de reprise après sinistre afin d’assurer la continuité des activités en cas de différents types de sinistres, notamment des pannes de système et des catastrophes naturelles touchant une région où se trouve du personnel clé.
Un autre élément, qui n’est pas une exigence absolue mais qui est également recommandé, consiste à s’assurer que tous les processus liés à Auth0 sont documentés. Cela peut inclure ce qui suit :
Gestion des modifications de configuration
Déploiement des nouvelles modifications et de tout mécanisme de déploiement automatique utilisé, ainsi que la façon de revenir à la version précédente si des problèmes sont détectés
Processus de rotation des certificats, s’il y a lieu
Ajout ou suppression de nouveaux fournisseurs d’identité, le cas échéant
Modifications de la structure du profil utilisateur dans Auth0 ou dans les annuaires dont Auth0 extrait les données
Ajout ou suppression d’applications ou d’API
Collecte et exportation des journaux
Processus de sauvegarde et de restauration que vous avez mis en place
Gestion des utilisateurs (mot de passe oublié, téléphone perdu)
Nous mettons à votre disposition un guide de planification au format PDF que vous pouvez télécharger et consulter pour en savoir plus sur nos stratégies recommandées.Guide de planification du projet B2B IAM
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme