Usuários do Identity Platform em projetos

O objeto usuário do Identity Platform representa uma conta de usuário inscrita em um app no projeto do Google Cloud. Normalmente, os apps têm muitos usuários registrados e, em um projeto do Google Cloud, todos os apps compartilham um banco de dados de usuários.

As instâncias do usuário são independentes das instâncias do Identity Platform. Por isso, é possível ter várias referências a diferentes usuários dentro do mesmo contexto e ainda chamar qualquer um dos métodos deles.

Propriedades do usuário

Os usuários do Identity Platform têm um conjunto fixo de propriedades básicas (um ID exclusivo, um endereço de e-mail principal, um nome e um URL de foto) armazenados no banco de dados de usuários do projeto, que podem ser atualizados pelo usuário (iOS, Android e Web). Não é possível adicionar outras propriedades diretamente ao objeto "user". Em vez disso, armazene as propriedades adicionais em qualquer outro serviço de armazenamento, como o Google Cloud Firestore.

Quando um usuário se registra no seu app, os dados do perfil dele são preenchidos com as informações disponíveis:

  • Se o usuário fez login com um endereço de e-mail e uma senha, somente a propriedade do endereço de e-mail principal será preenchida.
  • Se o usuário fez login com um provedor de identidade federado, como Google ou Facebook, as informações da conta disponibilizadas por esse provedor serão usadas para preencher o perfil dele.
  • Se o usuário fez login com seu sistema personalizado de autenticação, será preciso adicionar explicitamente as informações necessárias ao perfil do usuário.

Após a criação da conta de usuário, você pode atualizar as informações dela para incorporar alterações que o usuário fez em outro dispositivo.

Provedores de login

É possível permitir que usuários façam login nos seus apps usando vários métodos: endereço de e-mail e senha, provedores de identidade federados e um sistema personalizado de autenticação. Você também pode associar mais de um método de login a um usuário permitindo, por exemplo, que ele faça login na mesma conta usando um endereço de e-mail e uma senha ou o Login do Google.

As instâncias do usuário monitoram todos os provedores vinculados ao usuário. Isso permite que as propriedades em branco do perfil sejam atualizadas com as informações fornecidas por um provedor. Consulte o artigo "Como gerenciar usuários" (iOS, Android, Web).

O usuário atual

Quando um usuário se registra ou faz login, ele se torna o usuário atual da instância de autenticação, e ela mantém o estado do usuário. Portanto, a atualização da página em um navegador ou a reinicialização do aplicativo não resultará na perda de informações do usuário.

Quando o usuário sai do aplicativo, a instância do Auth descarta a referência ao objeto User e ao estado dele. Logo, não há usuário atual. No entanto, a instância de usuário continua completamente funcional. Se você mantiver uma referência a ela, ainda poderá acessar e atualizar os dados do usuário.

O ciclo de vida do usuário

A forma recomendada de rastrear o estado atual da instância de autenticação é usar listeners (também chamados de "observadores" no JavaScript). Eles recebem uma notificação sempre que algo relevante acontece com o objeto Auth. Consulte o artigo "Como gerenciar usuários" (iOS, Android, Web).

Um listener de autenticação é notificado nas seguintes situações:

  • O objeto Auth termina a inicialização, mas o usuário já havia feito login em uma sessão anterior ou foi redirecionado do fluxo de login de um provedor de identidade.
  • Um usuário faz login (o usuário atual está definido).
  • Um usuário sai (o usuário atual se torna nulo).
  • O token de acesso do usuário atual é atualizado. Isso pode acontecer nas seguintes condições:
    • O token de acesso expira: uma situação comum. O token de atualização é usado para acessar um novo conjunto válido de tokens.
    • O usuário altera a senha: o Identity Platform emite novos tokens de acesso e de atualização e renderiza os antigos. Com isso, o token do usuário expira e/ou é desvinculado automaticamente de todos os dispositivos por motivos de segurança.
    • O usuário se autentica novamente: algumas ações, como exclusão da conta, configuração de endereço de e-mail principal e alteração da senha, exigem emissão recente das credenciais do usuário. Em vez de desconectar o usuário e fazer o login dele novamente, adquira novas credenciais do usuário e transmita para o método de reautenticação do objeto "user".

Autoatendimento do usuário

Por padrão, o Identity Platform permite que os usuários se inscrevam e excluam as contas sem intervenção administrativa. Em muitas circunstâncias, isso permite que os usuários finais descubram seu aplicativo ou serviço e integrem (ou desfaçam a integração) com o mínimo de atrito.

