Utilizadores da Identity Platform em projetos

O objeto user da Identity Platform representa uma conta de utilizador que se inscreveu numa app no seu projeto Google Cloud. Normalmente, as apps têm muitos utilizadores registados e todas as apps num Google Cloud projeto partilham uma base de dados de utilizadores.

As instâncias de utilizadores são independentes das instâncias da Identity Platform, pelo que pode ter várias referências a diferentes utilizadores no mesmo contexto e continuar a chamar qualquer um dos respetivos métodos.

Propriedades do utilizador

Os utilizadores da Identity Platform têm um conjunto fixo de propriedades básicas (um ID único, um endereço de email principal, um nome e um URL de foto) armazenadas na base de dados de utilizadores do projeto, que podem ser atualizadas pelo utilizador (iOS, Android e Web). Não pode adicionar outras propriedades diretamente ao objeto do utilizador. Em alternativa, pode armazenar as propriedades adicionais noutros serviços de armazenamento, como o Google Cloud Firestore.

Quando um utilizador se inscreve na sua app pela primeira vez, os dados do perfil do utilizador são preenchidos com as informações disponíveis:

  • Se o utilizador se inscreveu com um endereço de email e uma palavra-passe, apenas a propriedade do endereço de email principal é preenchida
  • Se o utilizador se inscreveu com um fornecedor de identidade federada, como o Google ou o Facebook, as informações da conta disponibilizadas pelo fornecedor são usadas para preencher o perfil do utilizador
  • Se o utilizador se inscreveu com o seu sistema de autenticação personalizado, tem de adicionar explicitamente as informações que quer ao perfil do utilizador

Depois de criar uma conta de utilizador, pode recarregar as informações do utilizador para incorporar quaisquer alterações que o utilizador possa ter feito noutro dispositivo.

Fornecedores de início de sessão

Pode permitir que os utilizadores iniciem sessão nas suas apps através de vários métodos: endereço de email e palavra-passe, fornecedores de identidade federados e o seu sistema de autenticação personalizado. Pode associar mais do que um método de início de sessão a um utilizador: por exemplo, um utilizador pode iniciar sessão na mesma conta através de um endereço de email e uma palavra-passe ou através do Início de sessão com o Google.

As instâncias de utilizadores acompanham todos os fornecedores associados ao utilizador. Isto permite-lhe atualizar as propriedades de um perfil vazio com as informações fornecidas por um fornecedor. Consulte o artigo Gerir utilizadores (iOS, Android e Web).

O utilizador atual

Quando um utilizador se inscreve ou inicia sessão, torna-se o utilizador atual da instância de autenticação. A instância mantém o estado do utilizador, para que a atualização da página (num navegador) ou o reinício da aplicação não percam as informações do utilizador.

Quando o utilizador termina sessão, a instância de autenticação deixa de manter uma referência ao objeto do utilizador e deixa de persistir o respetivo estado. Não existe nenhum utilizador atual. No entanto, a instância do utilizador continua a ser totalmente funcional: se mantiver uma referência à mesma, continua a poder aceder aos dados do utilizador e atualizá-los.

O ciclo de vida do utilizador

A forma recomendada de acompanhar o estado atual da instância de autenticação é através de ouvintes (também denominados "observadores" em JavaScript). Um ouvinte de autenticação recebe uma notificação sempre que algo relevante acontece ao objeto de autenticação. Consulte o artigo Gestão de utilizadores (iOS, Android e Web).

Um ouvinte de autorização é notificado nas seguintes situações:

  • O objeto Auth termina a inicialização e um utilizador já tinha iniciado sessão numa sessão anterior ou foi redirecionado a partir do fluxo de início de sessão de um fornecedor de identidade
  • Um utilizador inicia sessão (o utilizador atual é definido)
  • Um utilizador termina sessão (o utilizador atual torna-se nulo)
  • A chave de acesso do utilizador atual é atualizada. Este caso pode ocorrer nas seguintes condições:
    • O token de acesso expira: esta é uma situação comum. O token de atualização é usado para obter um novo conjunto válido de tokens.
    • O utilizador altera a respetiva palavra-passe: a Identity Platform emite novos tokens de acesso e atualização e torna os tokens antigos expirados. Isto faz com que o token do utilizador expire automaticamente e/ou o utilizador termine sessão em todos os dispositivos, por motivos de segurança.
    • O utilizador volta a autenticar: algumas ações requerem que as credenciais do utilizador tenham sido emitidas recentemente. Essas ações incluem eliminar uma conta, definir um endereço de email principal e alterar uma palavra-passe. Em vez de terminar a sessão do utilizador e, em seguida, iniciar sessão novamente, obtenha novas credenciais do utilizador e transmita-as para o método reauthenticate do objeto user.

Self-service do utilizador

Por predefinição, a Identity Platform permite que os utilizadores se inscrevam e eliminem as respetivas contas sem intervenção administrativa. Em muitas circunstâncias, isto permite que os utilizadores finais descubram a sua aplicação ou serviço e se registem (ou cancelem o registo) com o mínimo de atrito.

