Utilisateurs d'Identity Platform dans les projets

L'objet user Identity Platform représente un compte utilisateur qui s'est inscrit à une application dans votre projet Google Cloud. Les applications comptent généralement de nombreux utilisateurs enregistrés, et chaque application d'un projet Google Cloud partage une base de données d'utilisateurs.

Les instances utilisateur sont indépendantes des instances Identity Platform. Vous pouvez donc faire référence à plusieurs utilisateurs dans le même contexte, tout en appelant n'importe laquelle de leurs méthodes.

Propriétés utilisateur

Les utilisateurs d'Identity Platform disposent d'un ensemble fixe de propriétés de base (un ID unique, une adresse e-mail principale, un nom et une URL de photo) stockées dans la base de données d'utilisateurs du projet, que l'utilisateur peut mettre à jour (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 : Identity Platform é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, Identity Platform permet aux utilisateurs de s'inscrire et de supprimer leurs comptes sans intervention administrative. 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, dans certains cas, vous souhaiterez que les utilisateurs soient créés manuellement ou de manière automatisée par un administrateur, à l'aide du SDK Admin ou de la console Google Cloud. Dans ce cas, vous pouvez désactiver les actions des utilisateurs sur la page des paramètres d'Identity Platform, 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 Identity Platform 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 effectuez une authentification avec Identity Platform, vous pouvez rencontrer trois types de jetons d'authentification :

Jetons d'ID Identity Platform Créés par Identity Platform 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 Google Cloud. 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 Google Cloud. É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 ont bien été authentifiés avec le fournisseur d'identité, puis les convertir en identifiants utilisables par les services Identity Platform.
Jetons personnalisés Identity Platform 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

Identity Platform considère qu'une adresse e-mail est validée si elle remplit deux conditions:

  1. L'utilisateur suit la procédure de validation Identity Platform.
  2. 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 :

  • Facebook
  • Twitter
  • 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, Identity Platform 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.