OAuth sem toque para MCP

• A extensão Enterprise-Managed Authorization (EMA) foi estabilizada, permitindo que empresas gerenciem centralmente as permissões de servidores MCP e que usuários façam login uma vez para acessar servidores autorizados
• O modelo anterior dependia de aprovações OAuth individuais por usuário e por servidor, o que dificultava onboarding, aplicação de políticas de segurança, trilha de auditoria e separação entre contas de trabalho e pessoais
• A EMA coloca o IdP da organização como autoridade de decisão de acesso, e, quando o administrador define a política uma vez, os usuários herdam as conexões MCP necessárias com suas contas organizacionais existentes
• O ID-JAG emitido durante o SSO é trocado por um token de acesso no servidor de autorização do servidor MCP, então o usuário não é redirecionado para telas de consentimento por servidor
• Okta, Anthropic, Visual Studio Code e Asana, Atlassian, Canva, Figma, Granola, Linear e Supabase estão entre os primeiros a oferecer suporte, e o Slack também está adicionando suporte

---

Estabilização da EMA e objetivo de implantação empresarial

• A extensão Enterprise-Managed Authorization (EMA) passou ao estado stable
• Ao gerenciar conexões com servidores MCP em ambientes corporativos, aprovações repetidas e prompts de consentimento eram apontados como grandes incômodos, e a EMA é uma extensão criada para reduzir esse problema
• Organizações podem controlar centralmente o acesso a servidores MCP por meio de um provedor de identidade (IdP) confiável
• Usuários finais entram com suas contas organizacionais existentes e então se conectam aos servidores MCP autorizados, reduzindo a necessidade de consentimento OAuth por servidor ou de configuração pontual

Limites do modelo de autenticação por usuário

• O modelo padrão de permissões do MCP foi projetado para um escopo centrado no usuário (user-scoped) e para convenções tradicionais de autenticação interativa
• Isso pode servir para cenários de consumo em que cada pessoa decide diretamente a que dados quer acessar, mas não escala bem em implantações corporativas
• Em ambientes empresariais, três problemas se destacam
  • Cada funcionário precisa aprovar cada servidor separadamente, exigindo conexões manuais por serviço durante o onboarding
  • As equipes de segurança passam a depender de acessos aprovados individualmente por cada usuário, sem controle central nem trilha de auditoria
  • Fica difícil impor o uso de contas corporativas, permitindo que usuários conectem contas pessoais a ferramentas de trabalho
• Esse atrito atrasa a adoção do MCP e aumenta a chance de surgirem implementações alternativas frágeis
• Sem um padrão universal para preservar estado de autenticação compartilhado, cada implementador tende a criar sua própria solução, e, mesmo com dados e ferramentas disponíveis, muita coisa pode permanecer desativada por causa do custo de permissões por usuário

Aprovar uma vez e herdar em todos os lugares

• O Enterprise-Managed Authorization transforma o IdP da organização na autoridade de decisão de acesso aos servidores MCP
• O administrador define a política uma vez, e os usuários se autenticam no host MCP com seu ID organizacional existente
• O IdP pode permitir ou negar acesso com base em associação a grupos, funções e regras de acesso condicional
• O fluxo interno funciona assim
  • O cliente obtém do IdP, durante o SSO, um Identity Assertion JWT Authorization Grant (ID-JAG)
  • O cliente envia isso ao servidor de autorização do servidor MCP e o troca por um token de acesso
  • O usuário não passa por telas de consentimento por servidor
• Essa estrutura traz três efeitos principais
  • Quando o administrador ativa um servidor para a organização, os usuários passam a ter acesso automaticamente dentro do escopo de seus grupos e funções existentes
  • As decisões de acesso ficam registradas no console administrativo do IdP, fornecendo um único registro auditável para todos os conectores
  • Ao eliminar a etapa interativa de escolha de conta, fica mais fácil reduzir confusões no fluxo de dados entre contas pessoais e corporativas
• No uso corporativo do MCP, o objetivo é que, quando o usuário fizer login, o cliente se conecte a ferramentas e dados autorizados sem etapas adicionais

Produtos com suporte inicial e ecossistema

• Neste lançamento, três grupos participam da implementação: provedores de identidade, clientes e servidores

• Provedor de identidade

  • A Okta é o primeiro provedor de identidade com suporte
  • Organizações que usam Okta podem provisionar acesso MCP para clientes e servidores compatíveis por meio do Cross App Access (XAA) da Okta

• Clientes

  • A Anthropic implementou EMA na camada MCP compartilhada do Claude
  • Administradores podem aprovar servidores MCP para usuários em Claude, Claude Code e Cowork
  • O Visual Studio Code também adicionou suporte a EMA dentro da IDE

