Skip to main content
POST
Obtén tokens de acceso MCP de corta duración usando el código de autorización S256 de un cliente público o su token de actualización actual.

​
Autenticación

Sin autenticación HTTP del cliente. Envía client_id en el cuerpo codificado como URL. Se rechaza cualquier cabecera Authorization, client_secret o client_assertion.

​
Cuerpo de la solicitud

​
Ejemplos de solicitud

Sigue la codificación y la autenticación documentadas para esta ruta. El formato envolvente y las reglas de idempotencia de la API de acciones solo se aplican a las invocaciones de acciones.

​
Respuesta

Un token de acceso Bearer opaco, su tiempo de validez restante en segundos, los ámbitos concedidos y un token de actualización cuando el cliente haya registrado refresh_token. expires_in es como máximo 900 y puede ser menor cerca de la caducidad de la concesión.
HTTP 200

​
Cabeceras de respuesta

​
Notas de la operación

  • Los parámetros escalares reconocidos deben proporcionarse una sola vez como cadenas no vacías, sin caracteres de control ASCII ni DEL. Los campos repetidos de consulta o formulario se decodifican como arrays y se rechazan al leerse como escalares.
  • Usa datos de formulario codificados como URL, por ejemplo curl —data-urlencode por campo. Un cuerpo de token JSON se rechaza con invalid_request.
  • El destinatario resource es obligatorio para ambos tipos de concesión y debe coincidir exactamente con la URL MCP del entorno que emitió el código o el token de actualización.
  • El canje del código de autorización requiere el client_id original, el redirect_uri exacto y un code_verifier S256 coincidente. Los códigos caducan tras 2 minutos y son de un solo uso.
  • El endpoint de tokens rechaza todas las cabeceras Authorization proporcionadas, incluidas Basic y Bearer, así como cualquier campo client_secret o client_assertion en el cuerpo.
  • Los tokens de acceso duran como máximo 15 minutos. Si refresh_token está registrado, la conexión y la familia de tokens de actualización caducan 30 días después de la aprobación del usuario; la rotación no amplía ese plazo.
  • La devolución de refresh_token depende de los tipos de concesión registrados. No depende de incluir offline_access en la solicitud de autorización. El scope devuelto añade offline_access siempre que se devuelve un token de actualización.
  • Para renovar, envía grant_type=refresh_token con client_id, el refresh_token actual, resource y, opcionalmente, un scope más restringido. Sustituye de forma atómica el token de actualización almacenado por el nuevo valor.
  • Reutilizar un código de autorización consumido o un token de actualización rotado revoca toda la conexión, incluidos todos sus tokens de acceso. No canjees simultáneamente el mismo código o token de actualización.
  • Las solicitudes de renovación nunca añaden permisos. Con un scope explícito solo se conservan los permisos de producto e identidad solicitados; offline_access no conserva los permisos de producto omitidos.
  • Los tokens están vinculados al usuario que concede el acceso, al cliente, a la audiencia del recurso, a la propiedad actual del equipo y al acceso de pago activo. Una concesión revocada o un cambio de propiedad requiere volver a conectar.
  • El límite público de tokens es de 60 solicitudes por minuto y por IP de cliente, compartido entre los workers. Los cuerpos codificados como URL están limitados a 32 KiB.
  • Los errores de OAuth devuelven error y error_description. Los errores del analizador del cuerpo pueden devolverse antes con el formato de error del analizador de integración.
  • openid y email son permisos de identidad, distintos de los permisos del producto, y solo se aceptan cuando se anuncian. email requiere openid. Durante la autorización inicial, una solicitud que solo contiene permisos de identidad usa los permisos predeterminados del producto mostrados en la pantalla de consentimiento.
  • El client_id devuelto por el registro dinámico o la URL HTTPS pública exacta del documento de metadatos del cliente.
  • Cuando se concede openid, el intercambio del código de autorización también devuelve un id_token firmado con RS256. Valida su firma, emisor, audiencia, caducidad y nonce si se proporcionó. Los permisos de identidad concedidos aparecen en scope de la respuesta; la renovación no emite un id_token nuevo.
  • Si OpenID Connect deja de estar disponible, renovar sin scope conserva los permisos del producto y elimina los de identidad. Solicitar explícitamente permisos de identidad no disponibles devuelve invalid_scope.
  • Si la cuenta fue eliminada o desactivada, el endpoint de tokens devuelve invalid_grant con HTTP 400.

​
Errores