L'objet utilisateur Firebase représente un compte utilisateur qui s'est inscrit pour une application dans 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 l'une de leurs méthodes.
Propriétés de l'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 directement d'autres propriétés à l'objet utilisateur ; à la place, 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é, 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 à l'aide de plusieurs méthodes : adresse e-mail et mot de passe, fournisseurs d'identité fédérée 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 d'utilisateur gardent une trace 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 perde 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 pas d'utilisateur actuel. Cependant, l'instance de l'utilisateur continue d'être entièrement fonctionnelle : si vous conservez une référence à celle-ci, 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é depuis 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 arriver 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 valide de jetons.
- 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 expirer automatiquement 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 informations d'identification de l'utilisateur aient été émises récemment ; 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 l'enlever) avec un minimum de friction.
Cependant, dans certaines situations, vous souhaitez que les utilisateurs soient créés manuellement ou par programme par un administrateur, à l'aide du SDK Admin ou de la console Firebase. Dans ces cas, vous pouvez désactiver les actions de l'utilisateur à 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 faire une requête HTTP pour désactiver ces fonctionnalités sur une base par locataire.
Si un utilisateur final tente de créer ou de supprimer un compte dans 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 avec élégance l'erreur sur votre front-end en demandant à l'utilisateur de prendre les mesures 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 en toute sécurité 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. Étant donné que l'intégrité des jetons d'ID peut être vérifiée , vous pouvez les envoyer à un serveur principal 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 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 :
- L'utilisateur termine le processus de vérification Firebase
- 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 fois, mais permettent ensuite aux utilisateurs de modifier les adresses e-mail sans nécessiter de re-vérification, ne sont pas fiables. Les IdP qui possèdent le domaine ou qui nécessitent toujours une vérification sont considérés comme fiables.
Prestataires 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 à plusieurs facteurs)
Fournisseurs non approuvés :
- GitHub
- Google, Yahoo et Microsoft pour les domaines non émis par ce fournisseur d'identité
- E-mail / Mot de passe sans vérification d'e-mail
Dans certaines situations, Firebase liera automatiquement les comptes lorsqu'un utilisateur se connecte à différents fournisseurs en utilisant la même adresse e-mail. Cependant, cela ne peut se produire que lorsque des critères spécifiques sont remplis. Pour comprendre pourquoi, considérez la situation suivante : un utilisateur se connecte en utilisant 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 les moments où nous associons automatiquement les comptes et quand nous renvoyons une erreur nécessitant une action de l'utilisateur ou du développeur :
- L'utilisateur se connecte avec un fournisseur non approuvé, puis se connecte avec un autre fournisseur non approuvé avec le même e-mail (par exemple, Facebook suivi de GitHub). Cela génère une erreur nécessitant une liaison de compte.
- L'utilisateur se connecte avec un fournisseur de confiance, puis se connecte avec un fournisseur non approuvé avec le même e-mail (par exemple, Google suivi de Facebook). Cela génère une erreur nécessitant une liaison de compte.
- L'utilisateur se connecte avec un fournisseur non approuvé, puis se connecte avec un fournisseur approuvé avec le même e-mail (par exemple, Facebook suivi de Google). Le fournisseur approuvé remplace le fournisseur non approuvé. Si l'utilisateur tente de se reconnecter avec Facebook, cela entraînera une erreur nécessitant la liaison du compte.
- L'utilisateur se connecte avec un fournisseur de confiance, puis se connecte avec un autre fournisseur de confiance avec le même 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.