Connecter votre application à l'émulateur Authentication

Avant d'utiliser l'émulateur Authentication avec votre application, assurez-vous que vous compreniez le workflow global Firebase Local Emulator Suite, et que vous installiez et configuriez le Local Emulator Suite et consultiez ses commandes CLI.

Cet article suppose que vous savez déjà comment développer Firebase Authentication solutions pour la production. Si nécessaire, consultez la documentation correspondant à votre combinaison de plate-forme et de technique d'authentification.

Que puis-je faire avec l'émulateur Authentication ?

L'émulateur Authentication fournit une émulation locale haute fidélité des Firebase Authentication services, offrant la plupart des fonctionnalités disponibles dans production Firebase Authentication. Associé aux SDK Firebase pour les plates-formes Apple, Android et Web, l'émulateur vous permet d'effectuer les opérations suivantes :

• Créer, mettre à jour et gérer des comptes utilisateur émulés pour tester l'authentification par adresse e-mail/mot de passe, numéro de téléphone/SMS, authentification multifacteur par SMS et authentification par un fournisseur d'identité tiers (par exemple, Google)
• Afficher et modifier les utilisateurs émulés
• Prototyper des systèmes d'authentification par jeton personnalisé
• Vérifier les messages liés à l'authentification dans l'onglet "Journaux de l'interface utilisateur de l'émulateur".

Choisir un projet Firebase

Le Firebase Local Emulator Suite émule des produits pour un seul projet Firebase.

Pour sélectionner le projet à utiliser, avant de démarrer les émulateurs, exécutez firebase use dans votre répertoire de travail dans la CLI. Vous pouvez également transmettre le --project flag à chaque commande d'émulateur.

Remarque : En règle générale, il est recommandé d'utiliser un seul ID de projet pour tous les appels d'émulateur . Ainsi, l'Emulator Suite UI, les différents émulateurs de produits et toutes les instances en cours d'exécution d'un émulateur particulier peuvent communiquer correctement dans tous les cas . En fait, par défaut, le Local Emulator Suite vous avertit si elle détecte plusieurs ID de projet en cours d'utilisation, mais vous pouvez remplacer ce comportement. Pour obtenir des conseils sur la définition et la gestion des ID de projet, consultez le guide d'installation et de configuration.

Local Emulator Suite est compatible avec l'émulation de projets Firebase réels et de projets de démonstration.

Type de projet	Fonctionnalités	Utilisation avec des émulateurs
Réel	Un projet Firebase réel est un projet que vous avez créé et configuré (très probablement via la Firebase console). Les projets réels comportent des ressources actives, telles que des instances de base de données, des buckets de stockage, des fonctions ou toute autre ressource que vous avez configurée pour ce projet Firebase.	Lorsque vous travaillez avec des projets Firebase réels, vous pouvez exécuter des émulateurs pour tout ou partie des produits compatibles. Pour tous les produits que vous n'émulez pas, vos applications et votre code interagiront avec la ressource active (instance de base de données, bucket de stockage, fonction, etc.).
Démonstration	Un projet Firebase de démonstration ne comporte aucune configuration Firebase réelle ni aucune ressource active. Ces projets sont généralement accessibles via des ateliers de programmation ou d'autres tutoriels. Les ID de projet pour les projets de démonstration sont précédés du préfixe demo-.	Lorsque vous travaillez avec des projets Firebase de démonstration, vos applications et votre code interagissent avec des émulateurs uniquement. Si votre application tente d'interagir avec une ressource pour laquelle aucun émulateur n'est en cours d'exécution, ce code échoue.

Nous vous recommandons d'utiliser des projets de démonstration dans la mesure du possible. Voici quelques-uns de ses avantages :

• Configuration plus facile, car vous pouvez exécuter les émulateurs sans jamais créer de projet Firebase
• Sécurité renforcée, car si votre code appelle accidentellement des ressources non émulées (de production), il n'y a aucun risque de modification des données, d'utilisation et de facturation
• Meilleure prise en charge hors connexion, car vous n'avez pas besoin d'accéder à Internet pour télécharger la configuration de votre SDK.

Remarque : Si vous souhaitez émuler des interactions entre services, telles que des fonctions Cloud Functions déclenchées par une base de données ou des règles de sécurité qui dépendent de l'authentification, vous devez vous assurer que l'ID de projet dans votre code (dans initializeApp(), etc.) correspond à l'ID de projet utilisé par la Firebase CLI.

