Connecter un client à l'URL d'un serveur ne lui donne pas accès aux données de compte protégées. OAuth permet au client de demander un accès délégué par l'intermédiaire d'un serveur d'autorisation, le service qui émet le jeton.
La spécification d'autorisation MCP définit ce flux pour les transports HTTP. L'autorisation est facultative pour les implémentations MCP. Les serveurs stdio locaux utilisent un mécanisme d'identifiants distinct.
Comment le client trouve-t-il où se connecter ?
Le client lit les métadonnées de ressource protégée du serveur MCP pour découvrir son serveur d'autorisation.
Selon les règles de découverte, un serveur peut fournir cette URL de métadonnées dans un en-tête WWW-Authenticate sur une réponse 401. Les clients prennent aussi en charge la découverte via les chemins de métadonnées well-known.
Le champ authorization_servers des métadonnées identifie les serveurs d'autorisation disponibles. Le client récupère les métadonnées du serveur sélectionné pour trouver ses points d'accès et ses capacités prises en charge.
Comment le client s'identifie-t-il ?
Le client obtient un client ID par un mécanisme d'enregistrement pris en charge par le serveur d'autorisation.
Les règles d'enregistrement MCP privilégient les informations client pré-enregistrées lorsqu'elles existent. Sinon, les clients peuvent utiliser des Client ID Metadata Documents lorsque le serveur annonce leur prise en charge.
Un Client ID Metadata Document est un document JSON situé à une URL HTTPS décrivant le client. L'URL fait office de client ID.
Ces règles rendent obsolète l'enregistrement dynamique de client, qui permet à un client de demander un ID via un point d'enregistrement. La spécification conserve ce mécanisme pour la compatibilité avec les serveurs d'autorisation dépourvus de prise en charge des documents de métadonnées.
Comment le client obtient-il le jeton ?
Le client échange un code d'autorisation contre un jeton d'accès après approbation de la concession par le serveur d'autorisation.
Les règles de protection du code d'autorisation exigent PKCE, qui lie l'échange au client qui l'a initié. Le client crée un vérificateur secret et envoie un challenge dérivé avec sa requête d'autorisation. Il fournit le vérificateur lors de l'échange du code, ce qui empêche un code intercepté d'être utilisé par un autre appelant.
Que contrôlent les scopes et la ressource cible ?
Les scopes décrivent les permissions demandées. La ressource cible identifie le serveur pour lequel le client demande un jeton.
Les règles de sélection des scopes demandent aux clients d'utiliser la valeur scope du challenge lorsqu'elle est fournie. Un client devrait demander l'accès nécessaire à son opération.
Le client inclut le paramètre resource dans les requêtes d'autorisation et de jeton. Il envoie le jeton obtenu dans l'en-tête Authorization des requêtes HTTP protégées. Le serveur destinataire vérifie que le jeton a été émis pour lui.
L'autorisation d'invoquer un outil ne garantit pas qu'une invocation donnée correspond à la tâche de l'utilisateur. L'hôte décide toujours s'il poursuit l'action proposée.
Comment autoriser un client à utiliser Bird ?
Vous ajoutez l'URL MCP hébergée de Bird à un client compatible et terminez la connexion navigateur.
Le handshake documenté de Bird utilise l'enregistrement dynamique de client. Cela décrit le flux de connexion de Bird séparément du mécanisme de document de métadonnées préféré par la spécification.
Sur l'écran de consentement, choisissez les permissions d'espace de travail ou d'organisation à déléguer. La concession est limitée par ce que le client demande, ce que vous approuvez et ce que vous détenez.
Le nom affiché du client est auto-déclaré : vérifiez qu'il correspond au client que vous avez lancé. Vous pouvez révoquer sa concession depuis Connected apps dans votre profil.
Un outil peut rester listé lorsque votre concession ne dispose pas de la permission pour l'invoquer. Un appel whoami réussi confirme l'identité connectée. L'opération demandée nécessite toujours ses propres permissions.
Pour un processus bird mcp local, le serveur réutilise la session stockée du CLI. Le guide de configuration MCP décrit ce chemin distinct.