O objeto usuário do Firebase representa uma conta de usuário que se registrou em um app no projeto. Normalmente, os apps têm muitos usuários registrados e, em um projeto, todos os apps compartilham um banco de dados de usuários.
As instâncias do usuário são independentes das instâncias do Firebase Authentication. Dessa forma, é possível ter várias referências a diferentes usuários no mesmo contexto e ainda chamar qualquer um dos métodos deles.
Propriedades do usuário
Os usuários do Firebase 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) armazenado no banco de dados de usuários do projeto, que pode ser atualizado pelo usuário (iOS, Android, 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.
- Se o usuário altera a senha: o Firebase emite novos tokens de acesso e de atualização e faz com que os antigos expirem. 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 Firebase 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 manualmente ou de maneira programática por um administrador com o SDK Admin ou o console do Firebase. Nesses casos, é possível desativar as ações dos usuários na página de Configurações do Firebase Authentication, o que impede que os usuários finais criem e excluam contas. Se você estiver usando a multilocação, será necessário fazer uma solicitação HTTP para desativar esses recursos em cada locatário.
Se um usuário final tentar criar ou excluir uma conta no sistema, o
serviço do Firebase vai 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
Quando a autenticação é feita com o Firebase, três tipos de tokens podem ser encontrados:
| Tokens de ID do Firebase | Criado pelo Firebase quando um usuário faz login em um app. Esses tokens são JWTs assinados que identificam com segurança um usuário em um projeto do Firebase. Eles contêm informações básicas do perfil do usuário, incluindo a string de ID dele, exclusiva para o projeto do Firebase. 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 a autenticação dos usuários no provedor de identidade foi concluída. Em seguida, eles os convertem em credenciais que podem ser usadas pelos serviços do Firebase. |
| Tokens personalizados do Firebase | 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
Um e-mail é considerado verificado pelo Firebase quando atende a duas condições:
- O usuário concluiu o fluxo de verificação do Firebase
- 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:
- 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 Firebase vincula contas automaticamente quando um usuário faz 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.