No entanto, há situações em que você quer que os usuários sejam criados manual ou programaticamente por um administrador, usando o SDK Admin ou o console do Google Cloud. Nesses casos, é possível desativar as ações do usuário na página de configurações do Identity Platform, o que impede a criação e a exclusão de contas por um usuário final. Caso use a multilocação, será necessário fazer uma solicitação HTTP para desativar esses recursos por locatário.

Se um usuário final tentar criar ou excluir uma conta no sistema, o serviço do Identity Platform retornará um código de erro: auth/admin-restricted-operation para chamadas de API da Web ou ERROR_ADMIN_RESTRICTED_OPERATION para Android e iOS. Lide com o erro no seu front-end pedindo que o usuário realize as ações apropriadas para seu serviço.

Tokens de autenticação

Ao executar a autenticação com o Identity Platform, há três tipos de tokens de autenticação que podem ser encontrados:

Tokens de ID do Identity Platform Criado pelo Identity Platform quando um usuário faz login em um app. Esses tokens são JWTs assinados que identificam um usuário com segurança em um projeto do Google Cloud. Esses tokens contêm informações básicas de perfil para um usuário, incluindo a string de ID do usuário, que é exclusiva do projeto do Google Cloud. Já que é possível verificar a integridade dos tokens de ID, envie-os a um servidor de back-end para identificar o usuário conectado no momento.
Tokens de provedor de identidade Criados por provedores de identidade federados, como Google e Facebook. Eles podem ter formatos diferentes, mas costumam ser tokens de acesso OAuth 2.0. Os apps usam esses tokens para verificar se os usuários foram autenticados com o provedor de identidade e convertê-los em credenciais que podem ser usadas pelos serviços do Identity Platform.
Tokens personalizados do Identity Platform São criados pelo seu sistema personalizado de autenticação para permitir que os usuários façam login em um app usando seu sistema de autenticação. Os tokens personalizados são JWTs assinados usando a chave privada de uma conta de serviço. A maneira como os apps utilizam esses tokens é parecida com o uso de tokens retornados dos provedores de identidade federados.

Endereços de e-mail verificados

O Identity Platform considera um e-mail verificado se atender a duas condições:

  1. O usuário conclui o fluxo de verificação do Identity Platform
  2. O e-mail foi verificado por um provedor de identidade (IdP) confiável.

Os IdPs que verificam um e-mail uma vez e permitem que os usuários o altere sem exigir uma nova verificação não são confiáveis. Os IdPs que são proprietários do domínio ou que sempre exigem a verificação são considerados confiáveis.

Provedores de confiança:

  • Google (para endereços @gmail.com)
  • Yahoo (para endereços @yahoo.com)
  • Microsoft (para endereços @outlook.com e @hotmail.com)
  • Apple (sempre verificada, porque as contas são analisadas com frequência e têm autenticação multifator)

Provedores não confiáveis:

  • Facebook
  • Twitter
  • GitHub
  • Google, Yahoo e Microsoft para domínios não emitidos por esse provedor de identidade
  • E-mail / senha sem verificação de e-mail

Em algumas situações, o Identity Platform vinculará contas automaticamente quando um usuário fizer login com provedores diferentes usando o mesmo endereço de e-mail. No entanto, isso só pode acontecer quando critérios específicos forem atendidos. Para entender o motivo, considere a seguinte situação: um usuário fez login com o Google usando uma conta @gmail.com. Em seguida, uma pessoa mal-intencionada criou uma conta usando o mesmo endereço @gmail.com, mas no Facebook. Se as duas contas fossem vinculadas automaticamente, o usuário mal-intencionado receberia acesso à conta do usuário.

Os casos a seguir descrevem quando as contas são vinculadas automaticamente e quando geramos um erro que exige ação do usuário ou do desenvolvedor:

  • O usuário fez login com um provedor não confiável e, em seguida, com outro provedor não confiável usando o mesmo e-mail (por exemplo, Facebook e depois GitHub). Isso gera um erro que exige a vinculação da conta.
  • O usuário fez login com um provedor confiável e, em seguida, fez login com um provedor não confiável usando o mesmo e-mail (por exemplo, Google e depois Facebook). Isso gera um erro que exige a vinculação da conta.
  • O usuário fez login com um provedor não confiável e, em seguida, fez login com um provedor confiável usando o mesmo e-mail (por exemplo, Facebook e depois Google). O provedor de confiança substitui o provedor não confiável. Se o usuário tentar fazer login novamente com o Facebook, ocorrerá um erro que requer a vinculação da conta.
  • O usuário fez login com um provedor confiável e, em seguida, fez login com outro provedor confiável usando o mesmo e-mail (por exemplo, Apple e depois Google). Os dois provedores serão vinculados sem erros.

É possível verificar manualmente um e-mail usando o SDK Admin. No entanto, recomendamos que você faça isso apenas se souber que o e-mail realmente pertence ao usuário.