Utilisateurs dans les projets Firebase

L'objet utilisateur Firebase représente un compte utilisateur qui s'est inscrit à une application de votre projet. Les applications ont généralement de nombreux utilisateurs enregistrés et chaque application d'un projet partage une base de données d'utilisateurs.

Les instances d'utilisateur sont indépendantes des instances d'authentification Firebase, vous pouvez donc avoir plusieurs références à différents utilisateurs dans le même contexte et toujours appeler n'importe laquelle de leurs méthodes.

Propriétés utilisateur

Les utilisateurs de Firebase disposent d'un ensemble fixe de propriétés de base (un identifiant unique, une adresse e-mail principale, un nom et une URL de photo) stockées dans la base de données des utilisateurs du projet, qui peuvent être mises à jour par l'utilisateur ( iOS , Android , web ). Vous ne pouvez pas ajouter d'autres propriétés directement à l'objet utilisateur ; au lieu de cela, vous pouvez stocker les propriétés supplémentaires dans n'importe quel autre service de stockage, comme Google Cloud Firestore.

La première fois qu'un utilisateur s'inscrit à votre application, les données de profil de l'utilisateur sont renseignées à l'aide des informations disponibles :

  • Si l'utilisateur s'est inscrit avec une adresse e-mail et un mot de passe, seule la propriété d'adresse e-mail principale est renseignée.
  • Si l'utilisateur s'est inscrit auprès d'un fournisseur d'identité fédérée, tel que Google ou Facebook, les informations de compte mises à disposition par le fournisseur sont utilisées pour remplir le profil de l'utilisateur.
  • Si l'utilisateur s'est inscrit avec votre système d'authentification personnalisé, vous devez explicitement ajouter les informations souhaitées au profil de l'utilisateur.

Une fois qu'un compte utilisateur a été créé, vous pouvez recharger les informations de l'utilisateur pour intégrer les modifications que l'utilisateur aurait pu apporter sur un autre appareil.

Fournisseurs de connexion

Vous pouvez connecter les utilisateurs à vos applications en utilisant plusieurs méthodes : adresse e-mail et mot de passe, fournisseurs d'identité fédérés et votre système d'authentification personnalisé. Vous pouvez associer plusieurs méthodes de connexion à un utilisateur : par exemple, un utilisateur peut se connecter au même compte à l'aide d'une adresse e-mail et d'un mot de passe, ou à l'aide de Google Sign-In.

Les instances utilisateur assurent le suivi de chaque fournisseur lié à l'utilisateur. Cela vous permet de mettre à jour les propriétés d'un profil vide en utilisant les informations fournies par un fournisseur. Voir Gestion des utilisateurs ( iOS , Android , Web ).

L'utilisateur actuel

Lorsqu'un utilisateur s'inscrit ou se connecte, cet utilisateur devient l'utilisateur actuel de l'instance Auth. L'instance conserve l'état de l'utilisateur, de sorte que l'actualisation de la page (dans un navigateur) ou le redémarrage de l'application ne perdent pas les informations de l'utilisateur.

Lorsque l'utilisateur se déconnecte, l'instance Auth cesse de conserver une référence à l'objet utilisateur et ne conserve plus son état ; il n'y a aucun utilisateur actuel. Cependant, l'instance utilisateur continue d'être entièrement fonctionnelle : si vous en conservez une référence, vous pouvez toujours accéder et mettre à jour les données de l'utilisateur.

Le cycle de vie de l'utilisateur

La méthode recommandée pour suivre l'état actuel de l'instance Auth consiste à utiliser des écouteurs (également appelés « observateurs » en JavaScript). Un écouteur Auth est averti chaque fois que quelque chose de pertinent arrive à l'objet Auth. Voir Gestion des utilisateurs ( iOS , Android , Web ).

