Firebase Auth : ce que c'est, méthodes d'authentification et fournisseurs de connexion

Qu'est-ce que Firebase Auth

Firebase Auth est un service d'authentification backend de Google fourni dans le cadre du SDK Firebase. Il gère toute la logique de gestion des comptes côté serveur : stockage des hachages de mots de passe, génération de jetons JWT et traitement des flux OAuth 2.0 et OpenID Connect. Les développeurs n'ont pas besoin de déployer leur propre serveur d'authentification, de gérer les jetons d'actualisation ou d'implémenter des protocoles de vérification — Firebase fait tout.

Architecture du service

Firebase Auth utilise une architecture fédérée avec un stockage d'utilisateurs unifié. Chaque utilisateur reçoit un identifiant unique (UID) qui ne dépend pas du fournisseur de connexion. Lors de l'inscription via Google et email, un seul utilisateur est créé avec deux comptes liés (fournisseurs). Firebase gère automatiquement la liaison des comptes côté client sans requêtes supplémentaires au serveur.

Les jetons Firebase Auth sont des JWT (JSON Web Token) avec une charge utile contenant l'UID, la date d'émission, la date d'expiration et les claims personnalisés. Les jetons d'accès durent 1 heure, les jetons d'actualisation sont illimités (mais peuvent être révoqués via la console d'administration). Le SDK actualise automatiquement le jeton à chaque requête HTTP vers les services Firebase. Selon Google (2026), Firebase Auth gère plus de 500 millions d'authentifications par jour.

Tarifs et limites

Firebase Auth est entièrement gratuit sur le forfait Spark (gratuit) et le forfait Blaze (pay-as-you-go). La seule limite est de 10 000 authentifications anonymes par jour sur Spark (illimité sur Blaze). Les authentifications par email/téléphone et OAuth n'ont pas de limites. Pour la vérification téléphonique, Spark fournit 10 000 vérifications par mois, tandis que Blaze facture à l'utilisation (0,01 $ par vérification après les 10 000 premières). Cela fait de Firebase Auth l'une des solutions les plus abordables du marché.

Fournisseurs d'authentification Firebase Auth

Firebase Auth prend en charge 12 fournisseurs d'authentification prêts à l'emploi. Chaque fournisseur est implémenté comme un service d'identité distinct avec un flux prédéfini — le développeur doit seulement créer un objet Credential et le passer à signInWithCredential. Firebase détermine automatiquement si l'utilisateur est nouveau ou existant, et en cas de duplication d'email, propose de lier les comptes.

Email et mot de passe

Email/Password est la méthode d'authentification de base avec des hachages de mots de passe (bcrypt) stockés sur les serveurs Firebase. Elle prend en charge l'inscription, la connexion, la réinitialisation du mot de passe par email et la confirmation d'email. Firebase vérifie automatiquement la force du mot de passe (6 caractères minimum) et peut bloquer la connexion après N tentatives échouées (protection contre la force brute).

Fournisseurs sociaux

Google, Apple, Facebook, Twitter, Microsoft, Yahoo, GitHub — tous les fournisseurs OAuth 2.0 peuvent être configurés via la console Firebase en 5 minutes. Pour chaque fournisseur, vous devez obtenir un Client ID et un Client Secret depuis la console du fournisseur lui-même. Apple Sign In est obligatoire pour les applications App Store (exigence d'Apple depuis 2020). Firebase Auth prend en charge complètement le flux Apple Sign In avec vérification JWT.

Authentification téléphonique

Phone Auth est l'authentification via un code SMS envoyé au numéro de téléphone de l'utilisateur. Firebase utilise Silent APN (iOS) ou SMS Retriever API (Android) pour lire automatiquement le code sans saisie au clavier. Sur Android, SMS Retriever API fonctionne uniquement sur les appareils avec Google Play Services. Pour les régions où les SMS ne sont pas disponibles, Firebase prend en charge la vérification reCAPTCHA comme solution de repli. L'authentification téléphonique est essentielle pour les applications nécessitant une liaison avec un numéro de téléphone — livraison de repas, transport, banque.

Intégration de Firebase Auth dans Android

Ajouter Firebase Auth sur Android nécessite d'ajouter la dépendance firebase-auth-ktx dans build.gradle et d'initialiser Firebase App (effectué automatiquement via le plugin Google Services). Après cela, l'objet FirebaseAuth est disponible via la méthode statique getInstance() — un singleton pour toute l'application. Aucune configuration supplémentaire n'est requise.

// build.gradle (app-level)
dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-auth-ktx")
    implementation("com.google.android.gms:play-services-auth:21.0.0")
}

