O objeto de usuário do Firebase representa uma conta de usuário que se inscreveu em um aplicativo no seu projeto. Os aplicativos geralmente têm muitos usuários registrados e cada aplicativo em um projeto compartilha um banco de dados de usuários.
As instâncias de usuário são independentes das instâncias do Firebase Authentication, portanto, você pode ter diversas referências a diferentes usuários no mesmo contexto e ainda assim chamar qualquer um de seus métodos.
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 da foto) armazenados no banco de dados de usuários do projeto, que podem ser atualizados pelo usuário ( iOS , Android , web ). Você não pode adicionar outras propriedades diretamente ao objeto de usuário; em vez disso, você pode armazenar as propriedades adicionais em qualquer outro serviço de armazenamento, como o Google Cloud Firestore.
Na primeira vez que um usuário se inscreve no seu aplicativo, os dados do perfil do usuário são preenchidos com as informações disponíveis:
- Se o usuário se inscreveu com um endereço de e-mail e senha, apenas a propriedade do endereço de e-mail principal será preenchida
- Se o usuário se inscreveu em um provedor de identidade federado, como Google ou Facebook, as informações da conta disponibilizadas pelo provedor serão usadas para preencher o perfil do usuário
- Se o usuário se inscreveu em seu sistema de autenticação personalizado, você deverá adicionar explicitamente as informações desejadas ao perfil do usuário
Depois que uma conta de usuário for criada, você poderá recarregar as informações do usuário para incorporar quaisquer alterações que o usuário possa ter feito em outro dispositivo.
Provedores de login
Você pode fazer login de usuários em seus aplicativos usando vários métodos: endereço de e-mail e senha, provedores de identidade federados e seu sistema de autenticação personalizado. Você pode associar mais de um método de login a um usuário: por exemplo, um usuário pode fazer login na mesma conta usando um endereço de e-mail e uma senha ou usando o Login do Google.
As instâncias de usuário rastreiam todos os provedores vinculados ao usuário. Isso permite atualizar as propriedades do perfil vazio usando as informações fornecidas por um provedor. Consulte Gerenciando usuários ( iOS , Android , web ).
O usuário atual
Quando um usuário se inscreve ou entra, esse usuário se torna o usuário atual da instância Auth. A instância persiste no estado do usuário, para que atualizar a página (em um navegador) ou reiniciar o aplicativo não perca as informações do usuário.
Quando o usuário sai, a instância Auth para de manter uma referência ao objeto de usuário e não persiste mais em seu estado; não há usuário atual. No entanto, a instância do usuário continua totalmente 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 maneira recomendada de rastrear o estado atual da instância Auth é usando ouvintes (também chamados de "observadores" em JavaScript). Um ouvinte Auth é notificado sempre que algo relevante acontece ao objeto Auth. Consulte Gerenciando usuários ( iOS , Android , web ).
Um ouvinte Auth é notificado nas seguintes situações:
- O objeto Auth termina a inicialização e um usuário já estava conectado em uma sessão anterior ou foi redirecionado do fluxo de entrada 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. Este caso pode acontecer 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 usuário altera sua senha: o Firebase emite novos tokens de acesso e atualização e torna os tokens antigos expirados. Isso expira automaticamente o token do usuário e/ou desconecta o usuário em todos os dispositivos, por motivos de segurança.
- O usuário autentica novamente: algumas ações exigem que as credenciais do usuário sejam emitidas recentemente; tais ações incluem a exclusão de uma conta, a definição de um endereço de e-mail principal e a alteração de uma senha. Em vez de desconectar o usuário e, em seguida, conectar o usuário novamente, obtenha novas credenciais do usuário e passe-as para o método reautenticar do objeto de usuário.
Autoatendimento do usuário
Por padrão, o Firebase permite que os usuários se inscrevam e excluam suas 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 não) com o mínimo de atrito.
No entanto, há situações em que você deseja que os usuários sejam criados manual ou programaticamente por um administrador, usando o Admin SDK ou o Firebase console. Nesses casos, você pode desativar as ações do usuário na página Configurações de autenticação do Firebase , o que impede a criação e exclusão de contas pelos usuários finais. Se você estiver usando multilocação, precisará fazer uma solicitação HTTP para desabilitar esses recursos por locatário.
Se um usuário final tentar criar ou excluir uma conta no seu sistema, o serviço Firebase 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. Você deve lidar com o erro em seu front-end, pedindo ao usuário que execute as ações apropriadas para o seu serviço.
Tokens de autenticação
Ao realizar a autenticação com o Firebase, você pode encontrar três tipos de tokens de autenticação:
| Tokens de identificação do Firebase | Criado pelo Firebase quando um usuário faz login em um aplicativo. Esses tokens são JWTs assinados que identificam com segurança um usuário em um projeto do Firebase. Esses tokens contêm informações básicas de perfil de um usuário, incluindo a string de ID do usuário, que é exclusiva do projeto do Firebase. Como a integridade dos tokens de ID pode ser verificada , você pode enviá-los a um servidor back-end para identificar o usuário conectado no momento. |
| Tokens do provedor de identidade | Criado por provedores de identidade federados, como Google e Facebook. Esses tokens podem ter formatos diferentes, mas geralmente são tokens de acesso OAuth 2.0. Os aplicativos usam esses tokens para verificar se os usuários foram autenticados com êxito no provedor de identidade e, em seguida, convertê-los em credenciais utilizáveis pelos serviços do Firebase. |
| Tokens personalizados do Firebase | Criado pelo seu sistema de autenticação personalizado para permitir que os usuários façam login em um aplicativo usando seu sistema de autenticação. Tokens personalizados são JWTs assinados usando a chave privada de uma conta de serviço . Os aplicativos usam esses tokens da mesma forma que usam os tokens retornados de provedores de identidade federados. |
Endereços de e-mail verificados
O Firebase considera um e-mail verificado se atender a duas condições:
- O usuário conclui o fluxo de verificação do Firebase
- O e-mail é verificado por um provedor de identidade confiável, ou IdP, abreviadamente.
Os IdPs que verificam o e-mail uma vez, mas depois permitem que os usuários alterem os endereços de e-mail sem exigir nova verificação, não são confiáveis. Os IdPs que possuem o domínio ou sempre exigem verificação são considerados confiáveis.
Provedores confiáveis:
- 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 sempre verificadas e autenticadas por vários fatores)
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 em provedores diferentes usando o mesmo endereço de e-mail. No entanto, isso só pode acontecer quando critérios específicos são atendidos. Para entender o porquê, considere a seguinte situação: um usuário faz login usando o Google com uma conta @gmail.com e um agente mal-intencionado cria uma conta usando o mesmo endereço @gmail.com, mas fazendo login via Facebook. Se essas duas contas fossem vinculadas automaticamente, o agente mal-intencionado obteria acesso à conta do usuário.
Os casos a seguir descrevem quando vinculamos contas automaticamente e quando geramos um erro que exige ação do usuário ou do desenvolvedor:
- O usuário faz login em um provedor não confiável e, em seguida, faz login em outro provedor não confiável com o mesmo email (por exemplo, Facebook seguido de GitHub). Isso gera um erro que exige vinculação de conta.
- O usuário faz login em um provedor confiável e, em seguida, faz login em um provedor não confiável com o mesmo e-mail (por exemplo, Google seguido pelo Facebook). Isso gera um erro que exige vinculação de conta.
- O usuário faz login em um provedor não confiável e, em seguida, faz login em um provedor confiável com o mesmo e-mail (por exemplo, Facebook seguido pelo Google). O provedor confiável substitui o provedor não confiável. Se o usuário tentar fazer login novamente no Facebook, ocorrerá um erro que exige a vinculação da conta.
- O usuário faz login em um provedor confiável e, em seguida, faz login em outro provedor confiável com o mesmo e-mail (por exemplo, Apple seguido pelo Google). Ambos os provedores serão vinculados sem erros.
Você pode definir manualmente um e-mail como verificado usando o Admin SDK, mas recomendamos fazer isso apenas se você souber que o usuário realmente é o proprietário do e-mail.