• Servidores

  • Asana, Atlassian, Canva, Figma, Granola, Linear e Supabase oferecem suporte à EMA
  • O Slack e outros servidores também estão adicionando suporte
  • Aaron Parecki, da Okta, afirma que incorporar o protocolo Cross App Access à extensão EMA do MCP transforma a identidade em um plano central de governança, oferecendo controles de conformidade para as equipes de segurança e uma experiência fluida para os usuários
  • Devdatta Akhawe, da Figma, diz que, à medida que a adoção do MCP cresce, o XAA facilita a expansão segura de implantações empresariais de MCP
  • Tom Moor, da Linear, menciona a experiência em que um único login configura automaticamente todos os conectores MCP

Documentação e canais de participação

• Clientes, servidores e plataformas de identidade podem revisar a especificação da extensão e adicionar suporte ao novo padrão em seus produtos
• A página Enterprise-Managed Authorization documenta os requisitos de fluxo para clientes, servidores e servidores de autorização
• No repositório ext-auth e no rascunho da especificação, é possível acompanhar as mudanças mais recentes da EMA e materiais de suporte
• O EMA Interest Group é usado para discussões sobre a extensão, relatos de compatibilidade e melhorias iterativas
• A EMA é um trabalho da comunidade MCP, com contribuições dos autores da SEP-990, mantenedores do repositório ext-auth e provedores de identidade e MCP que testaram as implementações iniciais e ajudaram a avançar a especificação

[GN⁺]

Opiniões no Hacker News

• Antes de cair no debate comum de “MCP morreu e Skills é o futuro”, o ponto em que o MCP realmente tem valor em relação a skills/CLI é separar o fluxo de autenticação para fora da janela de contexto do agente e, em alguns casos, até para fora do harness
  Isso obviamente é importante do ponto de vista de segurança e também torna a experiência muito mais simples para usuários comuns ou grandes empresas ao adotar ferramentas de IA
  Entendo as reclamações sobre inchaço de contexto ou duplicação de chamadas de ferramenta, mas há um valor claro nessa estrutura de tratar autenticação dessa forma
  Um MCP ideal já pode trazer bastante benefício mesmo que seja apenas um gateway de autenticação na frente da API

  • Esta extensão também mostra bem outras vantagens do MCP em relação a skills: controle centralizado, facilidade de uso para funcionários, auditoria/compliance e modelo de distribuição
    No momento, o melhor da distribuição de skills parece ser algo como “copie este arquivo e coloque aqui”, “faça checkout deste repositório e adicione um link simbólico” ou “instale com um comando de barra”
    Por mais simples que isso seja, ainda não é tão fácil quanto esta forma de extensão para distribuir um novo servidor MCP aos funcionários
  • O MCP também permite uma ótima trilha de auditoria
    Por exemplo, dá para autenticar 6 contas do Linear de 6 clientes diferentes e então escolher qual conta usar de forma determinística e auditável, permitindo também uma separação de responsabilidades
  • A verdadeira lição é que MCP vs. skills não é uma dicotomia
    São apenas ferramentas diferentes, e dependendo dos requisitos uma pode ser melhor que a outra — ou não
    É parecido com perguntar o que é melhor, uma faca ou uma serra
  • Além disso, o MCP permite conectar plataformas externas sem ambiente de runtime
    Sempre que esse tema aparece, engenheiros tratam o Claude Code como se fosse o único app de agente de IA que existe, mas há inúmeros casos de uso em vários setores além de programação
    O harness pode estar rodando não na máquina local, mas em um contêiner isolado e restrito na nuvem, onde execução arbitrária de código nunca é permitida
    Mesmo assim, quando o cliente quer conectar ferramentas existentes ao agente, o MCP se encaixa perfeitamente por fornecer conectores com autenticação embutida, enquanto skills não se aplica a esse cenário
  • Estou criando uma plataforma de avaliações de restaurantes com amigos e, depois de algumas tentativas e erros, MCP parece ser o caminho certo
    Usuários comuns não vão procurar um diretório do Claude para colar um arquivo de skill
    “Connections” é fácil de entender, e é mais simples colar um MCP ou encontrá-lo em um marketplace
    Ainda não está claro se será realmente útil dar ao agente acesso a lugares e avaliações

• Meus parabéns a quem construiu isso na Okta, Anthropic, Microsoft, Figma, Linear e outras empresas
  Há algo útil aqui até para os céticos do MCP
  Isso funciona com um novo formato de token chamado ID-JAG, descrito em https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...
  Não é nada específico de MCP, e o ID-JAG pode ser usado em qualquer lugar onde aplicativos que usam o mesmo provedor de SSO precisem compartilhar dados com segurança

  • Como essas empresas pioraram a qualidade do software e da vida, dá até um sentimento cínico de que isso é mesmo algo a ser comemorado

