Pular para conteúdo

Etapa 06 — Autenticação Google nas views

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-07-06

O setup operacional (envs Firebase, cookies) vive no runbook google-auth. Esta página é o desenho. As telas protegidas incluem o disparo do nuke (etapa 05) e a edição de configurações (etapa 07).

1. Contexto e escopo

As telas server-rendered (/processamentos/**, /admin/**) são operadas por humanos da X-Adm e não podem ficar públicas. Diferente da API (consumida por máquina, Bearer estático), elas precisam de login humano — resolvido com Google/Firebase restrito ao domínio @xadm.com.br.

Dentro do escopo: as duas camadas independentes de auth; o gate das views; a sessão; o CSRF; o comportamento sem envs (dev/test vs prod).

Fora do escopo: a auth da API (/api/**, Bearer estático — decisão 0002); não mexer nela ao trabalhar nas views.

2. Componentes

flowchart TB
    user[Usuário X-Adm] -->|login Google| fb[Firebase]
    fb -->|ID token RS256| login[LoginController]
    login -->|cookie xadm_session<br/>JWT HS256| browser[Browser]
    browser -->|cookie| fetcher[Autenticador de sessão]
    fetcher -->|email @xadm.com.br| regra[Regra de segurança das views]
    regra -->|autenticado| views[Views /processamentos, /admin]
    regra -.->|sem cookie / inválido| nega[302 /login ou 503]

3. Fluxos principais

3.1 Duas camadas independentes

As duas camadas rodam dentro do micronaut-security — não há filtro paralelo. A regra de segurança das views devolve "não é comigo" nos paths whitelisted, e é aí que a auth da API segue mandando sozinha.

  • /api/** → Bearer estático (@Secured("ROLE_API"), micronaut-security). /api/** é whitelisted na regra das views — o login Google não afeta a API.
  • Views → login Google + cookie de sessão JWT HS256 (xadm_session, TTL 8h), restrito a @xadm.com.br. O servidor valida o ID token do Firebase contra o JWKS público do Google (via nimbus-jose-jwt) — não precisa do firebase-admin-sdk.json.

3.2 Login (CSRF double-submit)

  • GET /login → renderiza o Firebase JS SDK + grava cookie CSRF.
  • POST /login/callback (JSON {credential, from, csrfToken}) → valida CSRF + Firebase ID token + domínio; emite xadm_session. Status: 200 {redirect}; 400 csrf/token; 401 token inválido; 403 domínio não permitido; 503 JWKS indisponível.
  • POST /logout → expira xadm_session. Sessão é stateless (sem revogação server-side); o TTL de 8h limita a janela de um token vazado.
  • Os forms POST de view (/admin/nuke-replication, /processamentos/{id}/excluir e /reprocessar) carregam token CSRF (_csrf) derivado da sessão; ausente/ divergente → 403 (só com auth ativo).

3.3 Sem envs AUTH_* — bypass vs fail-closed

"Auth configurado" ≡ os 5 obrigatórios preenchidos (AUTH_FIREBASE_PROJECT_ID, _API_KEY, _AUTH_DOMAIN, _APP_ID, AUTH_SESSION_SECRET) — o predicado tem uma fonte única, consumida pela regra de segurança, pelo tratador de recusa e pelo model das views. Comportamento:

Situação Comportamento
Envs AUTH_* completas gate ativo (views exigem login)
Ausentes e ambiente dev/test bypass (views públicas, WARN no log)
Ausentes e produção fail-closed: views respondem 503, nunca abrem por engano

4. Configuração

Envs AUTH_* → AuthSettings: AUTH_FIREBASE_PROJECT_ID (xadm-6ab81), AUTH_FIREBASE_API_KEY, AUTH_FIREBASE_AUTH_DOMAIN, AUTH_FIREBASE_APP_ID (os quatro são valores públicos, vão no HTML), AUTH_SESSION_SECRET (único segredo, ≥32 chars, openssl rand -hex 32), AUTH_SESSION_TTL_SECONDS (default 28800), AUTH_COOKIE_SECURE (default true), AUTH_XADM_EMAIL_DOMAIN (default xadm.com.br). Reusa o projeto Firebase compartilhado xadm-6ab81. Setup detalhado: google-auth.

5. Decisões

Nº Decisão
0002 Bearer estático para /api/**
0003 Login Firebase Google nas views

6. Riscos

  • Deploy de produção sem as envs AUTH_* → fail-closed (503), não exposição.
  • Vazamento do AUTH_SESSION_SECRET → rotação; secrets no Coolify.
  • Domínio do deploy fora dos Authorized domains do Firebase → popup do Google falha; adicionar no console antes do deploy.