OIDC Session Metadata e Zero Trust: Uma Decisão de Arquitetura

Em ambientes financeiros regulados — PCI-DSS, SOC 2 Type II, BACEN 4.658 no Brasil — a autenticação federada com provedores externos como Google sempre foi uma faca de dois gumes. Você ganha UX e reduz a superfície de gerenciamento de credenciais, mas perde visibilidade sobre o ciclo de vida da sessão do usuário no lado do IdP. Um token JWT válido emitido às 09h00 ainda é aceito às 17h00 mesmo que o usuário tenha trocado a senha às 14h00, que o Google tenha detectado acesso suspeito à conta às 15h00, ou que o dispositivo tenha sido marcado como comprometido às 16h00.

O modelo tradicional de mitigação era simples e brutal: tokens de curta duração (15-30 minutos) com refresh agressivo. Isso funciona, mas tem custo: latência de re-autenticação, fricção em fluxos de longa duração (relatórios, exportações, operações batch iniciadas pelo usuário), e pressão sobre os rate limits do Cognito — que impõe 120 requisições de token por segundo por user pool por padrão, um limite que sistemas de médio porte atingem facilmente em horários de pico.

Metadados de sessão OIDC mudam o vetor de defesa. Em vez de encurtar a vida do token, você enriquece a decisão de autorização com sinais do IdP em tempo real. O token pode ter vida mais longa, mas cada requisição sensível passa por uma avaliação que considera o estado atual da sessão no Google — não apenas o estado no momento da emissão. Isso é, conceitualmente, o que o NIST SP 800-207 chama de 'continuous verification' dentro de um modelo Zero Trust.

Antes de chegar às opções, é preciso nomear as forças que tornam essa decisão não trivial:

Latência vs. Frescor do Sinal. Consultar metadados de sessão do Google a cada requisição adiciona uma chamada de rede externa ao caminho crítico. Em APIs financeiras com SLO de p99 < 300ms, isso é inaceitável sem cache. Mas cache introduz janela de staleness — exatamente o problema que estamos tentando resolver.

Disponibilidade do IdP vs. Continuidade do Serviço. Se o endpoint de metadados do Google estiver indisponível, o que fazemos? Fail-open (aceitar a requisição) ou fail-closed (negar)? Em sistemas financeiros, fail-closed é o padrão regulatório correto, mas isso significa que uma degradação do Google pode derrubar seu serviço.

Granularidade de Política vs. Complexidade Operacional. Quanto mais granular a política de acesso adaptativo — 'este endpoint requer score de risco < 20 E verificação de dispositivo recente' — mais difícil é depurar, auditar e explicar para times de compliance.

Cobertura de Claims vs. Dependência de Vendor. Os metadados que o Google expõe são proprietários. Se amanhã você precisar suportar Microsoft Entra ou Okta como IdP alternativo, sua lógica de política precisa abstrair sobre diferentes schemas de claims. Isso é um risco de lock-in que poucos times de arquitetura modelam explicitamente.

Essas quatro tensões definem o espaço de design. As opções abaixo são respostas diferentes para o mesmo conjunto de forças.

Depois de modelar as quatro opções contra as forças identificadas, a decisão que eu tomaria é uma variante da Opção C com um elemento síncrono cirúrgico: avaliação assíncrona de metadados de sessão para a maioria das requisições, com step-up síncrono obrigatório para operações de alto impacto financeiro.

A lógica é a seguinte: nem todas as requisições têm o mesmo perfil de risco. Uma consulta de saldo ou leitura de extrato tem tolerância a uma janela de staleness de 5 minutos no sinal de risco. Uma transferência acima de R$ 10.000, uma alteração de dados cadastrais ou uma aprovação de crédito não têm. Forçar o mesmo modelo de avaliação para ambas é over-engineering no primeiro caso e under-engineering no segundo.

A implementação concreta usa três componentes AWS em coordenação:

1. DynamoDB como cache de estado de sessão: chave de partição userId#sessionId, TTL de 5 minutos, com atributos riskScore, verificationState, lastMetadataRefresh e stepUpRequired. Capacidade provisionada com auto-scaling: 100 RCU/WCU base, escala até 2.000 em pico. Criptografia com KMS CMK, ponto-a-ponto.

