Autorização por consumer

1. Introdução¶

Nesta opção, todos os consumidores (portal do cliente, portal do corretor, superapp, parceiros e fluxos com IA) consomem a mesma API e a mesma base URL, e a diferenciação acontece por regras de autenticação e autorização dentro do próprio backend.

O objetivo é manter uma única superfície de API, reduzindo duplicação e simplificando a operação, mas garantindo que:

Cada consumidor enxergue apenas o que é permitido para ele.
Cada usuário acesse apenas dados que pertencem a ele (ou ao vínculo correto).
Operações sensíveis (financeiro, documentos, contratação) sejam protegidas por regras consistentes.

2. Visão estratégica¶

2.1. O que esta opção resolve¶

Centraliza governança: um ponto único para padrões de segurança, logs, auditoria e métricas.
Reduz multiplicação de APIs: facilita manter contrato e documentação.
Acelera migração: é possível endurecer segurança e segmentação sem criar vários novos componentes.

2.2. O que esta opção não resolve sozinha¶

Se houver falha em qualquer regra de autorização, o impacto tende a ser maior, pois todos os consumidores estão no mesmo sistema.
Diferenças grandes de payload e experiência por canal podem levar a complexidade no código (muitos casos condicionais por canal).

3. Visão de negócio¶

3.1. Benefícios¶

Experiência consistente: regras e retornos tendem a ser uniformes entre portal do cliente, portal do corretor e superapp.
Menor custo de entrada para novos consumidores: um novo parceiro ou novo fluxo pode ser habilitado adicionando permissão e contratos, sem criar um novo backend.
Reuso natural de funcionalidades comuns: contratação imediata e outras features compartilhadas permanecem centralizadas.

3.2. Pontos de atenção para o negócio¶

É necessário definir claramente o que muda por consumidor:

Quais operações cada um pode executar.
Quais dados cada um pode visualizar.
Quais limites e regras adicionais se aplicam (por exemplo, parceiros e IA quase sempre precisam de limites mais rígidos).

A política de permissão precisa ser tratada como regra crítica de produto, e não como detalhe técnico.

4. Fluxo de funcionamento¶

%%{init:{ "theme":"neutral", "fontSize":22, "flowchart":{"curve":"basis","htmlLabels":true,"nodeSpacing":50,"rankSpacing":70} }}%% flowchart TB A["Consumidores cliente corretor superapp parceiro ia"]:::ui_input --> B["API Unica mesma base url para todos"]:::ui_input B --> C["Middleware de autenticacao ler token e cabecalhos"]:::ui_input C --> D{Token valido}:::decision D -- Nao --> E["Negar acesso retornar 401"]:::ui_button D -- Sim --> F["Identificar consumidor e usuario origem canal aplicacao"]:::ui_input F --> G["Resolver permissoes do endpoint por consumidor e perfil"]:::ui_input G --> H{Permissao concedida}:::decision H -- Nao --> I["Negar acesso retornar 403"]:::ui_button H -- Sim --> J["Carregar contexto de negocio vinculos convenio produto"]:::ui_input J --> K{Recurso pertence ao solicitante}:::decision K -- Nao --> I K -- Sim --> L{Tipo de operacao}:::decision L -- Contratacao --> M1["Executar contratacao imediata simular contratar emitir termos"]:::endpoint_post L -- Financeiro --> M2["Executar cobranca e pagamentos pix bolix boletos"]:::endpoint_post L -- Documentos --> M3["Executar documentos e pdf certificados comprovantes"]:::endpoint_post L -- Consultas --> M4["Executar consultas e listagens produtos coberturas dados"]:::endpoint_post M1 --> N["Registrar auditoria e metricas logs por consumidor"]:::ui_input M2 --> N M3 --> N M4 --> N N --> O["Resposta para consumidor payload unico por endpoint"]:::endpoint_get classDef endpoint_get fill:#e0f2fe,stroke:#0284c7,color:#0f172a,stroke-width:1px; classDef endpoint_post fill:#dcfce7,stroke:#16a34a,color:#052e16,stroke-width:1px; classDef endpoint_put fill:#fef9c3,stroke:#a16207,color:#3b2f0b,stroke-width:1px; classDef endpoint_delete fill:#fee2e2,stroke:#ef4444,color:#7f1d1d,stroke-width:1px; classDef ui_input fill:#eef2ff,stroke:#6366f1,color:#111827,stroke-width:1px; classDef ui_button fill:#ede9fe,stroke:#7c3aed,color:#1f2937,stroke-width:1px; classDef decision fill:#fff7ed,stroke:#f59e0b,color:#78350f,stroke-width:1px;

