L'objet user Firebase représente un compte utilisateur ayant signé pour une application projet. Les applications comptent généralement de nombreux utilisateurs inscrits, et toutes les applications d'une partage une base de données utilisateur.
Les instances Utilisateur sont indépendantes des instances Firebase Authentication. Vous pouvez donc avoir plusieurs références à différents utilisateurs dans le même contexte, tout en appelant de leurs méthodes.
Propriétés utilisateur
Les utilisateurs de Firebase disposent d'un ensemble fixe de propriétés de base : une pièce d'identité, une adresse e-mail principale, un nom et une URL de photo, stockés dans le la base de données utilisateur du projet, qui peut être mise à jour par l'utilisateur (iOS, Android Web). Vous ne pouvez pas ajouter directement d'autres propriétés à l'objet utilisateur ; à la place, vous pouvez stocker les propriétés supplémentaires dans d'autres services de stockage, tels que Google Cloud Firestore.
La première fois qu'un utilisateur s'inscrit à votre application, ses données de profil 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é de l'adresse e-mail principale est spécifiée.
- Si l'utilisateur s'est inscrit auprès d'un fournisseur d'identité fédéré, tel que Google ou Facebook, les informations de compte mise à disposition par le fournisseur sont utilisées pour renseigner le profil de l'utilisateur.
- Si l'utilisateur s'est inscrit avec votre système d'authentification personnalisé, vous devez ajouter explicitement les informations que vous souhaitez voir dans son profil.
Une fois le compte utilisateur créé, vous pouvez actualiser les informations de l'utilisateur pour intégrer les modifications qu'il pourrait apporter sur un autre appareil.
Fournisseurs de connexion
Vous pouvez connecter les utilisateurs à vos applications à l'aide de plusieurs méthodes : adresse e-mail et mot de passe, fournisseurs d'identité fédérés et 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 via une adresse e-mail et un mot de passe, ou utiliser Google Sign-In.
Les instances utilisateur conservent la trace de tous les fournisseurs associés à l'utilisateur. Cela vous permet de mettre à jour les propriétés d'un profil vide à l'aide des informations fournies par un fournisseur. Consultez la section "Gérer les utilisateurs" (iOS, Android, Web).
Utilisateur actuel
Lorsqu'un utilisateur s'inscrit ou se connecte, il devient l'utilisateur actuel de l'instance Auth. L'instance conserve l'état de l'utilisateur de sorte que ses informations ne soient pas perdues lors de l'actualisation de la page (dans un navigateur) ou du redémarrage de l'application.
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 pas d'utilisateur actuel. Cependant, l'instance utilisateur continue d'être entièrement fonctionnelle : si vous conservez une référence à celle-ci, vous pouvez toujours accéder aux données de l'utilisateur et les mettre à jour.
Cycle de vie du compte utilisateur
La méthode recommandée pour suivre l'état actuel de l'instance Auth consiste à utiliser des écouteurs (également appelés "observateurs" dans JavaScript). Un écouteur Auth est averti chaque fois qu'un événement pertinent se produit pour l'objet Auth. Consultez la section "Gérer les utilisateurs" (iOS, Android, Web).
Un écouteur Auth est averti dans les situations suivantes :
- L'objet Auth finit de s'initialiser et un utilisateur a déjà été connecté à partir 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 (il n'y a plus d'utilisateur actuel).
- Le jeton d'accès de l'utilisateur actuel est actualisé. Ce cas de figure peut se présenter dans les situations suivantes :
- Le jeton d'accès expire : il s'agit d'une situation courante. Le jeton d'actualisation permet d'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 affiche les anciens jetons expirés. Cela fait automatiquement expirer le jeton de l'utilisateur et/ou déconnecte l'utilisateur de chaque appareil pour des raisons de sécurité.
- L'utilisateur se réauthentifie : certaines actions exigent que les identifiants de l'utilisateur aient récemment été émis. Ces actions incluent la suppression et la définition d'une adresse e-mail principale et la modification d'un mot de passe. Au lieu de déconnecter puis reconnecter l'utilisateur, récupérez les nouveaux identifiants de l'utilisateur et transmettez-les à 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 de l'administrateur. Dans de nombreux cas, cela permet aux utilisateurs finaux de découvrir votre application ou votre service, et de l'intégrer (ou de le quitter) avec un minimum de friction.
Toutefois, il y a des situations dans lesquelles vous voulez que les utilisateurs soient par un administrateur, à l'aide du SDK Admin ou Console Firebase. Vous pouvez alors désactiver les actions utilisateur dans les Paramètres Firebase Authentication ce qui empêche les utilisateurs finaux de créer et de supprimer des comptes. Si vous utilisez l'architecture mutualisée, vous devez envoyer 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 dans votre système, le service Firebase renvoie le code d'erreur auth/admin-restricted-operation pour les appels de l'API Web ou ERROR_ADMIN_RESTRICTED_OPERATION pour Android et iOS. Vous devez volontiers gérer l'erreur du système frontal en demandant à l'utilisateur d'effectuer les actions appropriées pour votre service.
Jetons d'authentification
Lorsque vous vous authentifiez avec Firebase, vous disposez de trois types de jetons d'authentification que vous pourriez rencontrer:
| Firebase jetons d'ID | Créés par Firebase lorsqu'un utilisateur se connecte à une application. Ces jetons sont des jetons 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 une user, y compris la chaîne d'identifiant de l'utilisateur, qui est unique au Projet Firebase. Étant donné que l'intégrité des jetons d'ID peut être validée, vous pouvez envoyer ces jetons à un serveur backend pour identifier l'utilisateur actuellement connecté. |
| Jetons de 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 il s'agit souvent de jetons d'accès OAuth 2.0. Les applications utilisent ces jetons pour vérifier que les utilisateurs s'authentifient auprès du fournisseur d'identité, puis les convertissent en identifiants utilisables par les services Firebase. |
| Firebase jetons personnalisés | Créés par votre système d'authentification personnalisé, afin de permettre aux utilisateurs de se connecter à une application à l'aide de votre système d'authentification. Les jetons personnalisés sont des jetons JWT signés à l'aide de la clé privée d'un compte de service. Les applications utilisent ces jetons quasiment 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 validées
Firebase considère qu'une adresse e-mail est validée si elle remplit deux conditions:
- L'utilisateur suit la procédure de validation de Firebase
- L'adresse e-mail est validée par un fournisseur d'identité (IdP) approuvé.
Les IdP qui ne valident les adresses e-mail qu'une fois puis autorisent les utilisateurs à modifier ces adresses e-mail sans nouvelle validation ne sont pas approuvés. Les IdP qui sont propriétaires du domaine ou qui nécessitent toujours une validation sont considérés comme approuvés.
Fournisseurs approuvés :
- Google (pour les adresses @gmail.com)
- Yahoo (pour les adresses @yahoo.com)
- Microsoft (pour les adresses @outlook.com et @hotmail.com)
- Apple (adresses toujours validées, car les comptes sont toujours validés et bénéficient d'une authentification multifacteur)
Fournisseurs non approuvés :
- GitHub
- Google, Yahoo et Microsoft pour les domaines non émis par le fournisseur d'identité concerné
- Adresse e-mail/Mot de passe sans validation de l'adresse e-mail
Dans certains cas, Firebase associe automatiquement des comptes lorsqu'un utilisateur se connecte avec des comptes créés chez différents fournisseurs, pour lesquels il utilise la même adresse e-mail. Cela ne peut toutefois se produire que lorsque des critères spécifiques sont remplis. Pour comprendre pourquoi, considérons la situation suivante : un utilisateur se connecte avec un compte @gmail.com fourni par Google, et un individu malveillant crée un compte avec la même adresse @gmail.com, mais se connecte via Facebook. Si ces deux comptes étaient automatiquement associés, l'individu malveillant pourrait accéder au compte de l'utilisateur.
Vous trouverez ci-dessous les cas où nous associons automatiquement des comptes, et ceux pour lesquels nous générons volontairement une erreur nécessitant une action de la part de l'utilisateur ou du développeur :
- L'utilisateur se connecte via un fournisseur non approuvé, puis se connecte via un autre fournisseur non approuvé en utilisant la même adresse e-mail (par exemple, Facebook suivi de GitHub). Ce cas de figure entraîne une erreur, et une association des comptes est requise.
- L'utilisateur se connecte via un fournisseur approuvé, puis se connecte via un fournisseur non approuvé en utilisant la même adresse e-mail (par exemple, Google suivi de Facebook). Ce cas de figure entraîne une erreur, et une association des comptes est requise.
- L'utilisateur se connecte via un fournisseur non approuvé, puis se connecte via un fournisseur approuvé en utilisant la même adresse e-mail (par exemple, Facebook suivi de Google). Le fournisseur approuvé remplace le fournisseur non approuvé. Si l'utilisateur tente de se connecter à nouveau avec Facebook, une erreur est générée, et une association des comptes est requise.
- L'utilisateur se connecte via un fournisseur approuvé, puis se connecte via un autre fournisseur approuvé en utilisant la même adresse e-mail (par exemple, Apple suivi de Google). Les deux fournisseurs sont associés, et aucune erreur n'est générée.
Vous pouvez valider manuellement une adresse e-mail à l'aide du SDK Admin, mais nous vous recommandons de ne le faire que si vous savez que l'utilisateur est bien propriétaire de l'adresse e-mail.