1. Lambda Authorizer com leitura síncrona do DynamoDB: o authorizer lê o estado de sessão cacheado (latência p99 < 5ms com DAX opcional) e toma a decisão de autorização localmente. Não há chamada ao Google no caminho crítico. Se stepUpRequired = true, retorna 401 com WWW-Authenticate: step-up e o cliente inicia o fluxo de re-autenticação.

1. EventBridge Scheduler + Lambda de refresh assíncrono: a cada 4 minutos, um job consulta o endpoint de metadados do Google para sessões ativas e atualiza o DynamoDB. Se o sinal de risco mudar, o atributo stepUpRequired é setado atomicamente com uma condição DynamoDB (ConditionExpression: attribute_not_exists(stepUpRequired) OR stepUpRequired = :false), evitando race conditions.

IAM e Least Privilege no Lambda Authorizer. O authorizer precisa apenas de dynamodb:GetItem na tabela de sessões, com condição aws:ResourceTag/Classification = SessionCache. Nenhuma permissão de escrita. A role do refresh Lambda tem dynamodb:UpdateItem com condição dynamodb:LeadingKeys restrita ao prefixo userId# — impedindo que um bug no código escreva em partições arbitrárias. Ambas as roles usam kms:Decrypt com condição kms:EncryptionContext:TableName = session-state.

Circuit Breaker no Refresh Lambda. A chamada ao endpoint de metadados do Google deve ter timeout de 2 segundos e no máximo 2 retries com backoff exponencial. Se a taxa de erro superar 50% em uma janela de 60 segundos, o circuit breaker abre e o refresh Lambda para de tentar — mas não seta stepUpRequired = true automaticamente. A política correta aqui é conservar o último estado conhecido e emitir um alarme CloudWatch (MetricName: GoogleMetadataUnavailable, threshold > 3 minutos). A decisão de fail-open vs. fail-closed durante indisponibilidade do Google deve ser explícita na política e documentada no ADR — não implícita no código.

Observabilidade do Sinal de Risco. Os metadados do Google incluem campos como credential_age, account_risk_level e device_verified. Esses valores devem ser emitidos como dimensões de métricas customizadas no CloudWatch — não apenas logados. Isso permite criar alarmes como 'percentual de sessões ativas com account_risk_level = HIGH > 5%', que é um sinal de ataque de credential stuffing em andamento. O SLO que eu definiria: riskSignalAge (tempo desde o último refresh bem-sucedido) < 6 minutos para 99% das sessões ativas.

Cognito User Pools e o Problema do Token Opaco. O Cognito não repassa claims customizados do Google automaticamente para o access token. Você precisa de um Lambda trigger Pre Token Generation que leia o estado de sessão do DynamoDB e injete os claims relevantes. Atenção: esse trigger adiciona latência ao fluxo de refresh de token — mantenha-o abaixo de 100ms ou o Cognito vai timeout na chamada.

Uma decisão de arquitetura de identidade não termina na implementação técnica. Em sistemas financeiros regulados, a rastreabilidade de cada decisão de autorização é tão importante quanto a decisão em si. Cada chamada ao Lambda Authorizer deve emitir um evento estruturado para o CloudWatch Logs com: userId, sessionId, decision (allow/deny/step-up), riskScore no momento da decisão, signalAge em segundos, e o requestId do API Gateway. Esse log é a evidência de auditoria para demonstrar ao regulador que o sistema estava operando com verificação contínua.

No contexto do AWS Well-Architected, essa arquitetura toca diretamente o pilar de Segurança — especificamente os princípios de 'apply security at all layers' e 'enable traceability'. O uso de KMS CMK com rotation anual, IAM conditions granulares, e CloudTrail habilitado para todas as operações DynamoDB e KMS fecha o loop de auditoria.

O caminho para Zero Trust maduro a partir daqui tem dois passos naturais. O primeiro é adicionar sinais de contexto de dispositivo — não apenas o que o Google sabe sobre a conta, mas o que você sabe sobre o dispositivo: fingerprint, geolocalização, padrão de comportamento. Isso pode ser implementado via Amazon Fraud Detector ou via um modelo customizado no SageMaker alimentado pelos logs de auditoria. O segundo é mover a política de autorização para um motor externo — Open Policy Agent (OPA) rodando no EKS, ou AWS Verified Permissions com Cedar — desacoplando a lógica de política do código do authorizer e permitindo que o time de compliance edite políticas sem deploy de código.

Essa evolução deve estar no roadmap, mas não no MVP. A armadilha clássica é tentar construir o sistema Zero Trust completo na primeira iteração e não entregar nada.