[BUG] Login com conta pessoal Microsoft trava em loop — API não resolve identidade do tenant "consumers"

[elson-vinicius-lopes]

Esperado

Usuário autentica via OAuth Microsoft com conta pessoal e acessa /workspace normalmente,
com /api/workspaces/me resolvendo o workspace vinculado à identidade autenticada.

Observado

Após login OK com conta pessoal Microsoft (não enterprise/corporativa), a aplicação entra em
loop de login em produção (https://layoutparser.duckdns.org/workspace). A chamada
/api/workspaces/me retorna 401 com corpo {"error":"Identidade não resolvida."}.

Reprodução

1. Login com conta pessoal Microsoft (tenant "consumers", GUID padrão
   9188040d-6c67-4c5b-b112-36a304b66dad).
2. Cookie de sessão do BFF é emitido corretamente — confirmado que /api/session retorna
   {"authenticated":true,...,"isAdmin":true} para essa conta.
3. Front chama /api/workspaces/me → API .NET responde 401 "Identidade não resolvida." →
   aplicação redireciona de volta para login → loop.

Ambiente

Produção, https://layoutparser.duckdns.org, testado ao vivo via SSH (curl.exe direto no
processo Node e via IIS).

Impacto

Bloqueia totalmente o acesso ao workspace para qualquer usuário que só possua conta pessoal
Microsoft (sem conta enterprise/corporativa). Usuários enterprise não são afetados.

Causa raiz (investigação já concluída)

Front (LayoutParserReact) e BFF (server/) estão corretos:

• O BFF emite e valida o cookie de sessão corretamente para a conta pessoal.
• O BFF encaminha a identidade para a API via headers confiáveis
  (x-iis-user, x-layoutparser-identity-provider, x-layoutparser-identity-subject,
  x-layoutparser-identity-tenant).
• A mensagem de erro "Identidade não resolvida." não existe neste repositório
  (confirmado: string ausente em server/src) — ela é emitida pela API .NET
  (LayoutParserApi).
• Conclusão: a API .NET não resolve/provisiona identidades do tenant "consumers" (contas
  pessoais Microsoft) em /api/workspaces/me.

Correção esperada

100% no repositório LayoutParserApi — este bug é uma dependência cross-repo explícita
e não é resolvido por nenhum agente deste repositório (LayoutParserReact). A API precisa
provisionar/resolver identidade também para o tenant "consumers", ou documentar
explicitamente que contas pessoais não são suportadas (decisão de produto pendente).

Evidência técnica (sem dado sensível)

• Endpoint afetado: GET /api/workspaces/me
• Resposta: 401 {"error":"Identidade não resolvida."}
• Headers confiáveis enviados pelo BFF: x-iis-user, x-layoutparser-identity-provider,
  x-layoutparser-identity-subject, x-layoutparser-identity-tenant
• Tenant GUID observado: 9188040d-6c67-4c5b-b112-36a304b66dad (tenant "consumers" padrão
  Microsoft para contas pessoais)
• /api/session local confirma sessão válida (authenticated: true, isAdmin: true)

[elson-vinicius-lopes]

Investigação — 401 "Identidade não resolvida" em /api/workspaces/me

Rastreei o caminho completo: TrustedIdentityMiddleware → IdentityWorkspaceService. ResolveOrCreateUserAsync → SqlIdentityWorkspaceStore (tabelas tbLpUser/
tbLpExternalIdentity, no IdentityDatabase, nunca no SQL compartilhado).

Respostas diretas às duas perguntas

1. Existe allowlist de tenant? Não. Conferido o código inteiro do caminho — não
há nenhuma checagem de tenant/TenantOrIssuer em lugar nenhum. O SQL que resolve/cria o
usuário é genérico:

INSERT INTO dbo.tbLpExternalIdentity (ExternalIdentityId, UserId, Provider, TenantOrIssuer, Subject, CreatedAt)
VALUES (@ExternalIdentityId, @UserId, @Provider, @TenantOrIssuer, @Subject, SYSUTCDATETIME());

