Conectar um cliente a uma URL de servidor não dá acesso a dados protegidos da conta. OAuth permite que o cliente solicite acesso delegado por meio de um servidor de autorização, o serviço que emite o token.
A especificação de autorização MCP define esse fluxo para transportes HTTP. A autorização é opcional para implementações MCP. Servidores stdio locais usam um esquema de credenciais separado.
Como o cliente descobre onde fazer login?
O cliente lê os metadados de recurso protegido do servidor MCP para descobrir seu servidor de autorização.
Pelas regras de descoberta, um servidor pode fornecer essa URL de metadados em um header WWW-Authenticate em uma resposta 401. Clientes também suportam descoberta por meio de caminhos de metadados well-known.
O campo authorization_servers dos metadados identifica os servidores de autorização disponíveis. O cliente recupera os metadados do servidor selecionado para encontrar seus endpoints e capacidades suportadas.
Como o cliente se identifica?
O cliente obtém um client ID por meio de um mecanismo de registro suportado pelo servidor de autorização.
As regras de registro MCP preferem informações de cliente pré-registradas existentes quando disponíveis. Caso contrário, clientes podem usar Client ID Metadata Documents quando o servidor anuncia suporte.
Um Client ID Metadata Document é um documento JSON em uma URL HTTPS que descreve o cliente. A URL funciona como seu client ID.
Essas regras descontinuam o registro dinâmico de cliente, que permite a um cliente solicitar um ID por meio de um endpoint de registro. A especificação mantém o mecanismo para compatibilidade com servidores de autorização que não suportam documentos de metadados.
Como o cliente obtém o token?
O cliente troca um código de autorização por um access token depois que o servidor de autorização aprova a concessão.
As regras de proteção do código de autorização exigem PKCE, que vincula a troca ao cliente que a iniciou. O cliente cria um verificador secreto e envia um desafio derivado com sua solicitação de autorização. Ele fornece o verificador ao resgatar o código, ajudando a impedir que um código interceptado seja usado por outro chamador.
O que escopos e o recurso de destino controlam?
Escopos descrevem as permissões solicitadas. O recurso de destino identifica o servidor para o qual o cliente solicita um token.
As regras de seleção de escopo orientam os clientes a usar o valor scope do desafio quando fornecido. Um cliente deve solicitar o acesso que sua operação precisa.
O cliente inclui o parâmetro resource nas solicitações de autorização e de token. Ele envia o token resultante no header Authorization em solicitações HTTP protegidas. O servidor receptor verifica se o token foi emitido para ele.
Permissão para invocar uma ferramenta não garante que uma invocação específica corresponda à tarefa do usuário. O host ainda decide se prossegue com a ação proposta.
Como autorizo um cliente a usar Bird?
Você adiciona a URL MCP hospedada de Bird a um cliente compatível e completa o login no navegador.
O handshake documentado de Bird usa registro dinâmico de cliente. Isso descreve o fluxo de conexão de Bird separadamente do mecanismo preferido de documento de metadados da especificação.
Na tela de consentimento, escolha as permissões do espaço de trabalho ou da organização a delegar. A concessão é limitada pelo que o cliente solicita, pelo que você aprova e pelo que você possui.
O nome exibido do cliente é autodeclarado, então confirme que corresponde ao cliente que você iniciou. Você pode revogar a concessão em Connected apps no seu perfil.
Uma ferramenta pode continuar listada quando sua concessão não tem permissão para invocá-la. Uma chamada whoami bem-sucedida confirma a identidade autenticada. A operação solicitada ainda precisa de suas próprias permissões.
Para um processo bird mcp local, o servidor reutiliza o login armazenado do CLI. O guia de configuração MCP descreve esse caminho separado.