Users et UID
Créer, retrouver, mettre à jour, désactiver ou importer les users avec un mapping stable vers le compte métier et une procédure sur les doublons.
API
Intégrateur Firebase Auth API pour vos applications
Dawap relie Firebase Authentication au backend, aux comptes métier et aux outils internes d’une application web ou mobile. Nous cadrons UID, providers, Admin SDK, ID tokens, custom claims, sessions, révocation, migration et Identity Platform afin qu’un login réussi corresponde encore au bon client, au bon rôle et au bon état métier.
Premier lot Firebase Auth
Prouver un parcours de connexion jusqu’à la décision backend.
Le pilote prend une application, un provider et un droit sensible. Il suit la création du user, le lien avec le compte métier, l’émission et la vérification du token, la mise à jour du rôle puis la révocation effective.
Entrée : une app et un provider
Sortie : droit backend vérifié
Sécurité : révocation réellement testée
À l’issue du cadrage
- Cartographier UID Firebase, identifiant métier, provider, tenant éventuel, profil, rôle, abonnement et ressource protégée.
- Décider quelles données restent dans Auth, dans les custom claims et dans la base produit, avec une source qui fait foi.
- Configurer l’échange client-backend, la validation du token, les règles et le niveau de contrôle de révocation attendu.
- Tester claim ancien, compte désactivé, suppression en lot, provider lié, fonction bloquante indisponible et rollback.
Réponse courte
Une intégration Firebase Auth relie le login à la décision métier.
L’intégrateur associe le UID Firebase au compte produit, vérifie les ID tokens côté serveur, borne les custom claims et organise leur rafraîchissement. Il traite aussi les sessions, la révocation, les providers, les imports et les dépendances Identity Platform afin qu’un rôle supprimé cesse réellement d’ouvrir la ressource.
- Valider le token sur le backend et choisir explicitement quand vérifier aussi sa révocation.
- Garder le profil détaillé dans la base métier : les custom claims servent au contrôle d’accès et restent limités.
- Prévoir la propagation d’un changement de claim au prochain token, à la réauthentification ou à un refresh forcé.
UID
identifiant Firebase relié à une clé métier stable sans faire de l’email une clé universelle
ID token
signature, issuer, audience, expiration, auth_time, claims et révocation contrôlés côté backend
1 000 octets
plafond officiel des custom claims, réservés au contrôle d’accès et non au profil métier
7 secondes
délai maximal documenté d’une blocking function avant échec du parcours Auth
Architecture Firebase Auth
Six responsabilités entre l’application, Firebase et le backend
Firebase Authentication identifie l’utilisateur ; il ne remplace pas automatiquement le compte métier, l’autorisation backend ni la politique de session. Ces responsabilités doivent rester visibles dans le contrat.
Providers et account linking
Cadrer email, téléphone, social, custom auth ou fédération sans créer deux comptes lorsque le même utilisateur change de méthode.
ID tokens et backend
Vérifier signature, audience, issuer, expiration et UID côté serveur ; décider où le contrôle de révocation supplémentaire est nécessaire.
Custom claims et règles
Réserver les claims aux droits compacts, définir leur owner et tester la fenêtre où un ancien ID token porte encore l’ancienne valeur.
Sessions web et révocation
Choisir token client ou cookie serveur, protéger l’échange contre le CSRF et distinguer effacement local, expiration et révocation globale.
Identity Platform
Qualifier multi-tenancy, MFA, SAML/OIDC, fonctions bloquantes, audit, quotas et coût avant de dépendre d’une capacité liée à l’offre.
Parcours Firebase Authentication
Ce que l’on peut connecter sans diluer la sécurité du produit
Chaque cas relie une identité à une action autorisée, puis vérifie le changement inverse. L’onboarding seul ne prouve pas qu’un départ, une baisse d’abonnement ou un vol de session sera traité.
Relier l’inscription au compte métier
Créer ou retrouver le compte produit à partir du UID, puis rattacher organisation, consentement et statut sans copier tout le profil dans Auth.
Un onboarding mobile sans profil orphelin ni doublon silencieux.Autoriser après vérification du token
Transmettre l’ID token par HTTPS, le vérifier avec l’Admin SDK et recalculer les droits critiques depuis une donnée serveur.
Une API qui ne fait pas confiance au seul état du client.Réduire un droit après changement d’offre
Mettre à jour la source métier et le claim utile, puis forcer ou attendre le renouvellement prévu avant de vérifier l’accès réel.
Une baisse de plan sans privilège conservé par un token ancien.Importer des identités sans reset global
Reprendre UID, email, providers et hash compatibles par cohorte, mesurer les premiers logins et isoler les comptes non migrables.
Une bascule progressive avec taux d’échec et rollback connus.Scénarios de recette Firebase Auth
Trois contre-tests avant d’élargir la population
Ces scénarios décrivent une méthode de livraison, pas une référence client Firebase. Ils sont rejoués sur votre projet, votre offre, vos SDK et vos règles réelles.
Un ancien token n’ouvre plus un droit retiré
Le billing retire une option ; le backend reçoit encore un ID token contenant l’ancien claim et applique la politique de fraîcheur prévue au lieu de faire confiance à la copie client.
À auditer
UID, compte métier, version de rôle, custom claims, iat, auth_time, expiration, ressource, cache et mécanisme de refresh.
Livrable
Contrat de propagation avec owner du rôle, règle de fraîcheur, invalidation ciblée et scénario de réauthentification.
Traces
UID, version métier, claim reçu, token émis, décision backend, motif, refresh demandé et verdict final.
Décision
Choisir quels droits tolèrent la durée d’un token et lesquels exigent une lecture serveur ou une révocation.
Le nettoyage métier ne dépend pas d’un événement absent
Une opération Admin supprime plusieurs users ; la recette vérifie que le flux de fermeture ne suppose pas à tort que chaque suppression en lot déclenche un événement utilisateur.
À auditer
Commande bulk, UID concernés, fonction Auth, compte métier, données associées, journal, rapprochement et procédure de restitution.
Livrable
Workflow de suppression explicite avec inventaire préalable, résultat par UID, réconciliation et reprise des effets manquants.
Traces
Lot, UID, statut Firebase, statut métier, événement observé ou absent, compensation et propriétaire.
Décision
Exécuter les conséquences métier depuis le workflow orchestrateur, pas depuis la seule hypothèse d’un trigger onDelete.
Une dépendance lente ne coupe pas tous les logins sans stratégie
Le contrôle avant connexion dépasse son délai ou renvoie une erreur ; l’application produit un message exploitable et la politique fail-open ou fail-closed suit le risque défini.
À auditer
beforeCreate ou beforeSignIn, tenant, provider, dépendance, latence, timeout, erreur cliente, quota, métrique et rollback de fonction.
Livrable
Contrat de disponibilité avec budget de latence, cache autorisé, circuit breaker, alerte et procédure de désenregistrement sûre.
Traces
Événement, UID ou login, provider, durée, dépendance, décision, erreur présentée et action support.
Décision
N’ajouter une fonction bloquante que si le contrôle justifie de rendre Auth dépendant de ce service.
Intentions traitées
Pourquoi une équipe cherche un intégrateur Firebase Auth API
Le besoin apparaît lorsque Firebase ne sert plus uniquement à afficher un login : le backend doit protéger une API, les rôles viennent du métier, plusieurs apps partagent des comptes ou une migration doit conserver les accès.
Connecter users, UID, tokens et droits à la base produit, au CRM, au billing, au support et aux APIs internes.
Définir claims minimaux, source de vérité, propagation, vérification backend et procédure de retrait.
Vérifier ID tokens ou cookies de session, distinguer validité cryptographique et révocation, puis appliquer l’autorisation métier.
Livrables Firebase Auth
Ce que Dawap met en place sur une intégration Firebase Authentication
Le livrable couvre le parcours complet entre le SDK client, Firebase Auth, le backend et les données métier, avec une preuve de retrait aussi précise que la preuve de connexion.
- Audit du projet, offre, SDK, providers, users, UID, doublons, tenants éventuels, service accounts, IAM, quotas et règles de sécurité.
- Mapping UID-compte métier avec source des profils, organisations, rôles, abonnements, consentements et traitement des identités ambiguës.
- Middleware backend de vérification ID token ou session cookie : audience, issuer, expiration, auth_time, claims, révocation et erreurs.
- Workflow Admin SDK pour users, custom tokens et claims avec idempotence, limite de taille, propagation, pagination, permissions et reprise.
Méthode
On part de la ressource protégée, pas de l’écran de login
Nous suivons la décision depuis la donnée métier jusqu’au backend qui autorise réellement l’action. Cette lecture révèle si le rôle est trop volumineux pour un claim, si sa fraîcheur est compatible avec la durée du token et si la révocation est vérifiée au bon niveau de risque.
Résultats attendus
- Un UID relié sans ambiguïté au compte et à l’organisation métier.
- Des providers liés sans duplication silencieuse de l’identité.
- Des claims compacts, propriétaires et rafraîchis selon une règle connue.
- Des APIs backend qui vérifient token, audience et droit effectif.
Maillage identité et application
Poursuivre vers la couche qui porte la décision
Firebase Auth traite l’identité mais le produit, les protocoles, le billing et le backend conservent leurs responsabilités propres. Ces pages approfondissent chaque frontière.
Les critères d’une intégration Firebase Auth exploitable
Identité stable
Le UID et la clé métier restent reliés malgré un changement d’email ou de provider.
Droit frais
La durée de validité du token est compatible avec le risque du rôle qu’il transporte.
Retrait prouvé
Désactivation, révocation et suppression sont vérifiées sur la ressource réellement protégée.
Technologies et partenaires
Nous concevons des plateformes digitales robustes à partir de technologies éprouvées. Applications métier, marketplaces, middleware et APIs sont sélectionnés pour leur fiabilité, leur performance et leur intégration dans des environnements complexes.
-
Docker
-
Symfony
-
Mysql
-
Postman
-
Swagger
-
Redis
-
Memcached
-
Algolia
-
Arch Linux
-
Ubuntu
-
Drupal
-
Magento
-
Prestashop
-
Shopify
-
Docker
-
Symfony
-
Mysql
-
Postman
-
Swagger
-
Redis
-
Memcached
-
Algolia
-
Arch Linux
-
Ubuntu
-
Drupal
-
Magento
-
Prestashop
-
Shopify
Niveau de preuve
Firebase Auth : aucune référence fournisseur publique revendiquée
Dawap ne présente pas ici de projet client public développé avec Firebase Authentication. Les références proches prouvent des contraintes adjacentes : migration SSO, portail B2B, authentification d’API et orchestration de parcours sensibles.
Pour Branchassist, passer du SSO historique à Keycloak ne devait pas transférer aveuglément les autorisations. Dawap a séparé la connexion externe des droits internes : échange du code, contrôle de l’utilisateur actif, rôles Symfony, accès par ressource, révocation des jetons et trace des connexions. Une migration IAM ancrée dans l’application métier.
Firebase Auth gère l’identité, mais le profil métier et ses droits vivent souvent dans une autre source qu’il faut synchroniser. En pratique, il s’agit de relier identifiants, événements et révocation, afin que connexion et autorisations restent cohérentes sans stocker des rôles sensibles uniquement dans le client.
Un SaaS multi-tenant doit isoler identités, droits et données à chaque lecture comme à chaque action, pas seulement dans l’interface. L’approche proposée commence par choisir la frontière, propager le tenant et tester les fuites, afin qu’une erreur de filtre ne permette jamais à un client d’accéder au périmètre d’un autre.
Révoquer un token ne ferme réellement une session que si caches, refresh tokens et services consommateurs apprennent rapidement la décision. Le diagnostic relie les signaux utiles pour organiser propagation, vérification et reprise, afin de couper un accès compromis sans attendre l’expiration naturelle ni déconnecter inutilement tous les utilisateurs.
Quand un accès échoue, le bon diagnostic ne se limite pas au jeton. Il faut lire le scope, l’audience, la clé, le certificat, le contexte d’appel et la trace d’audit pour distinguer un refus normal d’une dérive d’IAM. Ce repère aide à sécuriser le run sans rendre les causes invisibles. Il réduit les tickets sans cause.
FAQ
Contacter un expert API
Questions fréquentes sur Firebase Auth API et le backend métier
Les réponses aux points qui bloquent avant de relier Firebase Authentication au produit : UID, Admin SDK, claims, tokens, sessions, providers, migration et Identity Platform.
Avant le premier échange, préparez
- Une ressource protégée et le parcours réel qui l’ouvre : app, provider, token, backend, règle et donnée métier.
- La source actuelle des profils, organisations, rôles, abonnements et statuts de désactivation.
- Un incident ou une migration à reproduire : doublon, claim ancien, token actif, suppression, quota ou échec de provider.
La question à trancher avant de coder
Combien de temps un ancien rôle peut-il rester dans un ID token sans créer un accès inacceptable ?
Quand Firebase Authentication doit être relié à un backend, une base produit, un CRM, un billing ou plusieurs applications et que les enjeux portent sur UID, rôles, claims, révocation, migration, multi-tenant ou exploitation.
Il permet notamment de gérer les users avec des privilèges serveur, créer des custom tokens, vérifier des ID tokens et piloter les custom claims. Son accès repose sur une identité de service qui doit recevoir uniquement les droits nécessaires.
Ce n’est pas leur rôle. Firebase recommande de réserver les custom claims au contrôle d’accès ; leur payload est limité à 1 000 octets. Le profil détaillé, son historique et ses données sensibles restent dans une base serveur appropriée.
Au prochain login ou à la réauthentification, lorsque l’ancien ID token est renouvelé après expiration, ou après un refresh forcé côté client. Le backend doit tenir compte de cette fenêtre pour les droits sensibles.
Non par défaut. La vérification standard contrôle notamment format, signature, audience, issuer et expiration. Le contrôle de révocation doit être demandé explicitement et peut ajouter un appel réseau ; il doit être placé selon le risque.
Oui via Firebase Authentication with Identity Platform. Les tenants, fonctions bloquantes, MFA ou fournisseurs SAML/OIDC dépendent de cette offre et de sa configuration. Une fonction bloquante doit répondre dans le délai documenté, sinon le parcours échoue.
On parle concret
Votre login fonctionne, mais le backend ne sait pas toujours pourquoi autoriser ?
En 15 minutes, on peut qualifier UID, token, rôle, ressource et premier parcours à rendre cohérent jusque dans la révocation.