MVP5 — Integração avançada, borda e multi-IdP

Fase 7 do plano AUTH-01 · Código tarefa: AUTH-09
Depende de: MVP1 Modo A concluído (Fases 0–5) · MVP4 parcial aceitável
Status: planejado

Documento público da Fase 7. Especificação detalhada e tarefas P7-xx: plano interno 2026-06-30_autenticacao-unificada-ecosif.md (Parte C, §26).

Objetivo

Fechar lacunas explícitas pós-MVP1 para ambientes enterprise e multi-plataforma:

Posicionamento no roadmap

MVP1–3 (Modo A)     → login externo + JWT ECOSIF + signin local
MVP4                → groups/claims, identity_provider_link, gateway MS (parcial)
Fase 7 / MVP5       → Modos B/C + client_credentials + borda + multi-IdP

Não substitui o Modo A — clientes simples continuam com ECOSIF_API_TOKEN_MODE=ECOSIF_JWT.

Pilares da Fase 7

P7-A — Modos B e C no código

Implementar o que a Parte B do plano AUTH-01 já especifica.

Entregas:

• Starter: SecurityFilterChainFactory escolhe filtro por ECOSIF_API_TOKEN_MODE
• Microsserviços: resolver usuário via oid/sub → identity_provider_link → gr_user
• Angular Modo B: interceptor envia access token MSAL (acquireTokenSilent), não JWT ECOSIF
• Angular Modo C: interceptor envia token GIS
• Docs: gateway_access_token_entra.md, gateway_access_token_google.md ✅ P7-06
• Traefik / API Gateway: exemplos com ECOSIF_GWVAL_ACCESSTOKEN_MS / _GOOG

Gate P7-A: piloto com cliente que exige APIM Entra; E2E login + API com access token validado em gateway e backend.

P7-B — client_credentials nativo (ecosif-auth)

Endpoint OAuth2 para integrações server-to-server sem signin (usuário/senha) e sem depender exclusivamente do Entra do cliente.

Contrato proposto

POST /api/auth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=<api_client_id>
&client_secret=<secret>
&scope=ecosif.api moviments:write   # opcional; escopos por cliente

Resposta 200:

{
  "access_token": "<jwt_ecosif>",
  "token_type": "Bearer",
  "expires_in": 1800,
  "scope": "ecosif.api moviments:write"
}

Modelo de dados (novo)

Regras:

• Secret armazenado com hash (bcrypt ou Argon2) — nunca em texto claro no banco
• JWT ECOSIF emitido com claims de serviço (sub = client_id ou usuário técnico vinculado)
• Rotacionar secret sem downtime (dois secrets ativos por janela)
• Rate limit por client_id (reutilizar P4-04 se existir)
• Logs: client_id, grant_type — sem secret

Relação com Entra client_credentials

Gate P7-B: app servidor obtém JWT via client_credentials; chama moviments sem signin; secret rotacionado com sucesso.

P7-C — API keys e mTLS na borda

Alinhar especificação deploy multiservidor com o modelo de auth.

API keys (camada gateway)

Modo mínimo (MVP5): documentação + template Traefik/AWS + variáveis ECOSIF_GWVAL_API_KEY, ECOSIF_API_KEY_HEADER.

Modo completo: validação no ecosif-auth opcional (ECOSIF_AUTH_API_KEY_ENABLED) para ambientes sem gateway dedicado.

mTLS (camada gateway / load balancer)

Gate P7-C: checklist deploy com API key ou mTLS em ambiente QAS; rota de importação protegida sem expor signin na internet pública.

P7-D — Multi-IdP (Azure + Google no mesmo ambiente)

Hoje: ECOSIF_AUTH_PROVIDER aceita um provedor externo. MVP5 permite ambos na tela de login e no external-login.

Mudança de modelo

Frontend

• Login exibe botão Microsoft e Google quando ambos true
• AppConfig: azureClientId + googleClientId simultâneos
• Mesmo apiTokenMode (Modo A ou B/C) para ambos

Provisionamento

• Mesmo usuário com e-mails iguais em Azure e Google: política configurável
• ECOSIF_AUTH_LINK_PROVIDERS_BY_EMAIL=true → um gr_user, dois identity_provider_link
• false → contas separadas (padrão conservador)

Gate P7-D: homolog com Azure + Google no mesmo .env; mesmo e-mail em ambos IdPs vincula ou não conforme flag.

Variáveis novas (rascunho — env.template)

# --- MVP5 / Fase 7 ---

# Modos B/C (implementação)
ECOSIF_API_TOKEN_MODE=ECOSIF_JWT          # ou AZURE_ENTERPRISE_GATEWAY | GOOGLE_GATEWAY
ECOSIF_GWVAL_ACCESSTOKEN_MS=false
ECOSIF_GWVAL_ACCESSTOKEN_GOOG=false

# client_credentials nativo
ECOSIF_AUTH_CLIENT_CREDENTIALS_ENABLED=false
ECOSIF_AUTH_TOKEN_ENDPOINT=/api/auth/token
ECOSIF_AUTH_CLIENT_CREDENTIALS_DEFAULT_SCOPE=ecosif.api

# Borda
ECOSIF_GWVAL_API_KEY=false
ECOSIF_API_KEY_HEADER=X-ECOSIF-Api-Key
ECOSIF_GWVAL_MTLS=false

# Multi-IdP
ECOSIF_ENABLE_AZURE_AUTH=true
ECOSIF_ENABLE_GOOGLE_AUTH=true
ECOSIF_AUTH_LINK_PROVIDERS_BY_EMAIL=false
# ECOSIF_AUTH_PROVIDER → deprecar em favor das flags; manter compat leitura

Tarefas P7 (programação)

Estimativa total: ~22 dias úteis (paralelizável em 2–3 sprints).

Matriz de cenários (pós-MVP5)

Critérios de aceite MVP5

1. Modo B ou C funcional em QAS com gateway validando token IdP e backend em defense in depth.
2. POST /api/auth/token emite JWT ECOSIF para client_credentials sem usuário/senha gr_user.
3. Runbooks API key e mTLS publicados; pelo menos um cenário validado em QAS.
4. Azure e Google habilitados no mesmo ambiente; external-login roteia por provider.
5. ecosif-automations pode migrar de signin para client_credentials (opcional por cliente).
6. Documentação integradores atualizada; sem regressão Modo A.

Referências

Decisões em aberto

~~Ver questionário de produto (AUTH-09)~~ — registrado em 2026-07-01 (ver abaixo).

Decisões de produto (2026-07-01)

Respostas do stakeholder — base para escopo MVP5.

Release 1 (obrigatório no primeiro MVP5)

M2M server-to-server

Autorização (além de autenticação)

Modelo alvo em camadas (implementação incremental):

1. RBAC atual — role + tenant no gr_user (baseline)
2. Scopes por API/client — claim scope no JWT e em api_client (ex.: moviments:write)
3. Mapping IdP — groups/claims Entra/Google → tenant/role (MVP4)

Ordem sugerida: RBAC (já existe) → scopes em P7-B → mapping MVP4 ativo em paralelo.

Multi-IdP (Release 2)

Fases de entrega MVP5

MVP5.1 (Release 1)  → P7-01…P7-10, P7-16  (~14 d)  Modos B/C + client_credentials + authz scopes
MVP5.2 (Release 2)  → P7-11…P7-15           (~8 d)   API key/mTLS runbooks + multi-IdP + E2E completo