• Estou tentando adicionar autenticação do Microsoft Entra ID ao servidor MCP que estou implementando agora e, sinceramente, parece que virei um idiota
  Pelo cabeçalho WWW-Authenticate, dá para informar ao cliente a URL de metadados do recurso e, com isso, também especificar o Microsoft Entra como servidor de autenticação e o escopo do registro do app
  Mas não dá para especificar o client_id, e a ideia parece ser que cada cliente, ou seja, cada agente, crie o seu por conta própria
  Só que, para iniciar o login pela URL .../authorize do Microsoft Entra, é preciso um client_id conhecido que corresponda ao registro do app no Entra, e não tem como um valor criado arbitrariamente pelo cliente bater com o Entra
  Em teoria daria para oferecer suporte a registro dinâmico de cliente, mas o Microsoft Entra obviamente não oferece isso
  No fim, a única saída que eu vejo é criar meu próprio shim de registro dinâmico de cliente na frente do Microsoft Entra para devolver o mesmo client_id estático para todo mundo
  Fico com a impressão de que devo estar deixando passar algo óbvio, porque não parece certo que esse protocolo funcione em ambiente enterprise sem gambiarra

  • Não parece que você esteja deixando passar algo óbvio
    O Entra ID não oferece suporte a registro dinâmico de cliente, e o estado desse ecossistema ainda não está bom
    Normalmente, o OAuth do MCP é tratado com clientes tradicionais pré-registrados, mas na prática muitos clientes MCP assumem que existe registro dinâmico de cliente e não oferecem uma opção para definir o client_id
    Ainda assim, alguns clientes suportam isso e, já aproveitando o jabá, nossa ferramenta Erato também suporta: https://erato.chat/docs
    Soluções típicas implantadas em ambientes corporativos também costumam centralizar o acesso ao MCP por meio de uma interface web, então dão suporte a isso
    Outra alternativa é usar um gateway MCP: entre o gateway e o serviço, usar OAuth pré-registrado, e entre o gateway e o cliente, permitir registro dinâmico de cliente
  • Nós também tivemos o mesmo problema por causa do client_id e, por motivos de segurança, não queríamos habilitar registro dinâmico de cliente
    No fim, fizemos o app atuar como proxy do fluxo OAuth, injetando um client_id fixo
    Para o cliente MCP, fingimos que há suporte a registro dinâmico de cliente, mas internamente a estrutura usa um client_id separado para o MCP como de costume
    O exemplo está aqui: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
  • Implementei isso ontem mesmo, e a essência é que esta biblioteca executa o servidor MCP: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
    Depois criei uma aplicação broker de autenticação que faz o registro do cliente com OpenID e gera JWTs
    Com isso, passamos a conseguir decidir se uma ferramenta pode ser usada e com quais permissões, com base no departamento do funcionário ou em outros critérios
    No fim das contas, o registro dinâmico de cliente é necessário
  • Recentemente, a FusionAuth documentou uma forma de usar clientes pré-registrados: https://fusionauth.io/docs/extend/examples/controlling-acces...
    Também estão avaliando o CIMD, um irmão mais novo e melhor do DCR, e a discussão está ativa, mas isso ainda não foi disponibilizado: https://github.com/FusionAuth/fusionauth-issues/issues/3230
    Como alternativa ao proxy sugerido, dá para criar um novo client_id do Entra com PKCE habilitado para cada cliente MCP em um portal do desenvolvedor ou algo do tipo, e fazer o usuário configurar esse valor no cliente
    Encontrei o comando de CLI para isso aqui, e imagino que também exista API: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
    A configuração do Claude Code está em https://code.claude.com/docs/en/mcp, e a do ChatGPT em https://developers.openai.com/api/docs/guides/developer-mode
    O registro prévio de clientes pode não ser o ideal para desenvolvedores, mas é aceitável, e a própria especificação o trata como uma abordagem de primeira classe: https://modelcontextprotocol.io/specification/2025-11-25/bas...
    Se os principais usuários forem funcionários internos e eles puderem seguir instruções de configuração para acessar o servidor MCP, isso também funciona
    Mas, se o público-alvo for uma integração pública ampla voltada a não desenvolvedores, isso claramente não é aceitável, e é exatamente aí que está uma das grandes forças e oportunidades do MCP

