Conectar un cliente a la URL de un servidor no le da acceso a los datos protegidos de la cuenta. OAuth permite al cliente solicitar acceso delegado a través de un servidor de autorización, el servicio que emite el token.
La especificación de autorización de MCP define este flujo para transportes HTTP. La autorización es opcional para implementaciones MCP. Los servidores stdio locales usan un esquema de credenciales separado.
¿Cómo encuentra el cliente dónde iniciar sesión?
El cliente lee los metadatos de recurso protegido del servidor MCP para descubrir su servidor de autorización.
Según las reglas de descubrimiento, un servidor puede proporcionar esa URL de metadatos en un encabezado WWW-Authenticate en una respuesta 401. Los clientes también admiten el descubrimiento mediante rutas de metadatos well-known.
El campo authorization_servers de los metadatos identifica los servidores de autorización disponibles. El cliente obtiene los metadatos del servidor seleccionado para encontrar sus endpoints y capacidades admitidas.
¿Cómo se identifica el cliente?
El cliente obtiene un client ID mediante un mecanismo de registro admitido por el servidor de autorización.
Las reglas de registro de MCP prefieren la información de cliente prerregistrada existente cuando está disponible. De lo contrario, los clientes pueden usar Client ID Metadata Documents cuando el servidor anuncia compatibilidad.
Un Client ID Metadata Document es un documento JSON en una URL HTTPS que describe al cliente. La URL actúa como su client ID.
Esas reglas desaconsejan el registro dinámico de clientes, que permite a un cliente solicitar un ID a través de un endpoint de registro. La especificación conserva el mecanismo para compatibilidad con servidores de autorización que no admiten documentos de metadatos.
¿Cómo obtiene el cliente el token?
El cliente intercambia un código de autorización por un token de acceso después de que el servidor de autorización aprueba la concesión.
Las reglas de protección del código de autorización requieren PKCE, que vincula el intercambio al cliente que lo inició. El cliente crea un verificador secreto y envía un desafío derivado con su solicitud de autorización. Proporciona el verificador al canjear el código, lo que ayuda a evitar que un código interceptado sea usado por otro llamante.
¿Qué controlan los scopes y el recurso de destino?
Los scopes describen los permisos solicitados. El recurso de destino identifica el servidor para el cual el cliente solicita un token.
Las reglas de selección de scope indican a los clientes que usen el valor scope del desafío cuando se proporciona. Un cliente debe solicitar el acceso que su operación necesita.
El cliente incluye el parámetro resource en las solicitudes de autorización y de token. Envía el token resultante en el encabezado Authorization en las solicitudes HTTP protegidas. El servidor receptor verifica que el token fue emitido para él.
El permiso para invocar una herramienta no garantiza que una invocación concreta corresponda a la tarea del usuario. El host aún decide si proceder con la acción propuesta.
¿Cómo autorizo a un cliente para usar Bird?
Añade la URL alojada de MCP de Bird a un cliente compatible y completa su inicio de sesión en el navegador.
El handshake documentado de Bird usa registro dinámico de clientes. Eso describe el flujo de conexión de Bird de forma separada al mecanismo preferido de documentos de metadatos de la especificación.
En la pantalla de consentimiento, elige los permisos del espacio de trabajo o la organización que deseas delegar. La concesión está limitada por lo que el cliente solicita, lo que tú apruebas y lo que tú posees.
El nombre mostrado del cliente es autodeclarado, así que confirma que coincide con el cliente que lanzaste. Puedes revocar su concesión desde Connected apps en tu perfil.
Una herramienta puede seguir listada cuando tu concesión carece de permiso para invocarla. Una llamada whoami exitosa confirma la identidad de la sesión iniciada. La operación solicitada aún necesita sus propios permisos.
Para un proceso bird mcp local, el servidor reutiliza el inicio de sesión almacenado de CLI. La guía de configuración de MCP describe esa ruta separada.