5. Manutenção e longo prazo¶

5.1. Manutenção do código¶

Menos peças para operar: um único backend reduz complexidade de deploy e troubleshooting.
Ponto único de padrões: padrões de erros, logs, auditoria e observabilidade podem ser consolidados.
Risco de complexidade interna: com muitos consumidores, cresce a chance de:
- condicionais por canal;
- variações de payload;
- exceções por parceiro.

Para evitar degradação, esta opção exige disciplina de arquitetura interna:

Políticas de permissão centralizadas (não espalhar regras em controllers).
Padrões de validação de vínculo (ownership) reutilizáveis.
Suítes de testes cobrindo permissão por consumidor e por recurso.

5.2. Escalabilidade¶

Escala horizontal do mesmo backend (aumento de réplicas).
É necessário separar limites por consumidor:
- rate limit por canal/parceiro;
- quotas por parceiro;
- proteções extras para rotas críticas (financeiro, documentos, autenticação).
Observabilidade por consumidor vira obrigatória:
- métricas por consumidor e por rota;
- trilha de auditoria por operação sensível.

6. Adaptação ao legado do PASI¶

O legado atual (documentado no relatório de autenticação deste projeto) mostrou que existem fragilidades de segurança e uma grande superfície pública. Nesta opção, a adaptação tipicamente ocorre por endurecimento progressivo, sem mudar o fato de ser uma API única.

6.1. Caminho de adaptação recomendado¶

Normalizar autenticação
- Padronizar token e regras de validade.
- Eliminar fluxos alternativos que emitam token sem garantia de identidade.
Reduzir superfície pública
- Revisar e remover [AllowAnonymous] de endpoints críticos.
- Manter público apenas o estritamente necessário (por exemplo, webhooks), com validações específicas.
Introduzir segmentação por consumidor
- Identificar consumidor em cada chamada (portal cliente, portal corretor, superapp, parceiro, IA).
- Associar permissões por consumidor e por perfil de usuário.
Introduzir validação de vínculo por recurso
- Garantir que consultas e operações respeitem ownership (por exemplo, cliente só vê o próprio dado; corretor só vê sua carteira; parceiro só vê seu escopo).
Auditoria e rastreabilidade
- Logs e trilha de auditoria para operações sensíveis (pagamentos, documentos, contratação).

6.2. Por que esta opção pode ser boa para transição¶

Permite atacar primeiro o maior risco (segurança e superfície pública) sem reestruturar toda a topologia.
Permite migrar consumidor por consumidor dentro do mesmo backend:
- primeiro superapp (launch),
- depois parceiros,
- depois webhooks,
- e por fim consolidação dos portais.

7. Principais prós e contras¶

7.1. Prós¶

Operação simples: menos serviços e menos pontos de falha.
Reuso máximo: funcionalidades comuns como contratação imediata permanecem centrais.
Governança central: auditoria, logs e métricas unificados.

7.2. Contras¶

Alto impacto de erro: se uma regra de autorização falhar, o risco pode afetar vários consumidores.
Complexidade de produto no código: variações entre canais podem virar código condicional.
Exposição para terceiros: parceiros e IA exigem rigor alto de permissão, limites e auditoria para não “herdar” acesso amplo.

8. Quando esta opção faz sentido¶

Quando a prioridade é melhorar segurança e segmentação rapidamente, com o mínimo de mudança estrutural.
Quando os canais compartilham muitas funcionalidades e diferem mais em permissão do que em fluxo ou payload.
Quando o time quer reduzir risco operacional de múltiplos backends no curto prazo, sem impedir evolução futura para outras opções.