TenantOrIssuer NVARCHAR(256) — sem CHECK, sem FK pra tabela de tenants permitidos,
sem lista em código nem em config. O tenant 9188040d-6c67-4c5b-b112-36a304b66dad
("consumers", contas pessoais) é aceito pelo schema e pela query exatamente como
qualquer outro GUID de tenant corporativo.

2. Precisa provisionar o usuário antes? Não. ResolveOrCreateUserAsync já é
"resolve ou cria" — primeira chamada de qualquer (provider, tenant, subject) cria a
linha em tbLpUser + tbLpExternalIdentity na hora, idempotente (inclusive sob
concorrência — tem tratamento de corrida por UNIQUE constraint). Não existe
pré-cadastro nem passo manual.

Então por que dá 401 especificamente nesse caso?

O 401 "Identidade não resolvida" (WorkspacesController.GetMe, linha 42) dispara sempre
que ICurrentUser.UserId fica null — e isso acontece em qualquer um destes três
casos, não só por tenant:

1. A conexão BFF→API não chegou como loopback. A API só confia nos headers
   (x-iis-user e os x-layoutparser-identity-*) se a conexão for 127.0.0.1/::1
   (TrustIdentityFromLoopbackOnly=true, guarda de segurança deliberada — sem isso
   qualquer host na rede forjaria identidade). Fora de loopback, os headers são
   ignorados por completo, silenciosamente — sem erro, sem log por request.
2. x-layoutparser-identity-provider ou x-layoutparser-identity-subject chegaram
   vazios. Sem os dois, o middleware nem tenta resolver — UserId fica null de
   propósito (não infere nada a partir do x-iis-user legado).
3. Uma exceção no SQL foi engolida pelo fail-closed. IdentityWorkspaceService
   captura qualquer exceção do INSERT/SELECT e devolve UserId = null deliberadamente
   (fail-closed — nunca deixa passar sem filtro), logando só:

   Falha ao resolver identidade externa (provider={Provider}, tenant={Tenant}) — negando UserId (fail-closed).
   

   Esse log existe mas eu não tenho acesso aos logs de produção pra confirmar se foi
   disparado nesse caso.

O que precisamos de vocês pra fechar

1. correlationId de uma chamada que reproduziu o 401 + horário aproximado (UTC) —
   com isso o dono confere no log de produção se a linha "Falha ao resolver identidade
   externa" apareceu (confirma cenário 3) ou não (aponta pra cenário 1 ou 2).
2. Confirmar a topologia deste deployment "LayoutParser Web": o BFF dele está
   co-hospedado com a API (mesma máquina, salto vira loopback) do mesmo jeito que o BFF do
   LayoutParserReact já usado em produção? Se for uma instância/hospedagem nova e
   separada, o cenário 1 (guarda de loopback) é o suspeito nº 1 — e nesse caso o sintoma
   não seria específico de conta pessoal, apenas ainda não foi testado com conta
   corporativa nesse ambiente novo.
3. Se puderem, um teste rápido com conta corporativa no mesmo ambiente/URL que deu
   401 pra conta pessoal — se também der 401, é loopback/topologia (cenário 1), não
   tenant.

Assim que tivermos o correlationId ou a confirmação de topologia, fechamos rápido —
não há nada no código que precise de allowlist de tenant pra editar; se for cenário 1 ou
2, o fix é de configuração/rede, não de lógica de negócio.

[elson-vinicius-lopes]

Atualização de investigação — 2026-09-15

Hipóteses anteriores descartadas após auditoria do próprio código da API:

1. Allowlist de tenant — não existe. O schema/query de tbLpExternalIdentity aceita qualquer TenantOrIssuer (incluindo 9188040d-6c67-4c5b-b112-36a304b66dad, tenant "consumers" de contas pessoais Microsoft) sem CHECK, FK ou lista em código/config.
2. Necessidade de provisionamento prévio de usuário — não existe. ResolveOrCreateUserAsync já cria a linha em tbLpUser/tbLpExternalIdentity na primeira chamada, de forma idempotente (com tratamento de corrida via UNIQUE constraint).