Inscription d'utilisateur par email

createUserWithEmailAndPassword est la méthode principale d'inscription. Elle prend un email et un mot de passe, crée un utilisateur dans Firebase Auth et retourne un objet AuthResult avec l'UID. Si un utilisateur avec cet email existe déjà, Firebase retourne l'erreur ERROR_EMAIL_ALREADY_IN_USE. Après une inscription réussie, le SDK sauvegarde automatiquement le jeton dans SharedPreferences et restaure la session au prochain lancement de l'application sans appeler signIn.

class AuthViewModel {
    private val auth = FirebaseAuth.getInstance()

    suspend fun register(email: String, password: String): Result<User> {
        return try {
            val result = auth.createUserWithEmailAndPassword(email, password).await()
            Result.success(result.user?.toUser() ?: throw Exception("User is null"))
        } catch (e: FirebaseAuthException) {
            Result.failure(e)
        }
    }
}

Connexion Google

Pour Google Sign In, un processus en deux étapes est utilisé : obtenir un ID Token via Credential Manager (Android) ou Google Sign-In SDK, puis passer le jeton à une identité Firebase. Firebase vérifie le jeton sur son serveur (vérifie la signature avec la clé RSA de Google) et crée ou retourne l'utilisateur existant. Le processus ne nécessite pas de stockage de secret sur le client — toute l'authentification se fait par vérification cryptographique des jetons.

Gestion des utilisateurs et des sessions

Firebase Auth gère automatiquement le cycle de vie de la session. Après la connexion, le SDK sauvegarde le jeton d'actualisation dans le stockage local, et à chaque redémarrage de l'application, restaure la session via une connexion silencieuse. Les développeurs n'ont pas besoin d'implémenter le stockage de jetons, la gestion des expiration ou l'actualisation — le SDK Firebase Auth fait tout.

Utilisateur actuel

FirebaseAuth.getInstance().currentUser retourne un objet FirebaseUser si la session est active, ou null si l'utilisateur s'est déconnecté. FirebaseUser contient l'UID, l'email, displayName, photoUrl, phoneNumber, providerData et une liste de claims. Après les mises à jour du profil (updateProfile), les modifications sont synchronisées automatiquement avec le serveur. L'objet FirebaseUser est mis en cache en mémoire et mis à jour lors de toute opération d'authentification.

Authentification anonyme

signInAnonymously crée un utilisateur temporaire sans inscription. Les utilisateurs anonymes ont un UID mais pas d'email, de nom ou de fournisseur. Ceci est utile pour les applications où le contenu est disponible avant l'inscription (panier, favoris, historique). Lorsque l'utilisateur décide de s'inscrire, le compte anonyme est lié à un compte permanent via linkWithCredential. Sur le forfait Spark, il y a une limite de 10 000 authentifications anonymes par jour.

Selon Google (2026), environ 40% des utilisateurs commencent à utiliser une application de manière anonyme, et 25% d'entre eux lient ensuite leur compte anonyme à un compte permanent. Cela signifie que l'authentification anonyme ne perd pas de données lors de la conversion d'un utilisateur en utilisateur enregistré.

Déconnexion et suppression de compte

