Autenticar un MCP con Autodesk APS: dos conexiones, dos autorizaciones
En un MCP que consulta Autodesk necesito resolver dos permisos: que el cliente pueda utilizar mis herramientas y que esas herramientas accedan a Autodesk con la cuenta adecuada. Separarlos desde el diseño evita un problema fácil de pasar por alto: autorizar al agente y acabar usando para todas sus consultas la conexión de quien instaló el servidor.
La explicación de Autodesk sobre autenticación MCP plantea esta separación. Voy a recorrer las decisiones de identidad y conexión que exige. El análisis es documental; la implementación y las pruebas reales del cliente se desarrollan en la entrega de autenticación MCP de Issues Manager.
Tabla de contenidos
Una petición al asistente atraviesa dos controles de acceso
La persona escribe «muéstrame mis proyectos». La aplicación de IA identifica una herramienta disponible y, mediante su cliente MCP, solicita al servidor que la ejecute. Antes de consultar Autodesk, ese servidor necesita saber si acepta la petición, a qué identidad local corresponde y qué operaciones tiene permitido realizar. Esta primera frontera protege nuestras herramientas. Aunque la función final solo lea información, no debería estar disponible para cualquiera que conozca su dirección.
Si la petición está autorizada, aparece la segunda frontera: el backend necesita acceder a Autodesk APS. Para ello utiliza una conexión configurada con el contexto apropiado, que puede ser individual o de servicio según el producto. Autodesk decide si ese acceso permite consultar el recurso solicitado. Haber superado el control del servidor MCP no concede automáticamente acceso a los proyectos, del mismo modo que tener permisos en un proyecto no autoriza a entrar en cualquier aplicación que se conecte a Autodesk.
En un ejemplo con dos personas se ve mejor la diferencia. Ana puede utilizar nuestro asistente y tiene acceso al proyecto de viviendas. Luis también puede utilizarlo, pero trabaja en otro proyecto. Ambos tienen permiso para invocar la herramienta de consulta; los tokens APS y los recursos accesibles deben resolverse por separado. Si el servidor conserva una única conexión global porque el primer prototipo solo tenía una cuenta, los resultados de Ana podrían terminar sirviendo a Luis. El error está en la asociación de identidades, aunque ambas llamadas sean técnicamente válidas.
Esta separación también ayuda a explicar los fallos. Una petición puede ser rechazada antes de llegar a APS porque el cliente no está autorizado para el servidor MCP. Otra puede llegar correctamente y encontrar una conexión Autodesk pendiente de renovar. Una tercera puede usar un token válido y carecer de permiso para ese proyecto. Mostrar los tres casos como «vuelve a iniciar sesión» deja al usuario probando lo mismo sin saber qué parte necesita atención.
El esquema mínimo que utilizaría es este:
Cliente de IA → MCP: credencial para utilizar nuestras herramientas.
MCP → Autodesk APS: token de la conexión Autodesk de esa persona.
La aplicación tiene que relacionar ambas identidades. Recibir la primera credencial no proporciona automáticamente la segunda.
La identidad del cliente debe llevar a la conexión Autodesk correcta
Un servidor remoto puede apoyarse en un proveedor de identidad para reconocer al usuario. Cuando recibe una credencial válida para ese servicio, obtiene un identificador estable y lo relaciona con una cuenta de la aplicación. A partir de ahí busca la conexión APS correspondiente. Esa búsqueda debe apoyarse en la identidad acreditada por el servidor, no en un nombre que el modelo de lenguaje haya escrito al preparar los argumentos de la herramienta.
Por ejemplo, una herramienta podría aceptar un identificador de proyecto como filtro. Eso permite especificar qué quiere consultar el usuario; no demuestra que tenga derecho a hacerlo. El servidor necesita comprobar que la identidad autenticada dispone de la conexión y el acceso adecuados. Si acepta un user_id como autoridad para recuperar tokens, bastaría con cambiar un argumento para intentar operar como otra persona. La validación del formato de ese campo no resuelve el problema: un identificador bien escrito también puede corresponder a una cuenta ajena.
Cuando una persona utiliza por primera vez una herramienta que necesita Autodesk, puede faltar esa segunda conexión. El sistema puede ofrecer un enlace de autorización y continuar después de completarla. Ese enlace debe quedar relacionado con la identidad que inició el recorrido y su retorno debe validarse. El usuario no tendría que pegar tokens en el chat para demostrar que ha terminado. La aplicación debe poder comprobarlo por su propio mecanismo y recuperar la conexión correcta al repetir la consulta.
Una identidad SSA compartida representa una decisión diferente. En ese caso, el backend accede con los permisos del servicio, no con los permisos Autodesk de cada persona que conversa. Eso puede encajar en una automatización organizativa, pero exige que nuestra aplicación determine qué parte de esos datos expone a cada usuario. Compartir la credencial de salida no elimina la necesidad de controlar el acceso de entrada. La comparación entre 3LO y SSA ayuda a decidir cuándo tiene sentido cada contexto.
También hace falta considerar la vida de las cuentas. Desactivar a alguien en la aplicación debería impedir que siga invocando sus herramientas aunque su conexión Autodesk todavía exista. Desconectar Autodesk puede dejarle acceso a funciones locales y bloquear solo las que necesitan APS. Mantener estos estados separados permite explicar qué ha ocurrido y aplicar la decisión correspondiente sin borrar conexiones indiscriminadamente ante cualquier error.
Dos tokens distintos pueden convivir con un único login visible
La especificación de autorización MCP trata el acceso del cliente al recurso MCP. La autorización de Autodesk tiene su propio recorrido y sus propios tokens. Mantener ambos destinatarios explícitos ayuda a comprobar dónde debe aceptarse cada credencial.
El servidor necesita validar que la credencial corresponde a ese recurso. La firma, el emisor, la caducidad y la audiencia tienen papeles diferentes: un token auténtico puede haber vencido o estar destinado a otro servicio. Después de aceptarlo, todavía hay que comprobar si permite ejecutar la operación solicitada. La guía de seguridad de MCP desarrolla por qué aceptar y reenviar tokens sin respetar sus destinatarios introduce riesgos. Un token APS no debería convertirse en una llave genérica para nuestro servidor intermedio.
Con un proveedor de identidad externo, la primera utilización puede pedir acceso a la organización y después conexión con Autodesk. Son dos decisiones distintas, aunque la interfaz pueda acompañarlas sin mostrar todos los detalles técnicos. El proveedor acredita a la persona ante nuestra aplicación; Autodesk autoriza lo que la aplicación puede hacer en su contexto. Es una alternativa razonable cuando la organización ya administra sus altas y bajas en un sistema de identidad que quiere mantener como referencia.
Otra posibilidad es un proxy OAuth que ofrezca al cliente la autorización del servidor MCP y gestione internamente la conexión con Autodesk. El usuario puede ver un único acceso a Autodesk mientras el proxy conserva tokens APS y emite credenciales diferentes para el servidor MCP. Esa comodidad no convierte ambos tokens en uno. El intercambio interno entre componentes también necesita protección, porque permite recuperar una credencial con capacidad de acceso a datos de proyecto.
Elegir entre estas opciones depende de cómo se administrarán los usuarios, de qué clientes deben conectarse y de quién mantendrá la infraestructura. Un proxy propio añade responsabilidades: estados de autorización, asociación de cuentas, protección de credenciales y recuperación. Adoptar un proveedor externo tampoco termina el diseño; hay que configurar y verificar el recurso protegido. El número de pantallas que ve el usuario es una consecuencia de esta arquitectura, no una medida suficiente de su calidad.
Qué cambia al pasar de una herramienta local a un servicio remoto
En STDIO, una aplicación inicia un proceso local y utiliza sus flujos de entrada y salida para comunicarse con él. Ese transporte tiene un modelo de acceso diferente al de un servidor HTTP disponible en red. La autorización HTTP de MCP no se aplica de la misma manera; importan el origen del programa, los permisos del proceso y las credenciales que recibe. Que una herramienta esté en tu ordenador no significa que su código sea confiable ni que cualquier dato permanezca allí.
Al ofrecer el servidor por HTTP, el límite del equipo deja de proteger por sí solo la entrada. Hay que decidir qué clientes y usuarios pueden acceder, cómo se verifica cada petición y cómo se limita el trabajo que pueden provocar. Una herramienta de lectura puede generar muchas llamadas a APS o devolver información de varios proyectos. Por eso autenticación, autorización sobre los recursos y límites de uso se complementan, incluso cuando no se permite modificar datos.
También cambia la conservación del estado. Un ejemplo en memoria puede funcionar mientras hay un proceso y una persona probando. Si el servidor se reinicia, se pierde el estado; si hay dos instancias, cada una puede tener información distinta. Las conexiones, renovaciones y operaciones pendientes necesitan un diseño coherente con la forma en que se desplegará el servicio. Añadir otra instancia para mejorar disponibilidad puede descubrir problemas que nunca aparecían al ejecutar el ejemplo en local.
La descarga de metadatos de clientes o proveedores merece atención por el mismo motivo. Una URL recibida durante un flujo no debería permitir acceder libremente a destinos internos ni seguir redirecciones sin control. La especificación y sus medidas de seguridad forman parte de la implementación, no son un complemento opcional para después de ponerla en producción. El objetivo práctico es que el mecanismo de descubrimiento no se convierta en una vía para explorar la red del servidor.
Para comprobar la separación, un ensayo útil intentaría usar un token destinado a otro recurso, acceder con una cuenta distinta y consultar un proyecto no autorizado. También tendría que observar qué ocurre si APS deja de responder durante una renovación. Son situaciones diferentes y deberían producir resultados distinguibles. Un mensaje comprensible y una denegación correcta aportan más evidencia sobre el aislamiento que repetir muchas veces la consulta que ya funciona.
Qué reutilizar de los ejemplos y qué sigue pendiente en nuestro proyecto
El repositorio oficial aps-mcp-auth-examples permite estudiar varios patrones de autenticación manteniendo herramientas comunes. Esa decisión facilita comparar el recorrido de acceso: cambia la forma de obtener o resolver la identidad, mientras la herramienta sigue necesitando un token para consultar datos. Para aprender, esta separación permite localizar el comportamiento que pertenece al proveedor de acceso y el que corresponde a la función de negocio.
El README también explica simplificaciones del ejemplo: estado en memoria, caché de tokens limitada, recuperación incompleta ante fallos de renovación y aspectos de seguridad pendientes. Las consultas de datos tienen además límites de paginación y concurrencia. Reutilizarlo requiere leer esas condiciones junto con el código. Una herramienta puede devolver información correcta en una demostración y seguir necesitando cambios para varias personas, reinicios o un volumen de proyectos mayor.
En una adaptación, la revisión empezaría por persistencia y custodia de credenciales, asociación de identidades y coordinación de renovaciones. Después vendrían las comprobaciones de cada recurso, la revocación y el comportamiento ante errores. No hace falta desarrollar toda una plataforma antes de una primera prueba, pero sí tener claro qué partes se han simplificado para que el ejemplo sea comprensible. Así se puede aprender de él sin atribuirle garantías que sus propios autores no ofrecen.
En la versión del login de Issues Manager, el catálogo MCP todavía estaba vacío: esa etiqueta sirve para estudiar la conexión web con Autodesk. La serie incorpora después el cliente MCP autenticado y prueba que desconectar Autodesk también corta sus consultas.
El diseño se puede contrastar con una prueba muy concreta: conectar una cuenta, consultar un recurso y desconectar esa cuenta. Si el cliente MCP sigue obteniendo datos después, la relación entre las dos autorizaciones todavía necesita trabajo. Es una comprobación más útil que dar por terminado el acceso al ver un token válido.
Respuestas