No entanto, existem situações em que quer que os utilizadores sejam criados manual ou programaticamente por um administrador, através do SDK de administrador ou da Google Cloud consola. Nestes casos, pode desativar as ações do utilizador na página de definições do Identity Platform, o que impede a criação e a eliminação de contas por um utilizador final. Se usar a multilocação, tem de fazer um pedido HTTP para desativar estas funcionalidades por inquilino.

Se um utilizador final tentar criar ou eliminar uma conta no seu sistema, o serviço Identity Platform devolve um código de erro: auth/admin-restricted-operation para chamadas da API Web ou ERROR_ADMIN_RESTRICTED_OPERATION para Android e iOS. Deve processar o erro de forma adequada no seu front-end pedindo ao utilizador que tome as ações adequadas para o seu serviço.

Símbolos de autorização

Quando faz a autenticação com a Identity Platform, existem três tipos de tokens de autorização que pode encontrar:

Tokens de ID do Identity Platform Criados pela Identity Platform quando um utilizador inicia sessão numa app. Estes tokens são JWTs assinados que identificam de forma segura um utilizador num projeto da Google Cloud. Estes tokens contêm informações básicas do perfil de um utilizador, incluindo a string de ID do utilizador, que é exclusiva do projeto Google Cloud. Uma vez que a integridade dos tokens de ID pode ser validada, pode enviá-los para um servidor de back-end para identificar o utilizador com sessão iniciada atualmente.
Tokens de fornecedor de identidade Criadas por fornecedores de identidade federados, como a Google e o Facebook. Estas chaves podem ter formatos diferentes, mas são frequentemente chaves de acesso de OAuth 2.0. As apps usam estes tokens para verificar se os utilizadores se autenticaram com êxito junto do fornecedor de identidade e, em seguida, convertem-nos em credenciais utilizáveis pelos serviços da Identity Platform.
Tokens personalizados do Identity Platform Criado pelo seu sistema de autenticação personalizado para permitir que os utilizadores iniciem sessão numa app através do seu sistema de autenticação. Os tokens personalizados são JWTs assinados com a chave privada de uma conta de serviço. As apps usam estes tokens de forma semelhante à forma como usam os tokens devolvidos pelos fornecedores de identidade federados.

Endereços de email validados

A Identity Platform considera um email validado se cumprir duas condições:

  1. O utilizador conclui o fluxo de validação da Identity Platform
  2. O email é validado por um fornecedor de identidade fidedigno, ou IdP.

Os IdPs que validam o email uma vez, mas que permitem aos utilizadores alterar os endereços de email sem exigir uma nova validação, não são fidedignos. Os IdPs que são proprietários do domínio ou que requerem sempre validação são considerados fidedignos.

Fornecedores fidedignos:

  • Google (para endereços @gmail.com)
  • Yahoo (para endereços @yahoo.com)
  • Microsoft (para endereços @outlook.com e @hotmail.com)
  • Apple (sempre validado, porque as contas são sempre validadas e autenticadas com autenticação multifator)

Fornecedores não fidedignos:

  • Facebook
  • Twitter
  • GitHub
  • Google, Yahoo e Microsoft para domínios não emitidos por esse fornecedor de identidade
  • Email / palavra-passe sem validação de email

Em algumas situações, a Identity Platform associa automaticamente as contas quando um utilizador inicia sessão com diferentes fornecedores através do mesmo endereço de email. No entanto, isto só pode acontecer quando são cumpridos critérios específicos. Para compreender o motivo, considere a seguinte situação: um utilizador inicia sessão através do Google com uma conta @gmail.com e um ator malicioso cria uma conta com o mesmo endereço @gmail.com, mas inicia sessão através do Facebook. Se estas duas contas fossem associadas automaticamente, o autor malicioso obteria acesso à conta do utilizador.

Os seguintes casos descrevem quando associamos automaticamente as contas e quando apresentamos um erro que requer uma ação do utilizador ou do programador:

  • O utilizador inicia sessão com um fornecedor não fidedigno e, em seguida, inicia sessão com outro fornecedor não fidedigno com o mesmo email (por exemplo, o Facebook seguido do GitHub). Isto gera um erro que requer a associação de contas.
  • O utilizador inicia sessão com um fornecedor fidedigno e, em seguida, inicia sessão com um fornecedor não fidedigno com o mesmo email (por exemplo, Google seguido de Facebook). Isto gera um erro que requer a associação de contas.
  • O utilizador inicia sessão com um fornecedor não fidedigno e, em seguida, inicia sessão com um fornecedor fidedigno com o mesmo email (por exemplo, o Facebook seguido do Google). O fornecedor fidedigno substitui o fornecedor não fidedigno. Se o utilizador tentar iniciar sessão novamente com o Facebook, é apresentado um erro que requer a associação de contas.
  • O utilizador inicia sessão com um fornecedor fidedigno e, em seguida, inicia sessão com um fornecedor fidedigno diferente com o mesmo email (por exemplo, Apple seguido de Google). Ambos os fornecedores são associados sem erros.

Pode definir manualmente um email como validado através do SDK de administrador, mas recomendamos que só o faça se souber que o utilizador é realmente proprietário do email.