• Sou uma das pessoas da Anthropic, junto com a Okta e vários parceiros de MCP, que ajudaram a criar isso
  Estou muito animado em ver esse formato ganhar forma no Claude e, agora que a EMA é uma extensão estável na especificação do MCP, quero ampliar a adoção para outros provedores de identidade e clientes também
  Se tiverem feedback, deixem aqui; sempre quero ouvir experiências reais de uso e formas de melhorar

  • Quanto tempo
    Faz um tempo que não acompanho o MCP, mas isso parece se encaixar muito bem para tornar o MCP mais seguro nas organizações e resolver as fraquezas do registro dinâmico de clientes
    Agora clientes e URIs de redirecionamento aprovados podem ser configurados diretamente pelo provedor de identidade e pela organização, então ataques baseados em DCR, como confused deputy ou phishing, podem ser mitigados de forma mais ampla
    Outra grande vantagem é reduzir a lógica de autorização que o servidor MCP precisava implementar quando o provedor de identidade ou a organização não davam suporte a DCR
    A desvantagem é que, para uso por consumidores, ainda parece que o DCR continua sendo necessário
    Talvez isso possa ser resolvido se provedores de OAuth de consumo como GitHub, GitLab e Google passarem a oferecer registro estático de cliente/servidor MCP, se os clientes embutirem um client_id estático e se os usuários fizerem login nesse provedor de identidade e gerenciarem a conexão diretamente por lá
    No geral, XAA/EMA parece muito superior ao DCR em segurança e usabilidade
    As preocupações também parecem bem mais fáceis de resolver do que no DCR e com impacto de segurança menor, porque um atacante não pode registrar o próprio cliente e há menos armadilhas em que desenvolvedores de servidores MCP podem cair
  • É excelente para “apps” comuns, mas para nós é urgente ter uma forma de interagir no estilo agente com menos atrito, sem que o usuário precise configurar o MCP
    Algo como uma sessão temporária ou um armazenamento de tokens fora de banda seria ótimo
    O caso de uso é que, no processo comercial, compradores e vendedores precisam trocar e analisar muitas informações, e essa análise está ficando cada vez mais orientada por agentes
    O problema do MCP é que o atrito da configuração inicial é muito maior do que o usuário simplesmente fazer login por conta própria e buscar as informações necessárias
    O MCP é bom para interações regulares e frequentes, mas tem muitos problemas para sessões rápidas e pontuais
    Se no Claude eu disser “busque documentos em X, Y e Z”, seria ótimo se o Claude acessasse esses sites, e o site retornasse informações básicas de uso e um link de login que o usuário pudesse abrir no navegador
    O ideal seria o usuário se autenticar no navegador, o callback devolver um token único, curto e de uso único, e depois ele ser trocado nas requisições ao site
    Assim daria para autenticar o usuário rapidamente e ainda manter o estado da sessão durante a tarefa
  • Gostaria de saber se há conversa com a equipe do Microsoft Entra, ou seja, Azure AD
    Quero entender se isso é algo para esperar em breve ou se ainda vai demorar bastante
  • Parabéns pelo lançamento
    O principal caso de uso parece ser funcionários de empresas, mas fico curioso se há valor semelhante também para usuários não centralizados, como clientes ou usuários gratuitos premium
    Não estou conseguindo visualizar muito bem, então queria entender o que posso estar deixando passar, e acho que vi uma resposta relacionada aqui: https://news.ycombinator.com/item?id=48594381
  • Só quero confirmar se isso ainda não está realmente utilizável e se está na fase SEP

• Isso é realmente excelente
  Nos últimos meses, tive a sorte de trabalhar com o pessoal de MCP em alguns SEPs e em SDKs experimentais em Go
  Antes eu era cético, do tipo “isso é só uma API” ou “lá vem mais uma abstração”
  O que as pessoas deixam passar é que o “P” de MCP induz a erro
  Quando você cria um app tradicional, precisa construir formulários, UI, tratamento de requisição/resposta, canais bidirecionais, tarefas longas, autenticação etc.
  Com MCP, 80% dessa camada comum já vem resolvida; então MCP é um protocolo, mas na prática está mais perto de um framework de apps
  A autenticação integrada é um reforço enorme, e estou empolgado com as próximas evoluções

• É bem curioso ver trabalho meu aparecendo em público
  Na Atlassian, cuidei da implementação do lado RAS desse fluxo
  Com certeza ainda haverá melhorias iterativas nesse fluxo, como CIMD e melhor suporte a tenancy
  Todas as pessoas da Anthropic, Okta e Atlassian que entregaram isso foram excelentes

