Propriedades do identificador compartilhado do fornecedor do Google

Contexto

Neste documento, abordamos as propriedades obrigatórias para identificadores compartilhados usados em integrações entre o Google e um fornecedor (ou emissor da conta para o usuário). Uma boa maneira de pensar em um identificador compartilhado é que ele é um ponteiro opaco para uma borda entre uma Conta do Google e uma conta de emissor.

Portanto, é importante lembrar que o identificador compartilhado não se refere à Conta do Google (ou ao usuário ou outra entidade no armazenamento do Google) nem à conta do fornecedor/emissor (ou outra entidade). Ela se refere ao vínculo entre os dois.

Propriedades do identificador compartilhado

As propriedades obrigatórias dos identificadores compartilhados nascem da experiência anterior e de problemas técnicos encontrados como resultado da falta dessas propriedades em identificadores compartilhados.

Para uma integração entre o Google e um parceiro externo, é fundamental que os identificadores compartilhados usados tenham as seguintes propriedades:

  1. Ser globalmente exclusivo:esse identificador compartilhado precisa apontar para exatamente um link entre um usuário do Google e uma conta de emissor. Não pode haver outro identificador compartilhado para o mesmo emissor que tenha o mesmo valor.
  2. Não adivinhe:esses identificadores compartilhados têm permissão para agir em nome do usuário. Por isso, é importante que terceiros não consigam adivinhar o valor do identificador compartilhado.
  3. Ser revogável: é importante que um identificador compartilhado possa ser revogado pelo usuário, e essa revogação deve proibir qualquer uso futuro do valor do identificador compartilhado. Essa propriedade tem algumas propriedades secundárias a seguir:
    • Não se baseia em uma propriedade imutável de qualquer uma das contas:se o valor do identificador compartilhado tivesse como base uma propriedade imutável da conta do emissor ou da Conta do Google, a recriação de um identificador compartilhado revogado resultaria no mesmo valor desse identificador compartilhado (desfazendo a revogação), e o valor do identificador compartilhado não poderia ser um número de hash da conta (por exemplo, um número de hash de um telefone).
    • Não ser apenas <Conta do Google ou do parceiro>: é preciso haver outro valor (por exemplo, tempo) para permitir a revogação.
  4. Permitir vários links para a conta em ambos os lados:é importante que a criação do valor do identificador compartilhado não torne impossível que um único usuário do Google vincule várias contas bancárias ou que mais de uma Conta do Google seja vinculada a uma única conta bancária (por exemplo, uma conta mãe e uma filha vinculadas à conta bancária do familiar responsável). Semelhante à revogação, essa opção tem alguns corolários:
    • Novamente, não com base em uma propriedade imutável de qualquer uma das contas. Caso contrário, o identificador compartilhado teria o mesmo valor quando um único usuário do Google tivesse vinculado várias contas bancárias (se o valor do identificador compartilhado tivesse sido baseado na Conta do Google) ou se várias Contas do Google estivessem vinculadas a uma única conta bancária (se o valor do identificador compartilhado fosse baseado em uma propriedade da conta bancária).
  5. Duração longa: o identificador compartilhado só é válido em um contexto seguro, ou seja, a integração entre o Google e o fornecedor, que usa proteções no nível da conexão e do aplicativo (por exemplo, PGP, SSL mútuo etc.). Portanto, não é necessário um ciclo de vida curto para permanecer seguro. A preferência do Google é que os identificadores compartilhados nunca expirem, mas se um fornecedor exigir um período de validade, ele precisa ser um longo período (por exemplo, mais de um ano).

Outras propriedades de identificador compartilhado recomendadas são:

  1. Base64:facilita o transporte e a comunicação do valor na integração por HTTPS.
  2. Comprimento mínimo:um mínimo de 27 dígitos (antes da codificação Base64) é recomendado para garantir que haja muito espaço de endereço a fim de evitar colisões.

O que pode dar errado?

Para ajudar o leitor a entender as propriedades necessárias, estes são alguns estudos de caso que ilustram os problemas encontrados quando essas propriedades não são respeitadas.

Estudos de caso de identificadores compartilhados

Estudo de caso no 1: reciclagem de números de telefone

Um emissor que usou o número de telefone do usuário como identificador compartilhado. Quando o usuário A trocou de plano de telefone, ele desistiu do número e comprou um novo. Um mês depois, a empresa reciclou o número de telefone antigo e, de repente, o novo proprietário dele, o usuário B, começou a receber cobranças na conta por itens que não estavam comprando.

O emissor violou muitas propriedades de identificador compartilhado, principalmente a propriedade 1. Itens como números de telefone podem ser migrados de usuário para usuário. Portanto, eles são exclusivos apenas durante um snapshot específico no tempo.

Estudo de caso no 2: The Paste

Um funcionário do Google/parceiro cola acidentalmente um identificador compartilhado em um chat em vez de uma ferramenta interna. Camadas extras de proteção impedem que qualquer pessoa use o identificador compartilhado de forma maliciosa, mas, para garantir a segurança, o Google queria revogar o identificador compartilhado e substituí-lo por um novo. Quando o Google/parceiro tenta revogar o identificador compartilhado, ele descobre que os identificadores compartilhados são apenas o ID da conta do usuário no sistema do emissor, e o identificador compartilhado é usado para pesquisar diretamente a conta do usuário. Portanto, o identificador compartilhado não poderia ser revogado sem excluir a conta do usuário e criar uma nova.

Estudo de caso no 3: o mau funcionário

Após o incidente "The Paste" acima, um usuário de má-fé do Google/parceiro percebe que, como o identificador compartilhado é apenas o ID da conta do usuário, se ele consegue colocar o ID da conta de outra pessoa no próprio valor de identificador compartilhado, pode fazer compras na conta dessa outra pessoa. A violação da propriedade no 2 fez com que essa colagem acidental seja mais do que uma falha de segurança para um único usuário, porque é uma falha de segurança para todos.

Estudo de caso no 4: a rotação

Após o incidente "The Paste" acima, o emissor muda para um UUID como formato de identificador compartilhado. Desta vez, um funcionário do emissor envia por engano alguns dos identificadores compartilhados em texto simples como parte de uma conversa de e-mail de depuração. O Google diz: "Não se preocupe. Vamos revogar e substituir os identificadores compartilhados do usuário.

Como parte da rotação, o Google informa ao emissor que cada conta de usuário comprometida terá dois identificadores compartilhados ativos por um curto período enquanto a limpeza do banco de dados estiver em andamento. Mas o emissor não permitiu a Propriedade no 4 e informa ao Google que tem uma restrição de que apenas um identificador compartilhado pode estar ativo para uma conta de usuário específica. Isso leva a uma rotação muito confusa com disputas.