Catch up on everthing we announced at this year's Firebase Summit. Learn more

Utilisateurs dans les projets Firebase

L'objet utilisateur Firebase représente un compte d'utilisateur qui a signé 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 utilisateur sont indépendantes des instances Firebase Authentication, 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 Firebase ont un ensemble fixe de propriétés d' une base ID unique, une adresse e - mail principale, un nom et une photo d' URL stockées dans la base de données utilisateur du projet, qui peut être mis à 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 renseigner le profil de l'utilisateur
  • Si l'utilisateur s'est inscrit avec votre système d'authentification personnalisé, vous devez explicitement ajouter les informations que vous souhaitez 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 a 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é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 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 utilisateur continue d'être complètement fonctionnelle : si vous gardez 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 d'important arrive à l'objet Auth. Voir Gestion des utilisateurs ( iOS , Android , Web ).

Un écouteur Auth reçoit une notification dans les situations suivantes :

  • L'objet Auth termine l'initialisation et un utilisateur était déjà 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 (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 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 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 informations d'identification de l'utilisateur soient récemment émises ; 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.

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'ID de l'utilisateur, qui est unique au projet Firebase. Parce que l'intégrité des jetons d'identité peut être vérifiée , vous pouvez les envoyer à un serveur principal d'identifier le haut -signé utilisateur actuellement.
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 sont souvent des jetons d'accès OAuth 2.0. Les applications utilisent ces jetons pour vérifier que les utilisateurs se sont correctement authentifiés auprès du fournisseur d'identité, puis les convertissent en identifiants 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. Jetons personnalisés sont JWTs signés avec 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 IdP qui vérifient les e-mails une fois, mais permettent ensuite aux utilisateurs de modifier les adresses e-mail sans nécessiter de nouvelle vérification, ne sont pas dignes de confiance. Les IdP qui possèdent le domaine ou nécessitent toujours une vérification sont considérés comme dignes de confiance.

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é
  • E-mail / Mot de passe sans vérification d'e-mail

Dans certaines situations, Firebase associe 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érons 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 quand nous lions automatiquement des comptes et quand nous lançons une erreur nécessitant une action de l'utilisateur ou du développeur :

  • L'utilisateur se connecte avec un fournisseur non fiable, puis se connecte avec un autre fournisseur non fiable 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 fiable 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 fiable, puis se connecte avec un fournisseur de confiance avec le même e-mail (par exemple, Facebook suivi de Google). Le fournisseur approuvé remplace le fournisseur non approuvé. Si l'utilisateur essaie de se reconnecter avec Facebook, cela provoquera une erreur nécessitant l'association 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.