Cloud FunctionsSecurity RulesAuthentication

Instrumenter votre application pour qu'elle communique avec l'émulateur

SDK Android, iOS et Web

Configurez vos classes de test ou de configuration intégrée à l'application pour interagir avec l'émulateur Authentication comme suit.

Kotlin

Firebase.auth.useEmulator("10.0.2.2", 9099)

Java

FirebaseAuth.getInstance().useEmulator("10.0.2.2", 9099);

Swift

Auth.auth().useEmulator(withHost:"127.0.0.1", port:9099)

Web

import { getAuth, connectAuthEmulator } from "firebase/auth";

const auth = getAuth();
connectAuthEmulator(auth, "http://127.0.0.1:9099");
auth_emulator_connect.js

Web

En savoir plus sur l'API Web modulaire et "tree-shakeable" et sur ses avantages par rapport à l'API avec espace de noms.

const auth = firebase.auth();
auth.useEmulator("http://127.0.0.1:9099");
emulator-suite.js

Aucune configuration supplémentaire n'est nécessaire pour prototyper et tester les interactions entre Authentication et Cloud Functions ou Firebase Security Rules pour Cloud Firestore ou Realtime Database. Lorsque l'émulateur Authentication est configuré et que d'autres émulateurs sont en cours d'exécution, ils fonctionnent automatiquement ensemble.

Admin SDKs

Les Firebase Admin SDK se connectent automatiquement à l'émulateur Authentication lorsque la variable d'environnement FIREBASE_AUTH_EMULATOR_HOST est définie.

export FIREBASE_AUTH_EMULATOR_HOST="127.0.0.1:9099"

Remarque : Pour que les émulateurs fonctionnent correctement, la variable d'environnement FIREBASE_AUTH_EMULATOR_HOST doit omettre les protocoles tels que http://.

Notez que l'émulateur Cloud Functions est automatiquement informé de l'émulateur Authentication. Vous pouvez donc ignorer cette étape lorsque vous testez des intégrations entre les émulateurs Cloud Functions et Authentication. La variable d'environnement sera automatiquement définie pour le Admin SDK dans Cloud Functions.

Lorsque la variable d'environnement est définie, les Firebase Admin SDK acceptent les jetons d'ID non signés et les cookies de session émis par l'émulateur Authentication (respectivement via les méthodes verifyIdToken et createSessionCookie) pour faciliter le développement et les tests locaux. Veillez à ne pas définir la variable d'environnement en production.

Si vous souhaitez que votre Admin SDK code se connecte à un émulateur partagé s'exécutant dans un autre environnement, vous devez spécifier le même ID de projet que celui que vous avez défini à l'aide de la CLI Firebase. Vous pouvez transmettre un ID de projet directement à initializeApp ou définir la variable d'environnement GCLOUD_PROJECT.

SDK Admin Node.js

admin.initializeApp({ projectId: "your-project-id" });

Variable d'environnement

export GCLOUD_PROJECT="your-project-id"

Jetons d'ID

Pour des raisons de sécurité, l'émulateur Authentication émet des jetons d'ID non signés, qui ne sont acceptés que par d'autres émulateurs Firebase ou par le SDK Firebase Admin lorsqu'il est configuré. Ces jetons seront rejetés par les services Firebase de production ou par le SDK Firebase Admin s'exécutant en mode production (par exemple, le comportement par défaut sans les étapes de configuration décrites ci-dessus).

Démarrer l'émulateur

Vous pouvez utiliser l'émulateur Authentication de manière interactive via l'interface utilisateur de la suite d'émulateurs Emulator Suite UI et de manière non interactive via son interface REST locale. Les sections suivantes couvrent les cas d'utilisation interactifs et non interactifs.

Pour démarrer l'émulateur Authentication, son interface REST et l' Emulator Suite UI, exécutez la commande suivante :

firebase emulators:start

Authentification émulée par adresse e-mail, lien par e-mail et anonyme

Pour l'authentification anonyme, votre application peut exercer la logique de connexion pour votre plate-forme (iOS, Android, Web).

Pour l'authentification par adresse e-mail/mot de passe, vous pouvez commencer à prototyper en ajoutant des comptes utilisateur à l'émulateur Authentication à partir de votre application à l'aide des méthodes du SDK Authentication, ou en utilisant l'Emulator Suite UI.

