blocked: 401 "Autenticação obrigatória" em TODOS os endpoints testados (inclusive sem [Authorize]) no ambiente https://layoutparser.duckdns.org

[elson-vinicius-lopes]

Contexto

Sequência de #9/#13, testando o reteste pedido pelo time da LayoutParserApi (que anunciou
fix de timing de deploy da config M2M em 2026-09-08). Testamos agora, pela primeira vez com
o Cypress real, o ambiente "produção"/dev real https://layoutparser.duckdns.org (além do
ambiente local 172.19.176.1:5100, já rastreado em #13).

Testado em 2026-09-10 com o mesmo token M2M válido (client LayoutParserE2EClient, scope
api://f76c2598-4759-48a9-8145-8a967ec7ac96/.default, obtido via Entra client_credentials
— confirmado 200 com access_token válido).

Sintoma

Contra https://layoutparser.duckdns.org:

1. POST /api/TransformationExecution/execute-lowcode com Authorization: Bearer <token>
   → 401, corpo:

   {"statusCode":401,"error":"Unauthorized","message":"Autenticação obrigatória.","correlationId":"<varia por request>"}

2. POST /api/AutoTransformation/generate-for-layout — endpoint que no ambiente local
   (172.19.176.1:5100) responde 404 "Layout não encontrado" sem exigir nenhuma
   autenticação (não deveria ter [Authorize], pelo comportamento observado no ambiente
   local) — também retornou 401, com o mesmo formato "Autenticação obrigatória."
   nesse ambiente.

Por que é diferente de #13

A #13 documenta um 401 sem body/WWW-Authenticate, isolado ao endpoint
execute-lowcode, no ambiente local. Aqui temos um 401 com body estruturado, afetando
inclusive um endpoint que não deveria exigir auth. Escopo/causa provável parecem diferentes
— possivelmente uma camada de autenticação (API Gateway/reverse proxy, ou
TrustedIdentityMiddleware) bloqueando todos os endpoints nesse ambiente específico, e
o token M2M do Entra não sendo aceito por essa camada ali (scheme diferente do esperado, ou
audience/issuer não reconhecido nesse ambiente).

Nota sobre rede

curl direto do WSL contra https://layoutparser.duckdns.org trava no handshake TLS
(connection reset) — o teste real só funcionou via Cypress rodando em Electron/Windows.
Possível particularidade de rede do WSL, não necessariamente do servidor; mencionado aqui
só como contexto de diagnóstico, não como parte do sintoma reportado.

Hipótese (não confirmada, para o time da API investigar)

1. Existe um gateway/proxy ou middleware de auth na frente de todos os endpoints em
   layoutparser.duckdns.org que não existe (ou está configurado diferente) no ambiente
   local.
2. O scheme/audience/issuer que esse gateway espera pode ser diferente do que o M2M do
   Entra (client LayoutParserE2EClient) emite — mesmo token, mesmo client, comportamento
   diferente por ambiente.

Relacionado

• #13 — mesmo token M2M,
  sintoma distinto, ambiente local.
• #9 — origem do bloqueio de
  auth de serviço.
• PRs da API mencionados como contexto pelo próprio time: #218, #221, #295.
• Doc persistente: docs/e2e-fiat-sysmiddle-tcl-xsl.md, seção 13.

Severidade

Bloqueia validar o gate sysmiddle no ambiente que o time da API classifica como o
"servidor real" de dev — não confirmado se é bug ou config de ambiente pendente, mas sem
isso não há como confirmar cStat=100 no ambiente correto.

[elson-vinicius-lopes]

Resposta completa da API postada em #13 (comment acima). Resumo para este issue especificamente: o 401 com corpo JSON {"statusCode":401,"error":"Unauthorized","message":"Autenticação obrigatória.",...} em layoutparser.duckdns.org não vem da API .NET — essa string/envelope não existe em nenhuma branch do LayoutParserApi. É erro serializado pelo Fastify, ou seja, do BFF. Esse domínio resolve para o BFF, e o M2M foi desenhado para o caller que NÃO passa pelo BFF (ADR M2M). Por isso até generate-for-layout (aberto na API) dá 401 lá: o BFF barra antes de repassar. Sugestão: fechar este issue como "ambiente incorreto para validação M2M — passa pelo BFF por design"; a validação de M2M é direto na API (ver checklist no #13).

[elson-vinicius-lopes]

Veredito do time LayoutParserApi sobre o ambiente duckdns

Em resposta ao reteste registrado aqui e em #13, o time LayoutParserApi classificou este
bloqueio como causa raiz distinta da de #13 e não é bug do lado deles:

layoutparser.duckdns.org: não serve pra M2M "em nenhuma hipótese" — esse domínio passa
pelo BFF (Fastify/Entra OIDC) antes de chegar na API .NET. O corpo JSON
{"statusCode":401,"error":"Unauthorized","message":"Autenticação obrigatória."} não
existe em nenhum commit da API — é serialização de erro do Fastify/BFF, não da API .NET.
O BFF valida o token contra seu próprio audience OIDC e rejeita o token M2M (audience da
API) antes da requisição chegar na API — por isso até endpoints sem [Authorize] (como
generate-for-layout) dão 401 lá.

Conclusão sobre duckdns: não é bug, é o BFF fazendo seu trabalho — pedem para fechar a #15
como "ambiente incorreto para M2M — passa pelo BFF por design".

Resposta completa (cobrindo também #13) comentada em
#13.

Não estou fechando esta issue. Sinalizando que, do ponto de vista do time da API, o
veredito é "ambiente incorreto para M2M por design" — fica para o dono do repo/quem tem
autoridade decidir se aceita esse veredito e fecha #15, ou se quer manter aberta por algum
outro motivo (ex.: documentar melhor qual ambiente usar em testes futuros).

[elson-vinicius-lopes]

Fechando — veredito do time LayoutParserApi confirmado

O time LayoutParserApi confirmou: https://layoutparser.duckdns.org não é ambiente correto para chamada M2M direta — por design, esse domínio passa por um BFF (Fastify/Entra OIDC) antes de chegar na API .NET.

Por que o 401 "Autenticação obrigatória" aparece em TODOS os endpoints, inclusive generate-for-layout (sem [Authorize] na API .NET):
o BFF valida o token recebido contra o seu próprio audience OIDC (o audience esperado pelo BFF, não o audience da API .NET/ServiceClient). Nosso token M2M tem audience da API (api://f76c2598-...), então o BFF rejeita antes de repassar a chamada para a API — isso acontece independente de o endpoint de destino exigir ou não [Authorize], porque o bloqueio é na camada do BFF, não na API.

Conclusão: não é bug de auth M2M na API — é uso de ambiente incorreto para esse tipo de chamada. O reteste válido de auth M2M (execute-lowcode) continua sendo feito direto contra a API (local ou clone limpo de master), não contra o domínio duckdns, que é a rota via BFF pensada para usuário humano/browser, não client_credentials.

Fechando conforme confirmado pelo dono do repo. Histórico completo da saga de auth M2M (que passou por #9→#13→#15) permanece na issue #13, que segue aberta aguardando o checklist técnico do clone limpo (ver adendo em docs/comunicacao-layoutparserapi-2026-09-10.md).