OAuth por Usuário em Servidores MCP: Keycloak, n8n e um Bot Telegram através de um Auth Proxy
Este artigo detalha a implementação de OAuth por usuário em servidores MCP, utilizando Keycloak, n8n e um bot Telegram. O autor compartilha as dificuldades encontradas e as soluções arquiteturais adotadas, incluindo o uso de um Auth Proxy para gerenciar a autenticação e autorização.
MundiX News·12 de maio de 2026·10 min de leitura·👁 6 views
OAuth por Usuário em Servidores MCP: Keycloak, n8n e um Bot Telegram através de um Auth Proxy
Este artigo explora a implementação de OAuth por usuário em servidores MCP (Model Context Protocol), integrando Keycloak, n8n e um bot Telegram. O autor compartilha as dificuldades encontradas e as soluções arquiteturais adotadas, oferecendo um guia prático para quem busca integrar OAuth/OIDC em sistemas não projetados para isso, construir agentes de IA multi-tenant ou integrar servidores MCP com um IdP corporativo.
A arquitetura inicial consistia em servidores MCP, um agente de IA e usuários no Telegram. A necessidade de autenticação por usuário, com o agente operando em nome do usuário, levou à adoção de um Auth Proxy. A decisão de usar um serviço separado foi motivada pela necessidade de manter a lógica de autenticação separada da roteamento e pela flexibilidade em caso de mudanças no IdP. O FastMCP, um proxy global, foi utilizado para agregar todos os servidores em um único ponto de entrada.
O Auth Proxy, posicionado antes do Gateway, utiliza o OAuthProxy para se apresentar aos clientes MCP como um servidor OAuth completo, utilizando credenciais pré-registradas com o Keycloak. A autenticação do usuário é feita através do Keycloak, garantindo que as senhas nunca sejam expostas ao Auth Proxy. O artigo detalha as dificuldades encontradas, como erros de escopo e diferenças nos dialetos OAuth entre os clientes, e as soluções implementadas, incluindo um middleware para lidar com as diferenças de implementação. A implementação de um middleware para lidar com as diferenças de implementação, como a falta de suporte a PKCE por alguns clientes, demonstrou ser uma solução flexível e adaptável.
A implementação de autenticação por usuário apresentou desafios adicionais, especialmente com o n8n, onde a autenticação padrão é feita uma vez por workflow. A solução foi a criação de uma API de Autenticação de Usuário (User Auth API), que permite que o bot Telegram inicie sessões, obtenha URLs de login, troque códigos por tokens e gerencie o acesso aos recursos. O Auth Proxy armazena os tokens, e o bot trabalha com session_id, garantindo a segurança e o controle de acesso.
Em resumo, o Auth Proxy atende a três tipos de clientes: Claude Desktop, n8n e o bot Telegram. O Claude Desktop se conecta diretamente, o n8n usa OAuth2 padrão e o bot Telegram utiliza a User Auth API para autenticação por usuário. A criação de uma node customizada para o n8n, utilizando a propriedade usableAsTool, permitiu a integração com agentes de IA. No entanto, a limitação de apenas uma tool por node levou à migração para LangGraph, que oferece mais controle e flexibilidade para cenários complexos, como a gestão de múltiplos instrumentos MCP.
O artigo conclui com uma análise dos resultados, destacando a facilidade de acesso aos servidores MCP, a rapidez do processo de autenticação e a melhoria na precisão dos agentes de IA. As limitações incluem o armazenamento de sessões na memória, a ausência de rate limiting e o uso de PKCE, que é um compromisso de segurança. O autor enfatiza a utilidade do middleware para lidar com as diferenças de implementação e a importância da escolha da plataforma, destacando que o LangGraph oferece mais controle para cenários complexos de autenticação por usuário.
Sem cartão para começar · Planos a partir de R$49/mês
OAuth por Usuário em Servidores MCP: Keycloak, n8n e um Bot Telegram através de um Auth Proxy
Este artigo explora a implementação de OAuth por usuário em servidores MCP (Model Context Protocol), integrando Keycloak, n8n e um bot Telegram. O autor compartilha as dificuldades encontradas e as soluções arquiteturais adotadas, oferecendo um guia prático para quem busca integrar OAuth/OIDC em sistemas não projetados para isso, construir agentes de IA multi-tenant ou integrar servidores MCP com um IdP corporativo.
A arquitetura inicial consistia em servidores MCP, um agente de IA e usuários no Telegram. A necessidade de autenticação por usuário, com o agente operando em nome do usuário, levou à adoção de um Auth Proxy. A decisão de usar um serviço separado foi motivada pela necessidade de manter a lógica de autenticação separada da roteamento e pela flexibilidade em caso de mudanças no IdP. O FastMCP, um proxy global, foi utilizado para agregar todos os servidores em um único ponto de entrada.
O Auth Proxy, posicionado antes do Gateway, utiliza o OAuthProxy para se apresentar aos clientes MCP como um servidor OAuth completo, utilizando credenciais pré-registradas com o Keycloak. A autenticação do usuário é feita através do Keycloak, garantindo que as senhas nunca sejam expostas ao Auth Proxy. O artigo detalha as dificuldades encontradas, como erros de escopo e diferenças nos dialetos OAuth entre os clientes, e as soluções implementadas, incluindo um middleware para lidar com as diferenças de implementação. A implementação de um middleware para lidar com as diferenças de implementação, como a falta de suporte a PKCE por alguns clientes, demonstrou ser uma solução flexível e adaptável.
A implementação de autenticação por usuário apresentou desafios adicionais, especialmente com o n8n, onde a autenticação padrão é feita uma vez por workflow. A solução foi a criação de uma API de Autenticação de Usuário (User Auth API), que permite que o bot Telegram inicie sessões, obtenha URLs de login, troque códigos por tokens e gerencie o acesso aos recursos. O Auth Proxy armazena os tokens, e o bot trabalha com session_id, garantindo a segurança e o controle de acesso.
Em resumo, o Auth Proxy atende a três tipos de clientes: Claude Desktop, n8n e o bot Telegram. O Claude Desktop se conecta diretamente, o n8n usa OAuth2 padrão e o bot Telegram utiliza a User Auth API para autenticação por usuário. A criação de uma node customizada para o n8n, utilizando a propriedade usableAsTool, permitiu a integração com agentes de IA. No entanto, a limitação de apenas uma tool por node levou à migração para LangGraph, que oferece mais controle e flexibilidade para cenários complexos, como a gestão de múltiplos instrumentos MCP.
O artigo conclui com uma análise dos resultados, destacando a facilidade de acesso aos servidores MCP, a rapidez do processo de autenticação e a melhoria na precisão dos agentes de IA. As limitações incluem o armazenamento de sessões na memória, a ausência de rate limiting e o uso de PKCE, que é um compromisso de segurança. O autor enfatiza a utilidade do middleware para lidar com as diferenças de implementação e a importância da escolha da plataforma, destacando que o LangGraph oferece mais controle para cenários complexos de autenticação por usuário.
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.