• Seria bom ter suporte à web para simplesmente permitir emitir cookies de longa duração
  Como eu queria fazer isso sem um servidor OAuth, hackeei a especificação para passar cookies pelo handshake do OAuth
  É muito frustrante tentarem não permitir esse tipo de coisa
  Basta abrir a página web, e quando o cookie for configurado, fechar e salvar
  Já escrevi até um minibook de 80 páginas sobre MCP, mas ainda assim isso continua me frustrando sem parar

  • Sou um dos mantenedores principais do projeto MCP, e essa abordagem não escala em vários cenários
    Ela traz problemas tanto de usabilidade quanto de segurança, e cookies foram feitos para navegadores
    Servidores e clientes MCP muitas vezes operam em ambientes em que não há garantia de navegador
  • Isso é praticamente pedir para deixarem suas credenciais serem roubadas
    Credenciais de longa duração trazem uma responsabilidade enorme

• Li várias vezes e sem dúvida isso é útil
  Auditoria e controle de acesso podem ser centralizados em um único provedor de identidade, e o provedor de identidade também pode agir como uma API gateway proxy que faz a troca de tokens quando necessário
  Essa é uma abordagem que outros players da área também adotaram
  Pessoalmente, me incomoda um pouco a ideia de o provedor de identidade delegar minhas permissões a um cliente sem que eu perceba isso
  Talvez seja porque estou acostumado demais a fluxos em navegador em que o usuário está presente, e isso parece estar evoluindo cada vez mais para uma centralização de acesso voltada a máquinas
  Em ambientes enterprise, onde a identidade pertence mais à empresa do que ao indivíduo, isso pode ser aceitável
  Mas integrar isso ao lado de identidade do cliente é um desafio totalmente diferente, e provavelmente não será fácil construir esse tipo de confiança entre provedor de identidade, cliente e servidor de autorização de recursos

  • Não existe nenhuma barreira teórica que impeça essa integração de funcionar no mundo do consumidor
    Por exemplo, bastaria criar uma relação de confiança para que, se você estiver logado no GitHub, também entre automaticamente no Sentry
    Ainda há muito trabalho pela frente, mas, como você disse, hoje o caso de uso mais claro é o enterprise
    Administradores não querem que cada funcionário fique clicando por aí e escolhendo credenciais arbitrárias

• No C1, a autenticação do MCP era uma grande dor de cabeça tanto no uso interno de MCP quanto no MCP Gateway dentro do produto, então fico muito feliz em ver isso chegando
  Hoje o C1 lançou suporte para atuar como provedor de identidade EMA e emitir tokens de escopo restrito com vida curta
  Agora quero conectar ao Linear e aos outros MCPs que usamos e escapar dos fluxos repetitivos de OAuth
  O Claude já vinha fazendo algo assim quase como mágica em alguns conectores nativos, pelo menos no Slack, e a experiência é bem boa
  Para ser transparente, sou VPE do C1, e documentamos a abordagem para quem quiser se aprofundar: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

• Não entendo muito bem qual é a vantagem disso em relação ao OAuth comum
  Acho que seria necessário um exemplo comparando os fluxos de autorização

  • No OAuth comum, o usuário final consente individualmente em compartilhar seus dados com cada aplicação
    Isso faz sentido em casos de uso de consumo, ou seja, quando o usuário final é dono dos próprios dados
    Mas, em muitos casos de uso empresariais, quem deve compartilhar os dados e controlar o acesso não é o usuário final, e sim a empresa
    Se eu sou funcionário da Acme, não deveria ser eu a decidir se os dados do Google Drive da Acme podem ser conectados ao Claude ou ao ChatGPT; isso deveria ser decidido pelo departamento de TI
    OAuth gerenciado pela empresa, ou Cross App Access (XAA), traz para dentro do framework OAuth um modelo de compartilhamento controlado centralmente pelo administrador de TI, para que ele funcione com o ecossistema existente
    Além disso, ao transferir a gestão do consentimento de compartilhamento de dados do funcionário para o administrador de TI, também há uma grande vantagem em termos de experiência do usuário
    O funcionário não precisa passar por vários fluxos de OAuth para conectar contas, porque o administrador de TI já deixou os controles de compartilhamento configurados
    Pense em chegar no primeiro dia de trabalho e o Slack já estar conectado ao Zoom, Drive, Calendar etc.
  • A vantagem é que o usuário não precisa controlar nem consentir quais apps estão autorizados a compartilhar suas informações entre si
    Porque a decisão de delegação de acesso é tomada no nível de política do provedor de identidade
    O usuário pode até nunca ficar sabendo quais apps ou serviços foram autorizados a compartilhar suas informações
    Espera, isso é mesmo uma vantagem? ;-)