La méthode signOut() efface la session locale et supprime le jeton sauvegardé. Après avoir appelé signOut, currentUser devient null. La méthode delete() supprime complètement le compte utilisateur de Firebase Auth — tous les fournisseurs liés sont déconnectés et l'accès aux services Firebase est bloqué. La suppression d'utilisateur est irréversible et nécessite une réauthentification pour protéger contre la suppression non autorisée du compte.

Claims personnalisés et gestion des rôles

Custom Claims sont des attributs personnalisés que Firebase Auth ajoute au jeton JWT de l'utilisateur. Contrairement aux champs de profil standard (email, displayName), les claims sont disponibles uniquement côté serveur — via le SDK Admin ou via des règles dans Firebase Security Rules pour Firestore et Realtime Database. Les claims ne sont pas directement visibles par le client mais peuvent être lus via user.getIdTokenResult().

Cas d'utilisation typiques

Rôles et droits d'accès sont le cas d'utilisation le plus courant des claims. Le SDK Admin permet d'attribuer le rôle « admin », « moderator » ou « premium_user » via une carte sur le serveur. Ces claims sont automatiquement inclus dans le jeton et peuvent être utilisés dans Firestore Security Rules pour le contrôle d'accès. Selon Google (2026), 65% des projets Firebase utilisent des claims personnalisés pour la gestion de l'accès aux données au lieu d'un serveur de rôles séparé.

// Admin SDK (Node.js) — attribution de claims à l'utilisateur
const admin = require("firebase-admin")

await admin.auth().setCustomUserClaims(uid, {
    role: "premium",
    tier: "pro",
    maxProjects: 50
})

// Lecture des claims sur le client
val claims = FirebaseAuth.getInstance()
    .currentUser?.getIdTokenResult(true)
    ?.await()?.claims

Limites des claims

Les claims personnalisés ont des limites : un maximum de 1000 octets pour l'ensemble de l'objet JSON de claims par utilisateur, pas plus de 20 clés dans l'objet. Les claims ne sont pas conçus pour stocker des données dynamiques — ils sont mis à jour uniquement via le SDK Admin et ne se synchronisent pas en temps réel. Après la mise à jour des claims, l'utilisateur doit actualiser le jeton (getIdTokenResult(true)) ou se reconnecter à l'application. Les claims ne sont pas mis en cache sur le client — chaque nouvelle connexion reçoit un jeton à jour du serveur.

Sécurité de l'authentification

Firebase Auth implémente une protection multicompte : chiffrement du trafic (TLS 1.3), hachage des mots de passe (bcrypt, coût 10), protection contre la force brute avec Adaptive Pricing (ralentissement automatique de la réponse en cas d'activité suspecte) et intégration reCAPTCHA pour la connexion web. De plus, Firebase Auth désactive les comptes en cas d'activité suspecte — connexions massives depuis différentes IP, tentatives de connexion avec mot de passe incorrect et adresses email suspectes.

Méthodes de protection

Account Lockout — verrouillage automatique du compte après un certain nombre de tentatives de connexion échouées. Le seuil est configurable dans la console Firebase (par défaut 10 tentatives). Email Enumeration Protection — protection contre l'énumération des adresses email. Lorsqu'il est activé, Firebase retourne la même erreur pour un email existant et inexistant. Trusted Domains — restriction de la connexion uniquement aux utilisateurs avec des domaines d'email spécifiés dans les paramètres.

Sécurité des jetons personnalisés

Une authentification personnalisée supplémentaire peut être construite en utilisant des Custom Tokens — JWT signés par un compte de service Firebase. Le client passe le jeton personnalisé à signInWithCustomToken(), Firebase vérifie la signature et crée une session. Cela permet d'intégrer Firebase Auth à une authentification côté serveur existante (par exemple, votre propre serveur OAuth 2.0) sans dupliquer la base de données d'utilisateurs. Le jeton dure 1 heure, après quoi le SDK actualise automatiquement la session via un jeton d'actualisation Firebase.