MCP Server avançado
Um servidor que funciona localmente pode falhar quando passa a atender usuários distintos pela rede. A consulta de estoque agora pertence a uma organização, a credencial precisa ser validada em cada pedido e o contrato deve continuar compatível durante uma atualização. Nesta aula, vamos tratar autenticação, autorização, implantação e versionamento como decisões integradas, usando um servidor MCP remoto que expõe somente leitura a um usuário autorizado.
A referência é a revisão MCP 2026-07-28. O fluxo de autorização para HTTP usa papéis OAuth e metadados de descoberta previstos na especificação; stdio tem outra fronteira operacional de credenciais. O código local recebe uma identidade já autenticada fictícia e aplica política de acesso. Ele não valida tokens criptográficos nem implementa OAuth, evitando apresentar uma checagem de campos como se fosse autenticação real.
JavaScriptMCPAo terminar esta aula
- Token válido para um serviço pode ser inválido para outro.
- Scope e propriedade do recurso são controles complementares.
- Revisão do protocolo, versão do servidor e schema da tool evoluem separadamente.
Antes de continuar: Laboratório: MCP Server
Autenticar e autorizar são verificações separadas
FundamentosAutenticação estabelece quem está fazendo o pedido e a validade da credencial. Autorização decide se essa identidade pode realizar a operação sobre o recurso solicitado. Para estoque, um usuário pode possuir estoque:ler na organização lojaA e ainda não ter acesso à lojaB. O scope não substitui a propriedade ou o tenant. A política precisa combinar identidade autenticada, operação, recurso e contexto confiável. Nunca aceite tenant do modelo como a origem da identidade; o servidor deve relacioná-lo aos vínculos que conhece para o chamador.
No modelo OAuth descrito pelo MCP, o servidor protegido é um resource server e o cliente solicita acesso em nome do titular. O servidor de autorização emite tokens, enquanto o servidor MCP verifica se podem ser usados naquele recurso. Audience e resource binding importam: um token destinado a outro serviço não deve ser aceito apenas porque possui uma assinatura válida. Não repasse o token MCP a um serviço downstream como atalho. A integração com outro serviço precisa de credencial e autorização adequadas à sua própria fronteira.
↗ Authorization — MCP 2026-07-28↗ Authorization Security Considerations — MCP 2026-07-28
Descoberta de autorização é contrato, não improviso
FundamentosA especificação atual define descoberta por Protected Resource Metadata e mecanismos de metadados do authorization server. Esses documentos informam como o cliente encontra endpoints e capacidades de autorização. A revisão também distingue mecanismos de registro de cliente e conserva alternativas de compatibilidade. Não presuma que qualquer servidor aceitará um fluxo particular de registro dinâmico porque um tutorial antigo o utiliza. O cliente deve seguir a documentação da revisão e do provedor instalado, mantendo a validação de origem e o cuidado com redirecionamentos.
Em um laboratório, configure um provedor de teste ou uma instalação local apropriada e registre os endpoints sem publicar segredos. Para clientes públicos, mecanismos como PKCE e validação de estado fazem parte do fluxo seguro correspondente; não crie uma tela que apenas recebe um token e o considera confiável. Um token decodificado não é um token validado. O servidor precisa verificar assinatura ou introspecção conforme o tipo, emissor, audience, validade e os requisitos do provedor. Só depois a identidade pode chegar ao executor de domínio.
Implantação precisa preservar fronteiras por pedido
FundamentosEm HTTP, pedidos podem chegar a instâncias diferentes e a revisão atual carrega metadados por requisição. A aplicação não deve guardar permissões em uma variável global do último usuário atendido. Cada chamada precisa de seu contexto autenticado e de seus controles. Configure TLS, limites de corpo, timeout, acesso aos serviços internos e observabilidade. Estado operacional e ledger de efeitos, quando existem, precisam de armazenamento compartilhado adequado à concorrência; escalar instâncias não transforma memória local em persistência distribuída.
No simulador, permitir exige audience do serviço, validade temporal, scope de leitura e tenant correspondente. Os campos foram criados localmente para testar a política depois da autenticação. Esse desenho permite quatro casos claros: credencial para outro serviço, credencial expirada, scope insuficiente e acesso a outra organização. A validação real do token pertence ao adaptador autenticador, que não está implementado aqui. A distinção é essencial porque aceitar um objeto com audience correta de qualquer chamador permitiria falsificar toda a identidade.
function permitir(identidade,tenant,agora) {
if (identidade.audience!=='mcp-estoque') throw new Error('audience incorreta');
if (identidade.exp<=agora) throw new Error('credencial expirada');
if (!identidade.scopes.includes('estoque:ler')) throw new Error('scope insuficiente');
if (identidade.tenant!==tenant) throw new Error('tenant nao autorizado');
return {status:'permitido',tenant};
}
const id={audience:'mcp-estoque',exp:200,scopes:['estoque:ler'],tenant:'lojaA'};
console.log(permitir(id,'lojaA',100));
for (const alterado of [{...id,audience:'outro'},{...id,exp:50},{...id,scopes:[]}]) { try { permitir(alterado,'lojaA',100); } catch(e) { console.log(e.message); } }
try { permitir(id,'lojaB',100); } catch(e) { console.log(e.message); }Versionamento protege consumidores
FundamentosA revisão do protocolo, a versão do software do servidor e a versão do contrato de ferramenta são conceitos diferentes. Atualizar o aplicativo para2.0 não implica usar uma nova revisão MCP. Mudar um campo da saída pode quebrar clientes mesmo que o protocolo permaneça igual. Defina política de evolução: adição opcional, depreciação e mudança incompatível precisam de testes e comunicação apropriados. A descoberta apresenta suporte técnico, mas consumidores ainda precisam validar o schema das ferramentas que usam e tratar sua ausência.
Antes de atualizar, execute uma matriz com cliente atual, cliente anterior suportado, contratos antigos e novos e credenciais com diferentes scopes. Teste rollback e confirme que não reaproveita uma aprovação sobre argumentos alterados. Uma implantação gradual só é segura se versões conviventes compartilham uma semântica compatível de estado e efeitos. O objetivo não é prometer compatibilidade ilimitada; é declarar as combinações suportadas e falhar de maneira reconhecível quando elas não são atendidas. Segurança e evolução precisam permanecer verificáveis em cada requisição.
Exercício aplicado
Um servidor MCP de estoque atende lojaA por HTTP. Uma identidade autorizada pode ler apenas sua organização. Prepare autenticação real em desenvolvimento e uma atualização de contrato com rollback.
- Execute o caso nominal e altere quatro condições de acesso.
- Separe autenticador de executor e impeça identidade vinda do corpo livre.
- Configure o fluxo de autorização e teste credenciais reais inválidas no transporte.
- Execute matriz de contrato antigo/novo e rollback.
Abrir resolução comentada
O simulador permite somente a identidade com audience correta, prazo válido, scope de leitura e tenant lojaA. Cada falha é detectada antes da consulta do recurso. Ao trocar o tenant solicitado, a mesma credencial é recusada, mostrando que scope de leitura não concede acesso a todas as organizações.
Na implantação real, esses campos chegam somente depois da validação do token por biblioteca ou componente apropriado. O laboratório deve guardar evidência do fluxo e de rejeições reais, sem registrar o token bruto. A matriz de versão distingue revisão MCP, software e contrato, tornando uma atualização revisável.
function permitir(identidade,tenant,agora) {
if (identidade.audience!=='mcp-estoque') throw new Error('audience incorreta');
if (identidade.exp<=agora) throw new Error('credencial expirada');
if (!identidade.scopes.includes('estoque:ler')) throw new Error('scope insuficiente');
if (identidade.tenant!==tenant) throw new Error('tenant nao autorizado');
return {status:'permitido',tenant};
}
const id={audience:'mcp-estoque',exp:200,scopes:['estoque:ler'],tenant:'lojaA'};
console.log(permitir(id,'lojaA',100));
for (const alterado of [{...id,audience:'outro'},{...id,exp:50},{...id,scopes:[]}]) { try { permitir(alterado,'lojaA',100); } catch(e) { console.log(e.message); } }
try { permitir(id,'lojaB',100); } catch(e) { console.log(e.message); }Como conferir seu resultado
- Rejeições ocorrem antes da consulta.
- Tokens não aparecem em logs compartilhados.
- Versões suportadas e incompatíveis possuem resultados documentados.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Distinguir autenticação e autorização.
- Interpretar audience/scope/tenant.
Credencial válida tem audience errada e scope só leitura; request pede escrita em outro tenant. Quais controles e rollout?
Conferir raciocínio e critérios de domínio
Validade isolada não basta: audience deve apontar ao serviço esperado.
Scope e tenant são verificações independentes; nenhuma escrita permitida.
Contrato novo precisa matriz cliente antigo/novo, migração e rollback definido.
Evidências para autoavaliação ou revisão por pares
- Identidade: Validade isolada não basta: audience deve apontar ao serviço esperado.
- Escopo: Scope e tenant são verificações independentes; nenhuma escrita permitida.
- Evolução: Contrato novo precisa matriz cliente antigo/novo, migração e rollback definido.
Um erro frequente
Credencial válida autoriza qualquer operação.
Autorizar exige audience, scopes e escopo do recurso compatíveis.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. Decodificar token prova autenticidade?
Não. É necessário validar o token conforme seu tipo e provedor.
Campos legíveis podem ser falsificados sem verificação adequada.
2. Scope de leitura libera todos os tenants?
Não. O vínculo ao recurso precisa ser verificado.
Operação permitida e recurso permitido são condições separadas.
3. Versão do servidor é revisão MCP?
Não. São dimensões distintas.
O schema da tool também possui sua própria compatibilidade.
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Authorization — MCP 2026-07-28
Model Context Protocol • consulta: 2026-10-06
MCPAutorização para transportes HTTP, OAuth, discovery e desafios de escopo.
Limites: Autorização no protocolo HTTP não define o RBAC de cada operação de negócio nem o fluxo stdio.
- Deploy & scale
Model Context Protocol Python SDK • consulta: 2026-10-06
PythonImplantar StreamableHTTP, allowlist Host/Origin, TLS proxy, workers e notificações entre réplicas.
Limites: ASGI, processo, TLS, health checks e infraestrutura permanecem responsabilidade da aplicação.
- Streamable HTTP — MCP 2026-07-28
Model Context Protocol • consulta: 2026-10-06
MCPPOST único por mensagem, respostas JSON ou SSE por requisição, segurança HTTP e compatibilidade.
Limites: Não confundir SSE de resposta atual com transporte HTTP+SSE de versões antigas.
- Base protocol — MCP 2026-07-28
Model Context Protocol • consulta: 2026-10-06
MCPJSON-RPC, schema, versão/capabilities em _meta e JSON Schema2020-12.
Limites: Fonte aberta contém versão por requisição; compatibilidade com revisões antigas exige implementação explícita.
- Transports overview — MCP 2026-07-28
Model Context Protocol • consulta: 2026-10-06
MCPJSON-RPC, stdio e Streamable HTTP; regras para transportes customizados.
Limites: HTTP+SSE legado não deve ser ensinado como o transporte remoto atual; streaming é opção do binding.
- Authorization Security Considerations — MCP 2026-07-28
Model Context Protocol • consulta: 2026-10-06
MCPSegurançaProteção de tokens, validação de origem/servidor e segurança do fluxo de autorização.
Limites: Autenticação de transportes não neutraliza prompt injection e não substitui autorização por ferramenta.