1. Dans le Emulator Suite UI, cliquez sur l'onglet Authentication.
2. Cliquez sur le bouton Add user (Ajouter un utilisateur).
3. Suivez l'assistant de création de compte utilisateur en renseignant les champs d'authentification par e-mail.

Une fois qu'un utilisateur test a été créé, votre application peut le connecter et le déconnecter à l'aide de la logique du SDK pour votre plate-forme (iOS, Android, Web).

Pour tester la validation de l'adresse e-mail/la connexion avec les flux de liens par e-mail, l'émulateur affiche une URL dans le terminal sur lequel firebase emulators:start a été exécuté.

i  To verify the email address [e-mail], follow this link:
http://127.0.0.1:9099/emulator/action?mode=verifyEmail&lang=en&oobCode=XYZ123&apiKey=fake-api-key

Collez le lien dans votre navigateur pour simuler l'événement de validation et vérifiez si la validation a réussi.

{
  "authEmulator": {
    "success": "The email has been successfully verified.",
    "email": "[e-mail]"
  }
}

Pour tester la réinitialisation du mot de passe, l'émulateur affiche une URL semblable, y compris un paramètre newPassword (que vous pouvez modifier si nécessaire), dans le terminal.

http://127.0.0.1:9099/emulator/action?mode=resetPassword&oobCode=XYZ!23&apiKey=fake-api-key&newPassword=YOUR_NEW_PASSWORD

Tests non interactifs

Au lieu d'utiliser les Emulator Suite UI ou le code client pour gérer les comptes utilisateur par adresse e-mail/mot de passe , vous pouvez écrire des scripts de configuration de test qui appellent des API REST pour créer et supprimer des comptes utilisateur, et récupérer des codes de validation d'adresse e-mail hors bande pour remplir l'URL de validation d'adresse e-mail de l'émulateur. Cela permet de séparer la plate-forme et le code de test, et d'effectuer des tests de manière non interactive.

Pour les flux de test non interactifs par adresse e-mail et mot de passe, la séquence type est la suivante.

1. Créez des utilisateurs avec le Authentication point de terminaison REST d'inscription.
2. Connectez-vous à l'aide des adresses e-mail et des mots de passe pour effectuer des tests.
3. Si cela s'applique à vos tests, récupérez les codes de validation d'adresse e-mail hors bande disponibles à partir du point de terminaison REST spécifique à l'émulateur.
4. Videz les enregistrements utilisateur avec le point de terminaison REST spécifique à l'émulateur pour effacer les données.

Authentification émulée par téléphone/SMS

Pour l'authentification par téléphone, l'émulateur Auth n'est pas compatible avec les éléments suivants :

• Flux reCAPTCHA et APN. Une fois configurés pour interagir avec l'émulateur, les SDK clients désactivent ces méthodes de validation d'une manière semblable à celle décrite pour les tests d'intégration (iOS, Android, Web).
• Numéros de téléphone de test avec des codes préconfigurés dans la Firebase console.

Sinon, en termes de code client, le flux d'authentification par téléphone/SMS est identique à celui décrit pour la production (iOS, Android, Web).

Utiliser le Emulator Suite UI :

1. Dans le Emulator Suite UI, cliquez sur l'onglet Authentication.
2. Cliquez sur le bouton Add user (Ajouter un utilisateur).
3. Suivez l'assistant de création de compte utilisateur en renseignant les champs d'authentification par téléphone.

Toutefois, pour les flux d'authentification par téléphone, l'émulateur ne déclenchera PAS la distribution de messages texte, car le contact avec un opérateur n'est pas dans le champ d'application et n'est pas adapté aux tests locaux. Au lieu de cela, l'émulateur affiche le code qui aurait été envoyé par SMS au même terminal sur lequel vous avez exécuté firebase emulators:start. Saisissez ce code dans l'application pour simuler la vérification des messages texte par les utilisateurs.

Tests non interactifs

Pour les tests d'authentification par téléphone non interactifs, utilisez l'émulateur Authentication API REST pour récupérer les codes SMS disponibles. Notez que le code est différent chaque fois que vous lancez le flux.

La séquence type est la suivante.

1. Appelez la plate-forme signInWithPhoneNumber pour démarrer le processus de validation.
2. Récupérez le code de validation à l'aide du point de terminaison REST spécifique à l'émulateur.
3. Appelez confirmationResult.confirm(code) comme d'habitude avec le code de validation.