Causa provável atual: o 401 "Identidade não resolvida" em WorkspacesController.GetMe dispara quando ICurrentUser.UserId fica null, o que ocorre em qualquer um destes três cenários — ainda não isolamos qual:

1. Conexão BFF→API não chegou como loopback (TrustIdentityFromLoopbackOnly=true ignora silenciosamente os headers de identidade fora de 127.0.0.1/::1).
2. Headers x-layoutparser-identity-provider/x-layoutparser-identity-subject chegaram vazios.
3. Exceção no SQL de resolução de identidade, engolida pelo fail-closed (IdentityWorkspaceService), com log Falha ao resolver identidade externa... negando UserId (fail-closed).

A config de deploy declarada (LAYOUTPARSER_API_URL=http://127.0.0.1:5000) sugere que a chamada BFF→API deveria ser loopback e portanto correta — mas isso não foi confirmado ao vivo no host de produção nesta sessão (sem acesso SSH credenciado disponível).

CorrelationId de reprodução repassado ao time da API para cruzar com logs de produção: 07e5f113-441f-49c2-ac42-4ee13365738a, 2026-09-15T13:47:20.288Z.

Nenhuma correção de código foi feita. Item permanece Blocked no Project — aguardando (a) confirmação do time da API sobre o que o correlationId mostra nos logs de produção, e (b) confirmação ao vivo de que a conexão BFF→API está de fato chegando como loopback no host de produção.

Próxima ação: time da API (cruzar correlationId com logs) + @lp-devops (confirmar loopback no host quando houver acesso).

[elson-vinicius-lopes]

Causa raiz confirmada — não era tenant, era a VM de infra fora do ar

Investigamos a fundo (log de produção + acesso ao host). A suspeita de restrição por
tenant "consumers" estava errada — não é isso.

O que realmente aconteceu

O erro real por trás de "Identidade não resolvida" era:

Microsoft.Data.SqlClient.SqlException: Login failed for user 'layoutparser_svc'.
Error Number:18456, State:1, Class:14

Não é rejeição de negócio — é falha de conexão com o banco de identidade
(IdentityDatabase, dedicado do projeto, roda numa VM separada da API). A VM que hospeda
esse SQL Server estava desligada (não religou sozinha depois de um reboot do host
físico). Toda tentativa de resolver identidade — de qualquer conta, pessoal ou
corporativa — falhava do mesmo jeito nesse período, porque a API nem conseguia abrir
conexão com o banco.

Confirmamos isso ao vivo: religamos a VM, testamos a autenticação da credencial real
configurada no serviço direto contra o SQL Server (SELECT 1 — sucesso), e confirmamos
que a credencial estava correta o tempo todo. Não há allowlist de tenant, não há
provisionamento manual necessário — como já tínhamos apurado no código. O sintoma
"conta pessoal falha" era só coincidência de qual conta vocês estavam testando quando a
infra caiu, não causa.

Status agora

VM e banco de identidade de volta ao ar, credencial confirmada íntegra.

Pedido

Podem repetir o login com a mesma conta pessoal que deu 401 antes? Esperado agora:
GET /api/workspaces/me responder 200 normalmente.

Follow-up nosso (não bloqueia vocês)

Vamos investigar por que a VM não religou sozinha após o reboot do host — tarefa agendada
do Windows que deveria cobrir isso parece não ter disparado. Isso é item de infra nosso,
não muda nada do lado de vocês.

[elson-vinicius-lopes]

Issue cross-repo criada para rastrear o lado da API: LayoutParser/layoutparser-api#408.

Contém: sintoma, as 2 hipóteses já descartadas pela API (allowlist de tenant,
provisionamento prévio), os 3 cenários que eles levantaram (loopback BFF→API,
headers de identidade vazios, exceção SQL engolida por fail-closed), o
correlationId de reprodução (07e5f113-441f-49c2-ac42-4ee13365738a,
2026-09-15T13:47:20.288Z) e o indício não confirmado ao vivo sobre
LAYOUTPARSER_API_URL=http://127.0.0.1:5000.

Bug permanece Blocked até retorno da API em #408.