Claude ganha Enterprise Managed Auth para conectar usuários a servidores MCP sem tela de consentimento

A documentação descreve Enterprise Managed Auth do ponto de vista de quem constrói o servidor MCP. O Claude apresenta uma identity assertion ao servidor de autorização e troca por um access token via JWT bearer grant. A assertion pode ser emitida de dois jeitos: pelo provedor de identidade do cliente (para quem entra no Claude por SSO) ou pelo próprio Claude, sob uma issuer URL específica de cada organização. A segunda opção está em beta e não vale para organizações que entram no Claude via Okta.

O trabalho do fornecedor é validação rigorosa. O iss precisa bater como string exata com o issuer registrado para o workspace, antes de buscar qualquer chave. A assinatura aceita ES256 e RS256, e rejeita none e HS256. Cada assertion expira em até um minuto e traz um jti que só pode ser aceito uma vez. Em assertions emitidas pelo Claude, o usuário é localizado pelo e-mail, não pelo sub. A assertion confirma que a pessoa é membro atual da organização, mas não diz que passou por SSO ou MFA e não traz grupos. Como o resumo da notícia alerta, tokens já emitidos seguem válidos até o fim do tempo de vida, mesmo se o usuário sair da organização.

Em 19 de junho de 2026 e em 23 de junho de 2026, o CEVIU noticiou a extensão Enterprise-Managed Authorization do MCP, que chegou como stable. Em 4 de novembro de 2026, na matéria "Claude ganha autenticação gerenciada pela empresa para conectar apps da organização", o foco era o modelo para administradores. Agora a documentação detalha o lado do fornecedor de conector: as duas formas de emitir a assertion, as checagens obrigatórias e os casos de teste antes do lançamento.

Para quem vende um conector ou servidor MCP a clientes corporativos, a leitura é que a ausência da tela de consentimento reduz atrito de adoção, mas transfere responsabilidade de segurança para o seu lado. Isolamento entre workspaces, anti-replay e busca de usuário por e-mail viram requisito de venda. Vale tratar a lista de casos de teste como checklist de produto, e planejar a revogação de acesso, já que os tokens emitidos não caem junto com a remoção do usuário.