0030 — Auth social pelo central: um projeto Firebase para o ecossistema¶
Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-04 · Decidido em: 2026-09-04
Contexto¶
O central-backend valida todo ID token social contra um projeto Firebase (o da X-Adm),
conferindo iss/aud contra ele — não há projeto Firebase por cliente (nem no cadastro de
Cliente, nem no schema). Em paralelo, os apps mobile standalone de cliente (On Petro, Sul
Plata, Loga) têm cada um o seu projeto Firebase e não passam pelo central: são um realm de
autenticação à parte.
O estado nunca tinha sido decidido por escrito — era o que o código fazia. Ao ligar um provider novo (Apple) a pergunta apareceu inteira: ligar onde, e o que acontece quando um cliente tem app mobile próprio e app que loga pelo central.
Decisão¶
Todo app que autentica pelo central-backend usa o projeto Firebase CENTRAL da X-Adm. Um projeto
para o ecossistema, no fluxo central.
- App de cliente novo registra um web app no projeto central e aponta o
firebase_optionspara ele — não cria projeto. - Os apps mobile standalone seguem nos seus próprios projetos: realm separado, fora deste fluxo.
- Habilitar um provider social é config única no projeto central e vale para todos os apps
que autenticam pelo central de uma vez. Google e Apple estão habilitados e em produção — o
login pelos dois já roda (provado com troca de ID token por JWT de sessão no
central-backend). A cerimônia de console (Firebase + Apple Developer) é operação, não norma: não vive aqui.
Consequências¶
iss/audidentificam o PROJETO, não o app. Um ID token emitido no contexto de um app do central é criptograficamente válido para qualquer app do central. Logo: autorização por app NUNCA vem do token — vem do grant(cliente, app, subject, role)no central (0029). É o piso "tenancy: o servidor decide" (seguranca §Authn) aplicado à borda social: o token prova quem é, o grant decide onde entra.- Identidades distintas por realm. O mesmo humano com a mesma conta Google tem UID diferente no app mobile do cliente (projeto próprio) e no app que loga pelo central (projeto central). Aceito: são realms diferentes; nenhum fluxo pressupõe o contrário.
- Apple tem duas pegadinhas de identidade (valem para qualquer app do central que ligue o
provider): o nome do usuário só vem no PRIMEIRO login — se não for persistido ali, não volta —,
e o e-mail pode ser um relay
@privaterelay.appleid.comquando o usuário escolhe esconder o e-mail. Portanto: identifique o usuário pelosubject(nunca pelo e-mail) e a tela de aprovação de acesso tolera nome ausente e e-mail de relay. Enviar e-mail ao usuário exige registrar o remetente no serviço de relay da Apple. - Rotação de credencial do provider é ponto único de falha compartilhado: a chave do provider vive no projeto central; revogá-la/rotacioná-la derruba o login social de todos os apps do central até o valor novo entrar.
- Por-cliente fica FORA de escopo (deferido, REGRA Nº 3). Só entra se um cliente exigir
compartilhar identidade entre o mobile (projeto próprio) e o app do central — aí vira feature:
firebase-project-idporCliente+ validação multi-projeto (cache de JWKS por projeto,iss/audpor cliente).
Alternativas descartadas¶
- Projeto Firebase por cliente: multiplica config de console, JWKS e credencial de provider por
tenant, e o
central-backendteria de validar multi-projeto — custo permanente sem demanda real. - Projeto por app: mesma multiplicação, com a agravante de habilitar cada provider N vezes.