Authentification multifacteur par SMS

L'émulateur Authentication est compatible avec le prototypage et le test des flux d'authentification multifacteur (AMF) par SMS disponibles en production pour iOS, Android, et le Web.

Lorsque vous ajoutez un utilisateur factice à l'émulateur, vous pouvez activer l'AMF et configurer un ou plusieurs numéros de téléphone auxquels les messages SMS du deuxième facteur seront envoyés. Les messages sont envoyés au même terminal sur lequel vous avez exécuté firebase emulators:start et sont disponibles à partir de l'interface REST.

Authentification émulée par un fournisseur d'identité tiers

L'émulateur Authentication vous permet de tester de nombreux flux d'authentification tiers dans vos applications iOS, Android ou Web sans modifier le code de production. Pour obtenir des exemples de flux d'authentification, consultez la documentation pour différentes combinaisons de fournisseurs et de plates-formes que vous pouvez utiliser dans votre application.

En règle générale, vous pouvez utiliser le SDK Firebase pour vous authentifier de deux manières :

• Votre application permet au SDK de gérer l'ensemble du processus de bout en bout, y compris toutes les interactions avec les fournisseurs d'identité tiers pour récupérer les identifiants.
• Votre application récupère manuellement les identifiants auprès d'un fournisseur tiers à l'aide du SDK de ce tiers et les transmet au SDK Authentication.

Encore une fois, consultez le lien de documentation ci-dessus et assurez-vous de bien connaître le flux que vous souhaitez utiliser (géré par le SDK Firebase ou récupération manuelle des identifiants). L'émulateur Authentication est compatible avec les tests des deux approches.

Tester les flux de fournisseurs d'identité gérés par le SDK Firebase

Si votre application utilise un flux de bout en bout du SDK Firebase, tel que OAuthProvider pour la connexion avec Microsoft, GitHub ou Yahoo, pour les tests interactifs, l'Authentication émulateur diffuse une version locale de la page de connexion correspondante afin de vous aider à tester l'authentification à partir d'applications Web qui appellent la méthode signinWithPopup ou signInWithRedirect. Cette page de connexion diffusée localement s'affiche également dans les applications mobiles, rendue par la bibliothèque WebView de votre plate-forme.

L'émulateur crée des comptes utilisateur et des identifiants tiers factices selon les besoins au fur et à mesure du déroulement des flux.

Tester les flux de fournisseurs d'identité avec récupération manuelle des identifiants

Si vous utilisez des techniques de connexion "manuelles" et appelez la méthode signInWithCredentials de votre plate-forme, votre application demandera, comme d'habitude, une connexion tierce réelle et récupérera des identifiants tiers réels.

Notez que l'émulateur n'est compatible avec l'authentification signInWithCredential que pour les identifiants récupérés à partir de Google Sign-In, Apple et d'autres fournisseurs qui utilisent des jetons d'ID implémentés en tant que jetons Web JSON (JWT). Les jetons d'accès (par exemple, ceux fournis par Facebook ou Twitter, qui ne sont pas des JWT) ne sont pas acceptés. La section suivante présente une alternative dans ces cas.

Tests non interactifs

Une approche pour les tests non interactifs consiste à automatiser les clics de l'utilisateur sur la page de connexion diffusée par l'émulateur. Pour les applications Web, utilisez une interface de contrôle telle que WebDriver. Pour les applications mobiles, utilisez les outils de test d'interface utilisateur de votre plate-forme, tels qu'Espresso ou Xcode.

Vous pouvez également mettre à jour votre code pour utiliser signInWithCredential (par exemple, dans une branche de code) et utiliser un flux d'authentification par jeton avec des jetons d'ID factices pour les comptes au lieu d'identifiants réels.

1. Recâblez ou commentez la partie de votre code qui récupère les idTokens du fournisseur d'identité. Cela évite d'avoir à saisir des noms d'utilisateur et des mots de passe réels lors de vos tests, et vous n'avez plus à vous soucier des quotas et des limites de débit de l'API au niveau du fournisseur d'identité.
2. Ensuite, utilisez une chaîne JSON littérale à la place du jeton pour signInWithCredential. En utilisant le SDK Web comme exemple, vous pouvez modifier le code comme suit :

