O problema: identidade não para na porta de entrada
As plataformas modernas de IA deixaram de ser um único aplicativo atrás de uma tela de login. Um usuário pode começar em um portal central, abrir um conjunto de dados governado, lançar um notebook onde esses dados residem e invocar um assistente que chama serviços em outro cluster. A experiência parece unificada, mas a identidade cruza fronteiras entre plano de controle e plano de dados a cada etapa.
É aí que o single sign-on (SSO) convencional deixa de ser suficiente. O SSO prova o usuário na porta de entrada, mas as equipes de plataforma que gerenciam dados ou IA federados entre múltiplos clusters ainda precisam de uma forma confiável de carregar esse contexto do usuário para os ambientes de execução distribuídos — sem entregar tokens brutos a cada aplicação, sem enfraquecer a revogação e sem forçar cada cluster a reimplementar a lógica de identidade.
Dois padrões de identidade em conflito
Existem duas maneiras comuns de estruturar identidade em uma plataforma federada. A primeira é a propriedade distribuída de sessão: cada gateway de serviço possui seu próprio fluxo de login, armazenamento de sessão, refresh de token e logout. Isso mantém cada cluster independente, mas significa que o estado de identidade não se move de forma limpa pela plataforma.
A segunda é a propriedade centralizada de sessão. Um gateway de identidade dedicado é dono do login, do estado de sessão, do refresh e do logout. Os gateways regionais permanecem no lugar, mas delegam a validação da sessão ao gateway central e se concentram na aplicação das políticas de acesso.
Na prática, a propriedade distribuída funciona para poucos aplicativos, mas cria problemas estruturais conforme a plataforma cresce: sessões limitadas ao local onde foram criadas, logout local que deixa sessões ativas em outros lugares, refresh de token descoordenado que aumenta a carga no provedor de identidade e contexto de identidade inconsistente entre serviços.
O padrão do gateway central de identidade
O padrão descrito pela NVIDIA combina quatro peças: OpenID Connect (OIDC) padrão, um armazenamento de sessão compartilhado, gateways de plano de dados stateless e uma pequena API de validação de identidade em que os serviços podem confiar. O gateway central é dono da sessão da plataforma; os gateways de plano de dados validam essa sessão por meio de uma API compartilhada e a convertem em contexto de identidade local confiável para as aplicações downstream.
Na prática, isso significa que o usuário faz login uma única vez. O gateway central cuida do fluxo OIDC inicial e armazena a sessão, por exemplo, em Redis. A cada acesso subsequente, a validação acontece por uma chamada lateral leve a um endpoint de informações do usuário — sem redirect e sem novo login.
Resultado medido: 55% menos logins
Na NVIDIA, essa abordagem reduziu em 55% os eventos repetidos de login em plataformas internas de desenvolvimento que abrangem clusters Kubernetes na AWS e na OCI. Mais importante, criou uma base reutilizável para shells de plataforma unificados, logout consistente, menor carga no provedor de identidade upstream e assistentes de IA capazes de agir com identidade delegada do usuário entre planos de dados.
Por que isso importa
Para times de plataforma no Brasil que operam ambientes Kubernetes federados, plataformas de dados multi-nuvem ou pilhas de aplicações de IA com múltiplas ferramentas autenticadas, o padrão oferece um caminho para transformar o SSO de um simples ponto de entrada em uma camada de identidade que acompanha o usuário por toda a plataforma — reduzindo fricção e fechando brechas de segurança ao mesmo tempo.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