Un écouteur Auth est averti dans les situations suivantes :

  • L'objet Auth termine son initialisation et un utilisateur était déjà connecté lors d'une session précédente ou a été redirigé depuis le flux de connexion d'un fournisseur d'identité.
  • Un utilisateur se connecte (l'utilisateur actuel est défini)
  • Un utilisateur se déconnecte (l'utilisateur actuel devient nul)
  • Le jeton d'accès de l'utilisateur actuel est actualisé. Ce cas peut se produire dans les conditions suivantes :
    • Le jeton d’accès expire : c’est une situation courante. Le jeton d'actualisation est utilisé pour obtenir un nouvel ensemble de jetons valide.
    • L'utilisateur modifie son mot de passe : Firebase émet de nouveaux jetons d'accès et d'actualisation et rend les anciens jetons expirés. Cela fait automatiquement expirer le jeton de l'utilisateur et/ou déconnecte l'utilisateur sur chaque appareil, pour des raisons de sécurité.
    • L'utilisateur se réauthentifie : certaines actions nécessitent que les identifiants de l'utilisateur soient récemment émis ; ces actions incluent la suppression d'un compte, la définition d'une adresse e-mail principale et la modification d'un mot de passe. Au lieu de déconnecter l'utilisateur, puis de le reconnecter, obtenez de nouvelles informations d'identification de l'utilisateur et transmettez les nouvelles informations d'identification à la méthode de réauthentification de l'objet utilisateur.

Libre-service utilisateur

Par défaut, Firebase permet aux utilisateurs de s'inscrire et de supprimer leurs comptes sans intervention administrative. Dans de nombreuses circonstances, cela permet aux utilisateurs finaux de découvrir votre application ou service et de l'intégrer (ou de le désactiver) avec un minimum de frictions.

Il existe cependant des situations dans lesquelles vous souhaitez que les utilisateurs soient créés manuellement ou par programme par un administrateur, soit à l'aide du SDK Admin, soit de la console Firebase. Dans ces cas, vous pouvez désactiver les actions des utilisateurs à partir de la page Paramètres d'authentification Firebase , ce qui empêche la création et la suppression de comptes par les utilisateurs finaux. Si vous utilisez la multilocation, vous devrez effectuer une requête HTTP pour désactiver ces fonctionnalités pour chaque locataire.

Si un utilisateur final tente de créer ou de supprimer un compte sur votre système, le service Firebase renverra un code d'erreur : auth/admin-restricted-operation pour les appels d'API Web ou ERROR_ADMIN_RESTRICTED_OPERATION pour Android et iOS. Vous devez gérer gracieusement l'erreur sur votre front-end en demandant à l'utilisateur de prendre les actions appropriées pour votre service.

Jetons d'authentification

Lorsque vous effectuez une authentification avec Firebase, vous pouvez rencontrer trois types de jetons d'authentification :

Jetons d'identification Firebase Créé par Firebase lorsqu'un utilisateur se connecte à une application. Ces jetons sont des JWT signés qui identifient de manière sécurisée un utilisateur dans un projet Firebase. Ces jetons contiennent des informations de profil de base pour un utilisateur, y compris la chaîne d'identification de l'utilisateur, qui est unique au projet Firebase. L'intégrité des jetons d'identification pouvant être vérifiée , vous pouvez les envoyer à un serveur principal pour identifier l'utilisateur actuellement connecté.
Jetons du fournisseur d'identité Créé par des fournisseurs d'identité fédérés, tels que Google et Facebook. Ces jetons peuvent avoir différents formats, mais sont souvent des jetons d'accès OAuth 2.0. Les applications utilisent ces jetons pour vérifier que les utilisateurs se sont authentifiés avec succès auprès du fournisseur d'identité, puis les convertissent en informations d'identification utilisables par les services Firebase.
Jetons personnalisés Firebase Créé par votre système d'authentification personnalisé pour permettre aux utilisateurs de se connecter à une application à l'aide de votre système d'authentification. Les jetons personnalisés sont des JWT signés à l'aide de la clé privée d'un compte de service . Les applications utilisent ces jetons de la même manière qu’elles utilisent les jetons renvoyés par les fournisseurs d’identité fédérés.

Adresses e-mail vérifiées

Firebase considère qu'un e-mail est vérifié s'il remplit deux conditions :

  1. L'utilisateur termine le flux de vérification Firebase
  2. L'e-mail est vérifié par un fournisseur d'identité de confiance, ou IdP en abrégé.

Les fournisseurs d'identité qui vérifient les e-mails une seule fois, mais permettent ensuite aux utilisateurs de modifier leurs adresses e-mail sans nécessiter une nouvelle vérification, ne sont pas fiables. Les fournisseurs d'identité qui possèdent le domaine ou qui nécessitent toujours une vérification sont considérés comme fiables.

Fournisseurs de confiance :

  • Google (pour les adresses @gmail.com)
  • Yahoo (pour les adresses @yahoo.com)
  • Microsoft (pour les adresses @outlook.com et @hotmail.com)
  • Apple (toujours vérifié, car les comptes sont toujours vérifiés et authentifiés par plusieurs facteurs)

Fournisseurs non fiables :

  • Facebook
  • Twitter
  • GitHub
  • Google, Yahoo et Microsoft pour les domaines non émis par ce fournisseur d'identité
  • Email / Mot de passe sans vérification de l'e-mail

Dans certaines situations, Firebase associera automatiquement les comptes lorsqu'un utilisateur se connectera auprès de différents fournisseurs en utilisant la même adresse e-mail. Toutefois, cela ne peut se produire que lorsque des critères spécifiques sont remplis. Pour comprendre pourquoi, considérons la situation suivante : un utilisateur se connecte à l'aide de Google avec un compte @gmail.com et un acteur malveillant crée un compte en utilisant la même adresse @gmail.com, mais en se connectant via Facebook. Si ces deux comptes étaient automatiquement liés, l'acteur malveillant aurait accès au compte de l'utilisateur.

Les cas suivants décrivent quand nous lions automatiquement les comptes et quand nous générons une erreur nécessitant une action de l'utilisateur ou du développeur :

  • L'utilisateur se connecte auprès d'un fournisseur non fiable, puis se connecte auprès d'un autre fournisseur non fiable avec la même adresse e-mail (par exemple, Facebook suivi de GitHub). Cela génère une erreur nécessitant la liaison du compte.
  • L'utilisateur se connecte auprès d'un fournisseur de confiance, puis se connecte auprès d'un fournisseur non fiable avec la même adresse e-mail (par exemple, Google suivi de Facebook). Cela génère une erreur nécessitant la liaison du compte.
  • L'utilisateur se connecte auprès d'un fournisseur non fiable, puis se connecte auprès d'un fournisseur de confiance avec la même adresse e-mail (par exemple, Facebook suivi de Google). Le fournisseur approuvé écrase le fournisseur non approuvé. Si l'utilisateur tente de se reconnecter avec Facebook, cela provoquera une erreur nécessitant la liaison du compte.
  • L'utilisateur se connecte auprès d'un fournisseur de confiance, puis se connecte auprès d'un autre fournisseur de confiance avec la même adresse e-mail (par exemple, Apple suivi de Google). Les deux fournisseurs seront liés sans erreur.

Vous pouvez définir manuellement un e-mail comme vérifié à l'aide du SDK Admin, mais nous vous recommandons de ne le faire que si vous savez que l'utilisateur est réellement propriétaire de l'e-mail.