firebase.auth().signInWithCredential(firebase.auth.GoogleAuthProvider.credential(
  '{"sub": "abc123", "email": "[e-mail]", "email_verified": true}'
));

Lorsqu'il est utilisé avec l'émulateur, ce code authentifie correctement un utilisateur avec l'adresse e-mail [e-mail] sur Google. Considérez le champ "sub" comme une clé primaire, qui peut être remplacée par n'importe quelle chaîne, simulant ainsi la connexion de différents utilisateurs. Vous pouvez remplacer firebase.auth.GoogleAuthProvider par, par exemple, new firebase.auth.OAuthProvider('yahoo.com') ou tout autre ID de fournisseur que vous souhaitez simuler.

Authentification émulée par jeton personnalisé

L'Authentication émulateur gère l'authentification avec des jetons Web JSON personnalisés à l'aide d' appels à la méthode signInWithCustomToken sur les plates-formes compatibles, comme décrit dans la documentation production Authentication.

Différences entre l'émulateur Authentication et la production

L'émulateur Firebase Authentication simule de nombreuses fonctionnalités du produit de production. Toutefois, comme tout type de système d'authentification repose fortement sur la sécurité à plusieurs niveaux (appareil, fournisseurs tiers, Firebase, etc.), il est difficile pour l'émulateur de recréer correctement tous les flux.

Cloud IAM

La suite d'émulateurs Firebase ne tente pas de répliquer ni de respecter un comportement lié à IAM pour l'exécution. Les émulateurs respectent les règles de sécurité Firebase fournies, mais dans les situations où IAM serait normalement utilisé, par exemple pour définir le compte de service d'appel Cloud Functions et donc les autorisations, l'émulateur n'est pas configurable et utilisera le compte disponible globalement sur votre machine de développement, comme lors de l'exécution directe d'un script local.

Connexion via un lien par e-mail sur mobile

Étant donné que sur les plates-formes mobiles, la connexion par lien par e-mail repose sur les liens dynamiques Firebase, tous ces liens seront ouverts sur la plate-forme Web (mobile).

Connexion tierce

Pour les flux de connexion tiers, Firebase Authentication s'appuie sur des identifiants sécurisés provenant de fournisseurs tiers tels que Twitter et GitHub.

Les identifiants réels des fournisseurs OpenID Connect tels que Google et Apple sont acceptés par l'émulateur Authentication. Les identifiants des fournisseurs non OpenID Connect ne sont pas acceptés.

Connexion par adresse e-mail / SMS

Dans les applications de production, les flux de connexion par adresse e-mail et SMS impliquent une opération asynchrone dans laquelle l'utilisateur vérifie un message reçu et saisit un code de connexion dans une interface de connexion. L'émulateur Authentication n'envoie aucun e-mail ni aucun SMS message, mais comme décrit ci-dessus, il génère des codes de connexion et les affiche dans le terminal pour être utilisés lors des tests.

L'émulateur n'est pas compatible avec la possibilité de définir des numéros de téléphone de test avec des codes de connexion fixes, comme cela peut être fait à l'aide de la Firebase console.

Authentification par jeton personnalisé

L'émulateur Authentication ne valide pas la signature ni l'expiration des jetons personnalisés. Cela vous permet d'utiliser des jetons créés manuellement et de les réutiliser indéfiniment dans les scénarios de prototypage et de test.

Limitation du débit / protection contre les abus

L'émulateur Authentication ne réplique pas les fonctionnalités de limitation du débit ni de protection contre les abus de production.

Fonctions de blocage

En production, les utilisateurs sont écrits dans le stockage une seule fois après le déclenchement des événements beforeCreate et beforeSignIn. Toutefois, en raison de limitations techniques, l'émulateur Authentication écrit dans le stockage deux fois : une fois après la création de l'utilisateur et une autre après la connexion. Cela signifie que pour les nouveaux utilisateurs, vous pouvez appeler getAuth().getUser() dans beforeSignIn dans l'émulateur Authentication, mais vous rencontrerez une erreur en production.

Et maintenant ?

• Pour obtenir un ensemble organisé de vidéos et des exemples pratiques détaillés, suivez la playlist de formation sur les émulateurs Firebase.

• Étant donné que les fonctions déclenchées sont une intégration typique avec Authentication, découvrez-en plus sur l'émulateur Cloud Functions pour Firebase dans la section Exécuter des fonctions localement.