Le risque métier apparaît quand Firebase Authentication identifie correctement un utilisateur, mais que l’application ne sait plus si cette personne appartient encore au bon compte client, si son abonnement ouvre la fonction demandée ou si un rôle retiré doit être opposable immédiatement. Ces décisions vivent généralement dans le produit, le CRM, le billing ou un référentiel interne.
Le problème s’aggrave lorsque ces couches sont confondues. Un email devient la clé de tous les systèmes, le profil complet est copié dans des custom claims, le backend accepte un token sans vérifier son projet, ou le support désactive un user en pensant que toutes les sessions sont déjà inutilisables. Le login continue à fonctionner, mais personne ne sait expliquer précisément pourquoi l’action métier a été autorisée.
Contre-intuitivement, multiplier les claims ou raccourcir les jetons ne répare pas une autorité métier ambiguë. Si le retrait d’un droit critique ne peut pas être mesuré de Firebase jusqu’au backend, alors la population ne doit pas être étendue : la validité cryptographique ne prouve ni la fraîcheur du profil ni la fermeture effective des sessions.
La méthode sépare identité, profil, autorisation et session afin de décider où lire chaque vérité, quoi mettre en cache et quand bloquer. Si votre besoin est déjà de construire ou reprendre le connecteur, notre page intégrateur Firebase Auth API précise le pilote, les livrables et les limites de preuve de l’accompagnement Dawap.
Séparer identité, profil et autorisation
Donner une responsabilité à chaque donnée
Firebase Auth porte le user, son UID, ses providers, son état et des métadonnées d’authentification. La base produit porte souvent l’organisation, le contrat, les préférences, les consentements détaillés et les droits contextuels. Le backend combine l’identité vérifiée avec cet état métier pour autoriser une ressource.
Le contrat doit indiquer, champ par champ, quelle source crée, corrige et retire la valeur. Un rôle commercial issu du billing ne doit pas devenir vrai parce qu’un client le transmet. À l’inverse, un attribut purement métier n’a pas à gonfler tous les ID tokens alors qu’il peut être lu depuis la base serveur au moment utile.
Écrire la décision sous forme de question
« Cette requête possède-t-elle un token valide ? » n’est que la première étape. La vraie question peut être : « Ce UID appartient-il encore à cette organisation et son offre autorise-t-elle cette opération ? » Cette formulation fait apparaître le tenant, la ressource, la fraîcheur attendue et le système qui tranche.
Si la réponse varie selon l’organisation, l’offre ou la sensibilité de l’action, alors le contrat doit porter ces entrées jusqu’au point d’autorisation. Le verdict conserve la règle appliquée, sa version et la source relue ; il ne se résume pas à un booléen sans contexte que le support serait incapable d’expliquer.
Relier le UID au compte métier sans dépendre de l’email
Conserver une table de correspondance stable
L’email change, peut être réutilisé ou arriver depuis plusieurs providers. Le mapping conserve au minimum le UID Firebase, l’identifiant métier, le projet ou tenant concerné, la provenance et l’état de rapprochement. Une adresse reste un attribut vérifié, pas une clé universelle implicite.
Lors d’un account linking, la recette vérifie que le même compte produit est conservé et que ni consentement ni organisation ne sont perdus. Une collision ambiguë rejoint une file de résolution. La fusion automatique de deux identités actives est irréversible et peut déplacer des données vers la mauvaise personne.
Traiter la création comme une projection
La création du profil métier part d’un événement ou d’un appel orchestré, mais elle relit l’état Firebase avant de muter. Une clé idempotente empêche de créer deux profils après un timeout. Le résultat conserve UID, identifiant métier, version de mapping et décision finale.
Le traitement reçoit en entrée le projet, le UID, la provenance et l’identifiant de corrélation ; il produit en sortie un profil relié ou un conflit qualifié. Un retry relit cette sortie avant toute nouvelle écriture. Cette responsabilité explicite évite qu’un appel rejoué transforme une panne réseau en doublon métier.
Borner l’Admin SDK et les comptes de service
Séparer les privilèges serveur des capacités client
L’Admin SDK peut gérer les users, créer des custom tokens, vérifier des ID tokens et modifier les custom claims. Ces opérations sont privilégiées. Elles doivent s’exécuter dans un environnement serveur, avec une identité de service protégée et des permissions IAM limitées au flux concerné.
Un worker d’import n’a pas besoin des mêmes droits que l’API qui vérifie les sessions. Séparer les comptes techniques réduit l’impact d’une fuite et permet de révoquer un usage sans arrêter tout le produit. Les logs conservent l’acteur technique et le motif, jamais la clé privée ni le token complet.
Tester aussi les refus
La recette confirme qu’un service peut exécuter sa tâche, puis qu’il ne peut pas supprimer un user, modifier un provider ou agir sur un autre projet sans autorisation. Une permission minimale n’est prouvée qu’avec ces cas négatifs.
Un cas concret utilise deux projets et deux identités de service : le worker autorisé importe sa cohorte, tandis que l’API de vérification reçoit un refus sur la mutation d’un compte. Si la seconde identité peut encore créer un custom token ou changer des claims, alors son rôle IAM doit être corrigé avant le pilote.
Utiliser les custom claims sans y mettre le profil métier
Réserver le token au contrôle d’accès
Firebase recommande les custom claims pour l’autorisation, pas pour stocker un profil détaillé. Leur payload est limité à 1 000 octets. Une organisation courante, un rôle compact ou un indicateur de niveau peuvent y tenir ; une liste de contrats, de permissions dynamiques ou de préférences n’y a pas sa place.
Chaque claim possède un owner, une signification et une règle de retrait. Les noms sont versionnés afin d’éviter qu’une application interprète différemment la même valeur. Le backend valide le token avant d’utiliser ses claims ; une valeur reçue séparément depuis le client ne fait jamais foi.
Accepter qu’une mise à jour ne soit pas instantanée
Après modification, les nouveaux claims arrivent lors d’une nouvelle connexion ou réauthentification, au renouvellement du token, ou après un refresh forcé. Cette fenêtre est acceptable pour certains affichages, pas forcément pour un droit financier ou un départ. Le contrat décide donc si le backend relit la source métier, force un nouveau token ou déclenche une révocation.
En pratique, le seuil dépend de l’impact : une préférence d’interface peut attendre le prochain renouvellement, alors qu’un droit d’administration exige une lecture serveur ou une révocation immédiate. La métrique utile mesure le temps entre la décision métier et le premier refus backend, pas seulement la date à laquelle le claim a été écrit.
Vérifier ID tokens, sessions et révocation au bon niveau
Ne pas confondre signature valide et accès encore autorisé
Le backend reçoit l’ID token par HTTPS puis vérifie notamment signature, issuer, audience, expiration et UID. La vérification standard avec l’Admin SDK ne contrôle pas automatiquement la révocation. Ce contrôle supplémentaire doit être demandé explicitement et peut nécessiter un aller-retour réseau.
La politique place ce coût là où le risque l’exige : changement de coordonnées bancaires, export sensible, administration ou action irréversible. Pour les ressources moins critiques, une durée courte, une règle Firebase ou une lecture métier peut offrir un meilleur compromis. Le choix est documenté, pas caché dans un helper commun.
Distinguer logout local et révocation
Effacer un token ou un cookie côté navigateur ferme l’interface locale, pas nécessairement toutes les sessions de l’utilisateur. Firebase permet de révoquer les refresh tokens et de vérifier cet état. Le scénario de départ teste plusieurs appareils et un token émis avant la révocation, puis mesure quand l’action backend est réellement refusée.
Pour une application web traditionnelle, un cookie de session serveur peut remplacer la persistance client. Il faut alors vérifier le token récent avant l’échange, protéger l’endpoint contre le CSRF, appliquer les attributs de cookie et décider si la révocation est contrôlée à chaque requête sensible.
Choisir fonctions bloquantes et événements sans dépendance cachée
Bloquer une connexion uniquement pour une règle critique
Firebase Authentication with Identity Platform permet des fonctions avant création ou avant connexion. Elles peuvent refuser le parcours ou enrichir certaines données, mais elles doivent répondre dans le délai documenté de sept secondes. Une dépendance CRM lente placée ici peut donc empêcher tous les utilisateurs concernés de se connecter.
Avant d’ajouter une fonction bloquante, l’équipe choisit fail-open ou fail-closed, budget de latence, cache autorisé, message client, métriques et procédure de retrait du trigger. Le contrôle doit être assez important pour justifier que Firebase Auth dépende de sa disponibilité.
Connaître les trous des événements asynchrones
Les triggers Auth de création et suppression appartiennent aux fonctions de première génération. La documentation précise aussi qu’une suppression de plusieurs users via l’Admin SDK ne déclenche pas les événements individuels de suppression. Un nettoyage métier critique ne peut donc pas reposer uniquement sur l’hypothèse d’un onDelete.
Le workflow de suppression inventorie les UID, exécute l’opération, conserve le résultat par user et rapproche ensuite Auth avec la base métier. L’événement reste utile comme signal ; l’orchestrateur garde la responsabilité de prouver chaque fermeture.
Qualifier Identity Platform avant de promettre le multi-tenant
Vérifier l’offre et la frontière produit
Le multi-tenant, les fonctions bloquantes, la MFA et certains providers d’entreprise sont associés à Firebase Authentication with Identity Platform. Chaque tenant peut posséder ses users et providers. L’intégration utilise un client tenant-aware et porte le tenantId dans les mappings, les jobs, les erreurs et les écrans support.
Créer un tenant technique par client n’est pas automatiquement la bonne décision. Il faut comparer isolation attendue, nombre de clients, providers, branding, règles, opérations support et coût de migration. L’analyse de l’isolation multi-tenant SaaS aide à distinguer frontière d’identité et frontière complète de données.
Migrer les comptes et leurs hashes sans reset global
Inventorier avant d’importer
La migration recense UID existants, emails vérifiés, providers, facteurs, comptes désactivés, créations en doublon et algorithmes de hash. L’Admin SDK accepte plusieurs formats de hash documentés, avec leurs paramètres. Une valeur inconnue ne doit pas être approximée : elle rejoint un parcours de récupération explicite.
Le pilote importe une cohorte représentative et suit premier login, échec de mot de passe, account linking, token, profil métier et support. Les comptes sources restent lisibles pendant la fenêtre de coexistence. Le rollback précise ce qui peut revenir en arrière et ce qui, comme un changement de mot de passe, doit suivre un autre chemin.
Respecter quotas et protections anti-abus
Les créations, suppressions, recherches, SMS, imports et échanges de tokens possèdent des limites qui dépendent de l’opération et parfois de l’offre. Elles peuvent évoluer. Le plan relit les quotas officiels juste avant la bascule, borne la concurrence et prévoit backoff, fenêtre, pause et reprise au curseur.
Le worker journalise le curseur, le nombre accepté, les rejets et la prochaine échéance autorisée sans enregistrer de secret. Une réponse de quota ne repart pas en boucle serrée : la file applique le délai, réduit la concurrence et alerte l’owner si la cohorte ne peut plus finir dans la fenêtre de migration.
Jouer une recette qui contredit le scénario nominal
Tester la fraîcheur d’un droit
Le scénario retire un rôle alors qu’un ancien ID token reste présent sur deux appareils. Il tente la ressource publique, une fonction payante et une opération d’administration. Le verdict montre quelle couche refuse, après quel délai, avec quelle trace et quel message utilisateur.
Le contre-test garde volontairement un appareil hors ligne, réutilise son ancien jeton puis le reconnecte après la décision métier. Le seuil est validé seulement si l’action sensible est refusée dans le délai promis, même lorsque l’interface affiche encore temporairement un état provenant de son cache local.
Tester les identités difficiles
La recette change un email, lie un second provider, reçoit deux créations proches et présente un compte métier déjà associé. Elle doit conserver une seule identité légitime ou isoler le conflit sans fusion arbitraire. Chaque résultat est vérifiable depuis le support avec UID, provider, compte et décision.
Le cas le plus risqué associe le nouvel email d’une personne à une adresse autrefois utilisée par un compte fermé. Le test doit bloquer la fusion automatique, préserver les deux historiques et demander une preuve supplémentaire. L’email vérifié reste un attribut utile, mais le UID et l’identifiant métier gouvernent la correspondance.
Tester les dépendances et les opérations en lot
Une fonction bloquante dépasse son budget, un appel Admin expire après mutation et une suppression en lot ne produit pas l’événement attendu. L’équipe reprend depuis l’état réel, sans recréer le user ni réouvrir un droit. Ces contre-tests valent davantage qu’une démonstration de login nominal.
Chaque panne possède un résultat attendu : refuser la connexion lorsque la règle est critique, mettre la mutation ambiguë en quarantaine, ou lancer la réconciliation après le batch. Si le support ne distingue pas ces trois chemins dans les traces, alors la bascule est à différer même si tous les scénarios nominaux passent.
Donner au support une preuve et une action suivante
Chercher depuis le dossier métier
Le support part du compte client, de l’utilisateur ou de l’action refusée. Il retrouve UID, providers, dernière connexion, version de claims, token ou session concerné, statut métier et opérations Admin. Les données sensibles sont masquées ; la corrélation suffit pour suivre le parcours.
Les alertes portent sur des écarts actionnables : users sans profil, profils sans user, claims en retard, révocations hors délai, collisions et imports incomplets. Chacune nomme un owner, une échéance et un runbook. Un compteur d’erreurs global sans population ni reprise ne protège pas l’accès.
Réconcilier sans réécrire à l’aveugle
La balance compare Auth et la base métier par pages et curseurs conservés. Elle classe les écarts avant mutation : attendu, source en retard, conflit, suppression légitime ou anomalie. Le repair relit les deux côtés, applique une règle versionnée et conserve l’état avant/après.
Le runbook interdit la correction directe en base ou dans la console pour masquer un écart. L’opérateur choisit une action bornée, renseigne le motif et déclenche le même chemin idempotent que le flux normal. Un écart qui revient après réparation signale une autorité mal définie plutôt qu’un incident isolé.
Éviter les erreurs fréquentes qui fragilisent Firebase Auth
La première erreur consiste à rapprocher les comptes par email seul. Un changement d’adresse, un provider supplémentaire ou une réutilisation suffit à attribuer le profil d’une personne à une autre. À corriger en priorité : conserver le couple projet–UID comme identité Firebase et exiger un verdict explicite lorsque le lien métier est ambigu.
La deuxième erreur transforme les custom claims en fiche client distribuée. Le payload grossit, vieillit dans les jetons et mélange données d’affichage avec permissions opposables. Il faut garder des claims compacts et versionnés, puis lire le CRM, le billing ou la base produit lorsque la décision dépend d’un état métier frais.
La troisième erreur assimile déconnexion visuelle et révocation. Fermer le navigateur ne coupe ni un refresh token présent sur un autre appareil ni un cookie serveur encore accepté. Si une opération sensible reste possible après le délai contractuel, alors le go-live doit être bloqué et le chemin de vérification renforcé.
La quatrième erreur délègue la fermeture d’un compte à un événement supposé infaillible. Les suppressions en lot et les timeouts après mutation imposent une réconciliation indépendante. Le bon arbitrage est de traiter l’événement comme un signal rapide, tandis que la balance périodique prouve l’état final.
Plan d’action pour un premier lot Firebase Auth maîtrisé
Cadrer
Choisissez une application, un provider, une population et une ressource dont le risque est compris. Documentez UID, compte métier, owner du rôle, contenu des claims, mode de session, contrôle de révocation, offre Firebase et identités de service.
Le contrat nomme les entrées, les sorties, les responsabilités, les dépendances et les seuils de fraîcheur. Il précise aussi le comportement de repli : lecture métier, refus temporaire ou file de reprise. Cette fiche est validée par le produit, la sécurité et le support avant la première mutation Admin.
Construire et observer
Implémentez mapping idempotent, vérification backend, mutations Admin, propagation et traces. Ajoutez métriques, quarantaine et rapprochement avant d’importer une grande population. Le support doit pouvoir expliquer un succès et un refus sans lire un token brut.
L’instrumentation relie la corrélation métier aux appels Firebase, au retry et à la décision backend. La file conserve le statut et la prochaine tentative ; le rollback stoppe l’extension sans effacer les preuves ; le runbook indique quoi relire avant de rejouer. Deux parcours complets, nominal et dégradé, doivent être démontrés à l’équipe d’astreinte.
Décider l’extension
Le go exige que claim ancien, token révoqué, provider lié, timeout et doublon soient traités. L’équipe doit exécuter le rollback et reprendre un lot interrompu. Le volume n’augmente qu’après fermeture des écarts critiques.
- À faire d’abord : nommer les sources du UID, du profil, de l’organisation et du droit.
- À tester ensuite : propagation, révocation, collision, opération en lot et dépendance lente.
- À différer : une migration sans hash connu, cohorte pilote ni support disponible.
- À refuser : un profil complet dans les claims ou une confiance directe dans une valeur envoyée par le client.
Relier révocation, multi-tenant et autorisation API
La synchronisation du profil ne suffit pas à fermer les accès. Le dossier sur la révocation des tokens et la fermeture réelle d’une session précise les délais, caches et contre-tests à relier au départ d’un utilisateur.
Lorsque plusieurs clients, providers ou politiques coexistent, le choix du tenant Firebase doit être confronté à l’isolation des identités, droits et données d’un SaaS multi-tenant. Cette lecture évite de confondre une frontière IAM avec l’isolation complète attendue par le produit.
Conclusion : prouver la décision backend
Une intégration Firebase Auth fiable ne s’arrête pas au login. Elle relie le UID au compte métier, maintient les providers sans doublon, garde les custom claims compacts et contrôle la fraîcheur des droits au niveau adapté.
Le backend vérifie chaque token dans le bon projet et distingue validité cryptographique, session locale et révocation. Les opérations Admin sont bornées par des identités de service, les événements ne remplacent pas la réconciliation et la migration avance par cohortes observables.
Pour transformer ce contrat en connecteur, tests et runbook, notre accompagnement d’intégrateur Firebase Authentication API cadre le mapping, la sécurité, la recette contradictoire et la reprise. Le pilote reste borné tant que la décision backend et le retrait d’un droit ne sont pas démontrables.
