Contexte
Ce document décrit les propriétés obligatoires pour les identifiants partagés utilisés dans les intégrations entre Google et un fournisseur (ou l'émetteur du compte de l'utilisateur). Un identifiant partagé est un bon point de départ : il s'agit d'un pointeur opaque vers une bordure entre un compte Google et un compte d'émetteur.
Par conséquent, il est important de garder à l'esprit que l'identifiant partagé ne fait pas référence au compte Google (ni à l'utilisateur ni à une autre entité dans l'espace de stockage de Google), ni au compte fournisseur/émetteur (ou toute autre entité). Il fait référence au lien entre les deux.
Propriétés des identifiants partagés
Les propriétés obligatoires pour les identifiants partagés découlent d'expériences passées et de problèmes techniques rencontrés en raison de l'absence de ces propriétés dans les identifiants partagés.
Pour une intégration entre Google et un partenaire externe, les identifiants partagés utilisés doivent impérativement avoir les propriétés suivantes:
- Être unique:cet identifiant partagé doit pointer vers un seul lien entre un utilisateur Google et un compte d'émetteur. Aucun autre identifiant partagé ne doit avoir la même valeur pour le même émetteur.
- Ils ne peuvent pas être devinés:ces identifiants partagés sont autorisés à agir au nom de l'utilisateur. Il est donc important qu'un tiers ne puisse pas deviner la valeur de l'identifiant partagé.
- Être révocable:il est important qu'un identifiant partagé puisse être révoqué par l'utilisateur. Cette révocation doit interdire toute utilisation ultérieure de la valeur de l'identifiant partagé.
Cette propriété a les quelques propriétés suivantes :
- Non basé sur une propriété immuable de l'un ou l'autre des comptes:si la valeur de l'identifiant partagé devait être basée sur une propriété immuable du compte de l'émetteur ou du compte Google, la recréation d'un identifiant partagé révoqué entraînera la même valeur de cet identifiant partagé (ce qui annulerait la révocation). La valeur de l'identifiant partagé ne doit donc pas être une propriété du compte ni un hachage de téléphone (par exemple, ne doit pas être un numéro de téléphone).
- Il ne doit pas s'agir simplement d'un <compte Google, compte partenaire> : la révocation doit être associée à une autre valeur (par exemple, le temps).
- Autoriser plusieurs associations au compte de chaque côté:il est important que la création de la valeur d'identifiant partagée ne empêche pas un utilisateur Google d'associer plusieurs comptes bancaires ni l'association de plusieurs comptes Google à un même compte bancaire (par exemple, un compte parent et un compte enfant associés tous deux au compte bancaire du parent). Comme pour la révocabilité, cette approche a plusieurs corollaires :
- Là encore, il ne s'agit pas d'une propriété immuable de l'un ou l'autre des comptes. Sinon, l'identifiant partagé aurait la même valeur lorsqu'un seul utilisateur Google a associé plusieurs comptes bancaires (si la valeur de l'identifiant partagée était basée sur le compte Google) ou si plusieurs comptes Google sont associés à un seul compte bancaire (si la valeur de l'identifiant partagé était basée sur une propriété du compte bancaire).
- Il doit avoir une longue durée de vie:l'identifiant partagé n'est valide que dans un contexte sécurisé (l'intégration entre Google et le fournisseur, qui utilise à la fois des protections au niveau de la connexion et au niveau de l'application (par exemple, PGP, SSL mutuel, etc.). Il n'a donc pas besoin de cycles de vie courts pour rester sécurisé. Google préfère que les identifiants partagés n'expirent jamais, mais si un fournisseur requiert une date d'expiration, celle-ci doit être longue (par exemple, plus d'un an).
Voici d'autres propriétés d'identifiant partagé recommandées:
- Base64:facilite le transport et la communication de la valeur dans l'intégration via HTTPS.
- Longueur minimale:nous vous recommandons d'utiliser au moins 27 chiffres (avant l'encodage en base64) pour disposer de suffisamment d'espace d'adressage pour éviter les conflits.
Qu'est-ce qui peut mal tourner ?
Voici quelques études de cas qui illustrent les problèmes rencontrés lorsque ces propriétés ne sont pas respectées pour aider le lecteur à comprendre les propriétés requises.
Études de cas sur les identifiants partagés
Étude de cas #1: Recyclage des numéros de téléphone
Émetteur qui a utilisé le numéro de téléphone de l'utilisateur comme identifiant partagé. Lorsque l'utilisateur A a changé de forfait téléphonique, il a abandonné son numéro de téléphone pour en obtenir un nouveau. Un mois plus tard, l'entreprise de téléphonie a recyclé l'ancien numéro de téléphone et soudainement, le nouveau propriétaire du numéro, l'utilisateur B, a commencé à être facturé sur son compte pour des articles qu'il n'achetait pas.
L'émetteur a enfreint de nombreuses propriétés d'identifiant partagé, principalement la propriété n° 1. Des éléments tels que les numéros de téléphone peuvent migrer d'un utilisateur à l'autre. Ils ne sont donc uniques que pour un instantané donné dans le temps.
Étude de cas n° 2: The Paste
Un employé de Google/Partner colle accidentellement un identifiant partagé dans un chat au lieu d'un outil interne. Des couches de protection supplémentaires empêchent toute personne malveillante d'utiliser l'identifiant partagé. Toutefois, par mesure de sécurité, Google a voulu révoquer l'identifiant partagé et le remplacer par un nouvel identifiant. Lorsque Google/un partenaire tente de révoquer l'identifiant partagé, il constate que les identifiants partagés ne sont que l'ID de compte de l'utilisateur dans le système de l'émetteur, et que l'identifiant partagé est utilisé pour rechercher directement le compte de l'utilisateur. Par conséquent, l'identifiant partagé ne peut pas être révoqué sans supprimer le compte de l'utilisateur et en créer un autre pour lui.
Étude de cas n° 3: Le mauvais employé
Après l'incident "Coller" ci-dessus, un acteur malveillant au sein de Google/partenaire se rend compte que, comme l'identifiant partagé n'est que l'ID de compte de l'utilisateur, s'il parvient à insérer l'ID de compte d'un autre utilisateur dans sa propre valeur d'identifiant partagée, il peut effectuer des achats sur le compte de cette autre personne. En raison d'une violation de la propriété n° 2, ce collage accidentel n'est plus qu'une faille de sécurité pour un seul utilisateur, mais une faille de sécurité pour chaque utilisateur.
Étude de cas n° 4: La rotation
Après l'incident "Coller" ci-dessus, l'émetteur bascule vers un UUID en tant que format d'identifiant partagé. Cette fois, un employé de l'émetteur envoie par erreur par e-mail certains des identifiants partagés en texte brut dans le cadre d'un thread de débogage de messagerie. Google dit : ne vous inquiétez pas, nous allons simplement révoquer et remplacer les identifiants partagés de l'utilisateur.
Dans le cadre de la rotation, Google indique à l'émetteur que chaque compte utilisateur piraté aura deux identifiants partagés actifs pendant une courte période, pendant le nettoyage de la base de données. Toutefois, l'émetteur n'a pas autorisé la propriété n° 4 et indique à Google qu'il est soumis à une contrainte selon laquelle un seul identifiant partagé peut être actif pour un compte utilisateur donné. Cela conduit à une rotation très désordonnée avec les conditions de concurrence.