SSO: Autenticação e Sessões
Login único com Google e Microsoft, autenticação por e-mail/senha, tokens de sessão e o isolamento que garante que cada usuário só vê o que é seu.
Nesta página
Provedores de login
O browserMate suporta três formas de login, todas via Firebase Authentication, a plataforma de autenticação do Google Cloud, mantida e atualizada diretamente pelo Google:
| Provedor | Descrição |
|---|---|
| Google (SSO) | Login com a conta Google corporativa ou pessoal. Um clique, sem senha adicional. |
| Microsoft (SSO) | Login com a conta Microsoft / Entra ID (Azure AD) da sua organização. |
| E-mail e senha | Cadastro tradicional com verificação de e-mail e recuperação de senha. |
Prefira SSO
Com Google ou Microsoft, não existe senha alguma para gerenciar, porque a autenticação acontece inteiramente no provedor. Além disso, quando a empresa desativa a conta do colaborador no provedor, o acesso ao browserMate é bloqueado automaticamente no próximo login.
Como funciona a autenticação
A senha nunca chega ao servidor do browserMate, em nenhum dos três provedores
O formulário de login chama o SDK do Firebase Authentication direto do navegador do usuário (
signInWithEmailAndPassword, createUserWithEmailAndPassword, sendPasswordResetEmail). A senha viaja só entre o navegador e os servidores do Firebase/Google, nunca passa pelo backend do browserMate. Toda a política de senha, hashing, armazenamento e recuperação de conta é responsabilidade do Firebase, não da plataforma. O único momento em que o backend do browserMate participa do cadastro por e-mail/senha é para disparar o e-mail de verificação, e ali ele recebe apenas o e-mail e o ID do usuário, nunca a senha.
- O usuário se autentica no provedor (Google, Microsoft ou e-mail/senha) diretamente com o Firebase, do lado do navegador.
- O Firebase emite um ID Token JWT com validade de 1 hora, renovado automaticamente enquanto a sessão está ativa.
- O servidor do browserMate valida esse ID Token e estabelece a sessão do usuário, sem nunca ter recebido uma credencial de senha.
- Um token interno de 256 bits (gerado com gerador criptográfico de números aleatórios) identifica o usuário em todas as operações de dados.
Se a mesma pessoa fizer login por SSO e por e-mail/senha com o mesmo endereço, o Firebase vincula as identidades à mesma conta.
Política de senha e proteções do Firebase
Como toda a conta (login, cadastro, e recuperação de senha) é gerenciada pelo Firebase Authentication, as proteções abaixo vêm prontas da plataforma do Google. O browserMate não implementa, nem precisa implementar, nada disso por conta própria:
- Política de senha dinâmica. A tela de cadastro busca, em tempo real, a política de senha configurada no projeto Firebase (comprimento mínimo/máximo, exigência de maiúscula, minúscula, número e símbolo) e mostra um checklist que vai marcando cada requisito enquanto o usuário digita. Se a política mudar do lado do Firebase, a tela de cadastro reflete a mudança automaticamente, sem precisar de deploy.
- Verificação de e-mail obrigatória. Uma conta criada por e-mail/senha só consegue entrar depois de confirmar o e-mail, e o Firebase bloqueia a sessão até lá. Contas via Google/Microsoft já chegam verificadas pelo próprio provedor, então não passam por essa etapa extra.
- Limitação de tentativas. O Firebase detecta e bloqueia temporariamente excesso de tentativas de login com a mesma conta, retornando o erro
too-many-requests. É proteção contra força bruta que não depende de nenhuma lógica adicional do browserMate. - Recuperação de senha sem exposição. O fluxo de "esqueci minha senha" é o
sendPasswordResetEmaildo próprio Firebase: o link de redefinição é gerado e validado inteiramente pelo Firebase; o browserMate nunca vê a senha antiga nem a nova.
Sessões e cookies
- Sessões são mantidas via cookies httpOnly, inacessíveis a JavaScript da página, o que bloqueia roubo de sessão por XSS.
- Cookies usam sameSite: lax, proteção contra CSRF (requisições forjadas a partir de outros sites).
- O identificador do usuário da sessão vem sempre do servidor, nunca de parâmetros enviados pelo browser, o que impede falsificação de identidade em requisições.
Isolamento Multi-tenant
Cada usuário vê apenas os processos e recursos que lhe pertencem ou foram explicitamente compartilhados. Toda operação passa pela verificação de autorização do servidor:
- Toda operação em processo (leitura, edição, execução, exclusão) verifica se o usuário logado tem a permissão necessária.
- Permissões válidas:
execute,edit,delete,api, concedidas individualmente no Compartilhamento. - Um usuário sem permissão recebe
403 Forbidden, e não apenas dados vazios.
Boas práticas
- Uma conta por pessoa. Não compartilhe logins: use o Compartilhamento para dar acesso aos processos. Contas compartilhadas impossibilitam auditoria.
- Use o e-mail corporativo. O compartilhamento por departamento e as funções de administração dependem do domínio do e-mail da empresa.
- Revogue acessos ao desligar colaboradores. Além de desativar a conta no provedor SSO, revogue os compartilhamentos ativos do usuário (veja Compartilhamento).