MCP Server avançado
Prepare a política de acesso de um servidor remoto de estoque e teste quatro rejeições locais. Depois, aplique essa política em um ambiente de desenvolvimento com autenticação real e revisão MCP registrada. O laboratório não inclui um authorization server pronto nem verifica assinatura de token no exemplo. A identidade fictícia representa o que o autenticador confiável deve entregar ao executor.
Sua entrega precisa mostrar que uma leitura autorizada funciona e que credencial inválida ou permissão insuficiente falha antes da consulta. A parte de implantação inclui uma matriz de compatibilidade e um plano de rollback verificável. Evite credenciais de produção: use ambiente e catálogo fictícios, com scopes estreitos e evidências que não revelem segredos.
MCPAo terminar esta aula
- Prove o bloqueio antes da consulta com eventos ou contadores.
- A validação criptográfica pertence ao autenticador confiável.
- Rollback precisa ser testado junto da compatibilidade do contrato.
Antes de continuar: Leitura: MCP Server avançado
Execute a política sem confundir dados com credencial
FundamentosSalve autorizacao.cjs e execute o caso nominal. Mude audience, expiração, scopes e tenant um campo por vez, capturando a recusa. Registre em qual condição cada caso falhou. Acrescente um contador à consulta fictícia e confirme que ele permanece zero nas rejeições. Essa contagem demonstra que a defesa está antes do acesso, em vez de filtrar uma resposta depois que os dados proibidos já foram consultados. A aplicação precisa proteger tanto o acesso quanto a apresentação.
Escreva uma interface do autenticador que recebe a requisição e retorna identidade validada ou erro. O executor não deve aceitar o objeto de identidade diretamente do corpo JSON enviado pelo usuário. No desenho, marque esse objeto como produzido por componente confiável. Crie um teste em que o cliente manda tenant lojaB no argumento e a identidade continua ligada a lojaA. O executor deve recusar, pois um campo de entrada não muda o vínculo autenticado. Essa fronteira evita elevação de acesso por parâmetros.
↗ Authorization — MCP 2026-07-28↗ Authorization Security Considerations — MCP 2026-07-28
Configure um fluxo HTTP de desenvolvimento
FundamentosEscolha uma implementação compatível com a revisão MCP que será testada e um provedor OAuth de desenvolvimento. Configure Protected Resource Metadata e os metadados do authorization server conforme a documentação atual. Registre emissor, recurso esperado e scopes sem publicar valores de tokens. Execute a obtenção de acesso com o cliente real e confira que o servidor valida a credencial antes da tool. Se o provedor usar um mecanismo de registro específico, documente-o em vez de presumir suporte a registro dinâmico de tutoriais antigos.
↗ Authorization — MCP 2026-07-28↗ Authorization Security Considerations — MCP 2026-07-28
Teste token ausente, expirado, destinado a outro recurso e sem scope de leitura. Capture status e mensagem segura, além do contador de consulta. Não basta editar o objeto do simulador para afirmar que a autenticação real foi validada. Essas rejeições precisam passar pelo adaptador instalado. Verifique também que logs e traces não contêm o token bruto. Para um serviço downstream, use credencial própria apropriada; confirme que o servidor não encaminha o token MCP indiscriminadamente a outras APIs.
↗ Authorization — MCP 2026-07-28↗ Authorization Security Considerations — MCP 2026-07-28
Revise a implantação e os limites
FundamentosDisponibilize o servidor somente no ambiente de desenvolvimento escolhido e registre transporte, TLS e limites de corpo e duração. Execute pedidos alternados de dois usuários e confira que o contexto de um não aparece no outro. Se usar múltiplas instâncias, repita com requisições distribuídas. Uma variável global de usuário pode passar em testes sequenciais simples e falhar sob concorrência. Identifique onde o contexto vive e como ele é criado por pedido. O código de domínio deve recebê-lo explicitamente.
Crie um contrato v1 e uma alteração incompatível, como renomear quantidade para disponivel. Execute um consumidor v1 contra a saída alterada e mostre a falha de validação. Agora implemente uma estratégia compatível escolhida, como manter v1 durante a transição ou publicar uma ferramenta diferente. Teste rollback mantendo o consumidor antigo. A revisão de protocolo pode continuar2026-07-28 em todos esses casos; o experimento mostra que compatibilidade da tool é outra dimensão da implantação.
Entregue uma matriz com resultados reais
FundamentosMonte linhas para credencial nominal, quatro rejeições e combinações de versões suportadas. Inclua resultado esperado, observado e evidência. Marque explicitamente quais casos foram locais e quais passaram pelo servidor autenticado. A conclusão deve identificar limites conhecidos, como ausência de teste multi-instância ou de um cliente legado. Para aceitar a etapa remota completa, é necessário observar autenticação e autorização no transporte real; o simulador oferece somente prova da política de domínio.
↗ Authorization — MCP 2026-07-28↗ Authorization Security Considerations — MCP 2026-07-28
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
As rejeições locais interrompem antes da consulta porque o executor exige audience, validade, scope e tenant compatíveis. O caso de outro tenant confirma a fronteira de recurso, enquanto o scope insuficiente confirma a fronteira de operação. O objeto de identidade não pode ser controlado pelo chamador no servidor real.
Na integração, o autenticador valida credencial e produz esse contexto. A matriz de evolução demonstra que renomear um campo quebra um consumidor mesmo sem mudar o protocolo. A resolução de rollout deve conservar os contratos suportados e declarar quando o cliente precisa migrar.
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.
Identidade nominal: audience estoque, scope ler, tenant A, exp 200, agora 100. Mude cada campo: exp 50, audience outro, scope vazio, tenant B. Novo contrato renomeia estoque→quantidade. Resolva matriz/compatibilidade.
Conferir raciocínio e critérios de domínio
A identidade nominal pode consultar A; exp 50 e audience outro são rejeitadas antes do executor. Nenhuma é recuperada repetindo com a mesma credencial.
Scope vazio e tenant B também negam acesso. As verificações são independentes; autenticação não autoriza automaticamente a operação/recurso.
Cliente antigo que lê estoque quebra com quantidade. A mudança exige versão/adaptação ou migração; rollback precisa manter contrato compatível, não só trocar nome do deploy.
Evidências para autoavaliação ou revisão por pares
- Validade da identidade: A identidade nominal pode consultar A; exp 50 e audience outro são rejeitadas antes do executor. Nenhuma é recuperada repetindo com a mesma credencial.
- Scope e tenant: Scope vazio e tenant B também negam acesso. As verificações são independentes; autenticação não autoriza automaticamente a operação/recurso.
- Compatibilidade do contrato: Cliente antigo que lê estoque quebra com quantidade. A mudança exige versão/adaptação ou migração; rollback precisa manter contrato compatível, não só trocar nome do deploy.
Um erro frequente
Mudança de nome não quebra consumidores.
Renomear campo pode quebrar consumidores que esperam o nome antigo.
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.