Transloadit

Autenticación

Auth Keys

Para las solicitudes multipart de creación de Assemblies autenticadas con una Auth Key, incluye un objeto auth dentro del campo de formulario params codificado en JSON. A continuación se muestra el valor mínimo de params para este caso.

{
  "auth": {
    "key": "23c96d084c744219a2ce156772ec3211"
  }
}

El campo key hace referencia a la Auth Key asociada a tu Workspace de Transloadit, que se encuentra en la página Credenciales. El objeto anterior es el objeto de autenticación mínimo para una solicitud de Assembly que usa una Auth Key. Otros endpoints y métodos de autenticación pueden usar formatos de solicitud distintos, como se describe en la documentación de cada endpoint y más adelante.

Las Assemblies que usan /transloadit/import, directamente o a través de un Template, requieren un token Bearer o bien params firmados con una marca de tiempo futura en params.auth.expires. Esto se aplica incluso cuando Signature Authentication del Workspace está deshabilitada. Una Auth Key por sí sola no es suficiente; las solicitudes autenticadas con un token Bearer no necesitan una Signature ni una caducidad independientes.

Signature Authentication

Te recomendamos habilitar Signature Authentication en tu cuenta, especialmente si integras Transloadit desde un entorno que no es de confianza (por ejemplo, desde el navegador con Uppy). Puedes habilitar Signature Authentication desde la Configuración del Workspace.

Con Signature Authentication habilitada, el Auth Secret de tu Workspace (que se encuentra junto a tu Auth Key en la página Credenciales) se usa como clave para un HMAC generado a partir de los bytes exactos del valor params serializado. Ese valor contiene tanto un campo key (que es tu Auth Key, como se ha mencionado antes) como un parámetro expires, que es una marca de tiempo en un futuro cercano usada como fecha de caducidad de la solicitud.

Para crear Assemblies con Transloadit, tu back-end podría calcular una Signature que solo cubra determinados parámetros, usuarios autenticados y un intervalo de tiempo que considere un uso legítimo. Por ejemplo, se negaría a generar una Signature para los usuarios que no hayan iniciado sesión. Aquí podrías usar cualquier lógica de negocio en el servidor para decidir si proporcionas una Signature o no. Transloadit puede exigir una Signature correcta para el contenido de una solicitud a la API cuando esta se autentica con tu Auth Key.

Para exigir Signature Authentication en las solicitudes a la API autenticadas con tu Auth Key:

  1. Ve a la Configuración del Workspace en tu cuenta.
  2. En la sección Configuración de la API, habilita la opción Requerir una Signature correcta.
  3. Pulsa el botón Guardar.

Los tokens Bearer válidos omiten los requisitos de Signature, incluidos los de la configuración del Workspace y del Template; los ámbitos del token y las restricciones de audiencia siguen aplicándose. Esta configuración no añade autenticación al acceso basado en capacidades, como las URL de Assembly Status, cancelación o carga reanudable. Mantén privados los IDs de las Assemblies y las URL de capacidades, y sigue las indicaciones de autenticación de cada endpoint.

Cómo generar Signatures

Entonces, ¿cómo se ve todo esto?

El campo params típico al crear una Assembly sin Signature Authentication es el siguiente:

{
  "auth": {
    "key": "23c96d084c744219a2ce156772ec3211"
  },
  "steps": {
    // …
  }
}

El valor de auth.key en este ejemplo es la Auth Key de Credenciales de API en tu cuenta.

Para firmar esta solicitud, hay que añadir el campo adicional auth.expires. Así se añade a nuestro contenido, que está protegido por nuestra Signature. Si alguien lo modificara, Transloadit rechazaría la solicitud porque la Signature ya no coincidiría. Habrías firmado un contenido distinto del que recibimos. Si la Signature coincide, entonces, naturalmente, compararemos la fecha y rechazaremos la solicitud según lo indicado. De este modo, resulta muy difícil que un tercero que haya obtenido este contenido repita las solicitudes indefinidamente. Porque, aunque nuestro HTTPS con calificación A+ ya debería contribuir en gran medida a evitarlo, la caché del navegador podría ser más fácil de espiar.

La propiedad expires debe contener una marca de tiempo en un futuro (cercano). Usa el formato ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ) para la fecha y asegúrate de usar UTC como zona horaria. Por ejemplo:

{
  "auth": {
    "key": "23c96d084c744219a2ce156772ec3211",
    "expires": "YOUR_FUTURE_ISO_8601_TIMESTAMP"
  },
  "steps": {
    // …
  }
}

Para calcular la Signature de esta solicitud:

  1. Desde tu front-end, serializa el objeto JavaScript anterior como una cadena JSON y envíalo a tu back-end.
  2. Desde tu back-end, calcula una Signature HMAC hexadecimal conforme a RFC 6234 sobre la cadena, con tu Auth Secret como clave y el algoritmo configurado en signature_algo de tu Auth Key. Las Auth Keys nuevas usan sha384 de forma predeterminada. Las Auth Keys antiguas sin un algoritmo configurado aceptan sha384, sha256 o sha1. Añade al principio de la cadena signature el nombre del algoritmo en minúsculas. Por ejemplo, el algoritmo predeterminado usa sha384:<HMAC-signature>. Puedes enviar esa cadena a tu front-end (siempre que hayas realizado las comprobaciones adecuadas para garantizar que se trataba de una solicitud genuina de tu front-end).
  3. Desde tu front-end, añade a tu solicitud un campo signature de un POST multipart que contenga este valor (por ejemplo, mediante un campo oculto en un formulario HTML).

La solicitud completa debería ser similar a la siguiente:

{
  "params": {
    "auth": {
      "key": "23c96d084c744219a2ce156772ec3211",
      "expires": "YOUR_FUTURE_ISO_8601_TIMESTAMP",
    },
    "nonce": "04ac6cb6-df43-41fb-a7fd-e5dd711a64e1",
    "steps": {
      // …
    },
  },
  "signature": "sha384:YOUR_SIGNATURE",
}

Una vez que Transloadit recibe la solicitud, también generamos una Signature siguiendo el mismo proceso y comparamos las dos Signatures. Si las Signatures son distintas, nuestros servidores responderán con INVALID_SIGNATURE.

En resumen, el proceso es el siguiente:

  1. Genera un contenido JSON para enviarlo a Transloadit como el campo params.
  2. Calcula una Signature a partir de ese contenido, usando tu Auth Secret como clave.
  3. Envía la solicitud a Transloadit, pasando la Signature en el campo signature
  4. Transloadit calculará la misma Signature usando el Auth Secret de tu cuenta y el contenido enviado.
  5. Si las Signatures coinciden, se permite la solicitud y se envía una respuesta adecuada. De lo contrario, se deniega la solicitud y se devuelve un error con el código INVALID_SIGNATURE.

Esto permite a Transloadit autenticar a quien realiza la llamada y verificar la integridad de params, ya que un tercero no podría calcular una Signature coincidente sin acceso a tu Auth Secret. TLS autentica a Transloadit ante tu cliente y protege la conexión. La firma de webhooks es un flujo independiente para las solicitudes que Transloadit envía a tus servidores.

A continuación se muestran algunos ejemplos de cómo realizar una solicitud POST para crear una Assembly. Te recomendamos encarecidamente usar uno de nuestros SDK, que gestionan la generación de Signatures automáticamente y están ampliamente probados.

Ejemplos de código para distintos lenguajes

Los ejemplos siguientes muestran cómo crear Assemblies usando nuestros SDK oficiales. Los SDK gestionan toda la generación de Signatures internamente, lo que hace que la integración sea más sencilla y segura.

// yarn add @transloadit/node
// or
// npm install --save @transloadit/node

import { Transloadit } from '@transloadit/node'

const transloadit = new Transloadit({
  authKey: 'YOUR_TRANSLOADIT_KEY',
  authSecret: 'YOUR_TRANSLOADIT_SECRET',
})

const response = await transloadit.createAssembly({
  params: {
    template_id: 'YOUR_TRANSLOADIT_TEMPLATE_ID',
    // your other params like notify_url, fields, etc.
  },
  waitForCompletion: true,
})

console.log(response)

Si necesitas calcular una Signature por separado (por ejemplo, para usarla en el front-end), puedes usar calcSignature:

const { signature, params } = transloadit.calcSignature({
  template_id: 'YOUR_TRANSLOADIT_TEMPLATE_ID',
})

console.log(signature, params)

Ver el código fuente de la implementación de Signatures

curl --fail-with-body -sS --location 'https://api2.transloadit.com/assemblies' \
  --form 'params={"auth":{"key":"23c96d084c744219a2ce156772ec3211","expires":"YOUR_FUTURE_ISO_8601_TIMESTAMP"},"template_id":"9cf67cbba601e37ee10c442b037e0"}' \
  --form 'signature=sha384:YOUR_SIGNATURE' \
  --form 'files=@/path/to/your/file.jpg'

URL firmadas de Smart CDN

Para firmar una URL de Smart CDN, se usa un proceso similar al de las Signatures de las solicitudes habituales a la API. Se calcula un resumen HMAC sobre una cadena derivada de la URL de Smart CDN, con el Auth Secret como clave. Para que la Signature sea válida, la Auth Key usada debe estar habilitada para su uso con Smart CDN.

La generación de una Signature de Smart CDN debe realizarse en el back-end. El proceso usa el Auth Secret, que es confidencial y no debe exponerse a tus usuarios en el front-end.

Una URL típica de Smart CDN tiene la siguiente estructura:

https://[your-workspace].tlcdn.com/[template-name]/[file-path]?[parameters]
  • [your-workspace] es el nombre de tu Workspace de Transloadit
  • [template-name] es el nombre de tu Template
  • [file-path] es la ruta al archivo que quieres transformar
  • [parameters] son los parámetros de transformación deseados (por ejemplo, h=100)

Una URL firmada de Smart CDN se genera siguiendo estos pasos:

  1. Añade el parámetro de consulta exp para definir un momento futuro a partir del cual Smart CDN ya no aceptará la Signature. Esto resulta útil para limitar temporalmente el acceso a un archivo. El momento de caducidad se representa mediante el número de milisegundos desde la época UNIX (la medianoche al comienzo del 1 de enero de 1970, UTC). Aunque este parámetro es opcional, te recomendamos encarecidamente establecer siempre un momento de caducidad. Por ejemplo, una Signature que usa exp=1722517200000 es válida hasta Thu, 01 Aug 2024 13:00:00 GMT.
  2. Añade el parámetro de consulta auth_key para definir la Auth Key correspondiente al Auth Secret que se usa para crear la Signature. Si no se establece este parámetro, la API de Transloadit asume que se ha usado para la Signature el par de Auth Key más antiguo habilitado para Smart CDN. Configurar los parámetros auth_key te permite rotar tu Auth Key sin interrumpir a tus usuarios, por lo que te recomendamos encarecidamente establecerlo. Por ejemplo: auth_key=23c96d084c744219a2ce156772ec3211
  3. Ordena los parámetros de consulta por clave en orden ascendente usando unidades de código UTF-16, de modo que coincida con URLSearchParams.sort(). La ordenación debe ser estable, es decir, si una clave aparece varias veces en la cadena de consulta, los valores correspondientes deben conservar su orden relativo. Por ejemplo, h=100&f=png&f=jpg&auth_key=hello&exp=123 se ordena como auth_key=hello&exp=123&f=png&f=jpg&h=100.
  4. Construye la cadena que se va a firmar concatenando los valores: 
    [your-workspace]/[template-name]/[file-path]?[sorted-parameters]
    Los valores de [your-workspace], [template-name] y [file-path] deben codificarse para URL para garantizar que solo contengan caracteres seguros para URL. Ten en cuenta que la cadena no empieza con una barra. El carácter ? debe omitirse si [sorted-parameters] está vacío.
  5. Calcula una Signature HMAC hexadecimal conforme a RFC 6234 sobre la cadena que se va a firmar, con tu Auth Secret como clave y SHA256 como algoritmo hash. Añade al principio de la Signature hexadecimal el nombre del algoritmo en minúsculas y dos puntos, es decir, sha256:. Por ejemplo, para SHA256, usa sha256:[hmac-signature].
  6. Añade la Signature hexadecimal con su prefijo a la URL mediante el parámetro de consulta sig, lo que da como resultado la URL firmada de Smart CDN: 
    https://[your-workspace].tlcdn.com/[template-name]/[file-path]?[parameters]&sig=sha256:[hmac-signature]
    Los valores de [your-workspace], [template-name] y [file-path] deben codificarse para URL para garantizar que solo contengan caracteres seguros para URL. Esta URL firmada puede enviarse a tu front-end o usarse en él hasta que llegue la fecha de caducidad.

Seguridad y duración de la caché

Las URL firmadas de Smart CDN no son solo un mecanismo de control de acceso. Su caducidad también determina durante cuánto tiempo un resultado recién generado puede seguir siendo apto para su almacenamiento en caché.

  • Los valores de exp más cortos reducen la ventana de repetición y refuerzan el control de acceso.
  • Los valores de exp más largos aumentan la reutilización de la caché, reducen el trabajo en el origen y, por lo general, disminuyen la latencia y el volumen de codificación.
  • En la práctica, la duración efectiva de la caché de una respuesta firmada de Smart CDN está limitada por el tiempo de validez restante de la Signature.

Esto significa que el equilibrio entre ambas opciones es sencillo:

  • Mayor sensibilidad en materia de seguridad: usa un exp más corto, lo que también implica un TTL efectivo de caché más corto.
  • Mayor reutilización de la caché y menor coste: usa un exp más largo, lo que también implica que la URL seguirá siendo utilizable durante más tiempo.

Elige el plazo de caducidad según la sensibilidad del contenido y el grado de reutilización de la caché que quieras. Para muchos casos de uso de imágenes y vistas previas, un plazo de caducidad moderado ofrece un buen equilibrio. Para contenido muy sensible, usa uno mucho más corto.

Ejemplos de código

A continuación encontrarás ejemplos en distintos lenguajes para generar URL firmadas de Smart CDN usando nuestros SDK.

// yarn add @transloadit/node
// or
// npm install --save @transloadit/node

import { Transloadit } from '@transloadit/node'

const transloadit = new Transloadit({
  authKey: 'YOUR_TRANSLOADIT_KEY',
  authSecret: 'YOUR_TRANSLOADIT_SECRET',
})

const url = transloadit.getSignedSmartCDNUrl({
  workspace: 'YOUR_WORKSPACE',
  template: 'YOUR_TEMPLATE',
  input: 'image.png',
  urlParams: { height: 100, width: 100 },
})

console.log(url)

Acceso de lectura tras la cancelación

Los Workspaces cancelados no pueden crear tokens Bearer nuevos. Los endpoints que permiten explícitamente el acceso tras la cancelación enlazan a esta guía. Usa una Auth Key activa existente y su Auth Secret; la clave debe seguir concediendo los ámbitos enumerados para el endpoint. Esto no restablece el acceso de escritura ni hace que otros endpoints estén disponibles tras la cancelación.

En un proyecto Node.js del lado del servidor en un entorno de confianza, instala el SDK con yarn add @transloadit/node. Establece TRANSLOADIT_KEY y TRANSLOADIT_SECRET, y después establece TRANSLOADIT_URL con la URL HTTPS completa que se muestra en la página del endpoint, sustituyendo los parámetros de ruta por los valores de tu recurso. Mantén privadas ambas credenciales, la URL firmada y la respuesta. Nunca ejecutes esta configuración en código del navegador.

El SDK firma params con sha384, el valor predeterminado para las Auth Keys nuevas, y proporciona la caducidad. El ejemplo añade un nonce nuevo para evitar la reutilización de Signatures. Si tu clave usa otro algoritmo de Signature, pásalo como segundo argumento a calcSignature. Incluye los filtros del endpoint dentro del objeto que se pasa como primer argumento, junto al nonce. El SDK no llama a /token para esta guía.

Guarda esto como read-api.mjs y ejecuta node read-api.mjs:

import { randomUUID } from 'node:crypto'

import { Transloadit } from '@transloadit/node'

const { TRANSLOADIT_KEY, TRANSLOADIT_SECRET, TRANSLOADIT_URL } = process.env
if (!TRANSLOADIT_KEY || !TRANSLOADIT_SECRET || !TRANSLOADIT_URL) {
  throw new Error('Set TRANSLOADIT_KEY, TRANSLOADIT_SECRET, and TRANSLOADIT_URL')
}
const transloadit = new Transloadit({
  authKey: TRANSLOADIT_KEY,
  authSecret: TRANSLOADIT_SECRET,
})
const { params, signature } = transloadit.calcSignature({ nonce: randomUUID() })
const url = new URL(TRANSLOADIT_URL)
url.searchParams.set('params', params)
url.searchParams.set('signature', signature)
const response = await fetch(url, { redirect: 'error' })
if (!response.ok) throw new Error(`HTTP ${response.status}: ${await response.text()}`)
const result = await response.json()
if (result.error) throw new Error(result.error)
console.log(JSON.stringify(result, null, 2))

Conectar un cliente MCP mediante URL

Los clientes de agentes como ChatGPT, Codex, Claude.ai, Claude Desktop, Claude Code y Cursor se conectan al servidor MCP alojado en https://api2.transloadit.com/mcp únicamente con esa URL. La API de Transloadit es un servidor de autorización OAuth 2.1 para él: el cliente descubre los endpoints, se identifica, te envía a la Consola para que inicies sesión y des tu consentimiento, y obtiene un token Bearer de corta duración para la audiencia mcp, además de un token de actualización. Ningún Auth Secret sale nunca de tu cuenta.

  1. Descubrimiento. El servidor MCP responde a las solicitudes no autenticadas con 401 y una cabecera WWW-Authenticate: Bearer resource_metadata="https://api2.transloadit.com/.well-known/oauth-protected-resource/mcp". Ese documento RFC 9728 identifica https://api2.transloadit.com como servidor de autorización, cuyos metadatos RFC 8414 en https://api2.transloadit.com/.well-known/oauth-authorization-server enumeran los endpoints siguientes.
  2. Identificación del cliente. Presenta un documento de metadatos del ID de cliente: una URL HTTPS que es el client_id y sirve JSON con el mismo client_id, un client_name y los redirect_uris. O bien regístrate una vez mediante el registro dinámico de clientes de RFC 7591 en https://api2.transloadit.com/oauth/register; los clientes envían solo su client_id (token_endpoint_auth_method: "none") o se autentican con private_key_jwt y un jwks_uri, y la respuesta contiene un client_id opaco. Las URI de redirección deben ser URL HTTPS, con coincidencia exacta, o URL de bucle local http://localhost / http://127.0.0.1, con coincidencia en cualquier puerto. Las solicitudes de tokens autentican al cliente con none o private_key_jwt, según lo que indique su documento (en token_endpoint_auth_methods_supported o, en su defecto, en token_endpoint_auth_method) o lo que declare su registro. La primera solicitud de token vincula la concesión al método que usó: una vez que una solicitud para una concesión incluye una client_assertion de RFC 7523, todas las solicitudes posteriores de tokens y de revocación para esa concesión también deben incluir una. Esa aserción es un JWT firmado (RS256 o ES256) con una clave del jwks_uri del cliente, con el ID de cliente como iss y sub. Su aud es una URL de endpoint de tokens configurada o su origen (sin barra final) para este despliegue. Tiene un exp dentro de los próximos cinco minutos y un jti que se acepta una sola vez por cliente y por región mientras la aserción siga siendo válida. Usa un jti nuevo para cada solicitud.
  3. Consentimiento. El cliente abre https://transloadit.com/c/oauth/authorize con response_type=code, su client_id, redirect_uri, un code_challenge de PKCE (solo S256), opcionalmente scope y state, y resource=https://api2.transloadit.com/mcp. Inicias sesión, eliges un Workspace y das tu aprobación; la Consola redirige el navegador de vuelta con code, tu state e iss=https://api2.transloadit.com. El código está vinculado al cliente, la URI de redirección, el desafío y el Workspace, y caduca después de 120 segundos.
  4. Tokens. El cliente envía mediante POST grant_type=authorization_code con code, code_verifier, client_id y redirect_uri a https://api2.transloadit.com/token y recibe un access_token (válido durante 604.800 segundos, 7 días, de forma predeterminada), su scope y un refresh_token. Enviar mediante POST grant_type=refresh_token con refresh_token y client_id devuelve un par nuevo y retira el token de actualización presentado; los tokens de actualización tienen una duración de 30 días y reutilizar uno retirado revoca todo el linaje.
  5. Revocación. Envía mediante POST token (un token de acceso o de actualización) a https://api2.transloadit.com/oauth/revoke según RFC 7009, o revoca la conexión en la Consola.

El indicador resource (RFC 8707) determina para qué sirve el token. resource=https://api2.transloadit.com/mcp (el valor predeterminado cuando se omite) genera un token mcp que contiene, como máximo, los ámbitos seguros de MCP (assemblies:write, assemblies:read, templates:read), limitados a los que concede la Auth Key del Workspace, y que solo acepta el servidor MCP. resource=https://api2.transloadit.com (con o sin barra final) genera un token api2 para aplicaciones que llaman directamente a la REST API, como las integraciones de Vercel Connect: contiene los ámbitos solicitados limitados a los ámbitos de la Auth Key, o todo lo que concede la clave cuando se omite scope, con la excepción de que una concesión nunca incluye la gestión de Auth Keys ni de credenciales de Template (auth_keys:*, template_credentials:* o los ámbitos globales read/write que los implican), por lo que no puede crear ni revelar credenciales duraderas. Cualquier otro valor de resource devuelve invalid_target.

Los errores del protocolo OAuth procedentes del registro de clientes, la autorización y la revocación usan el cuerpo estándar con error y error_description; los límites de tasa pueden devolver RATE_LIMIT_REACHED.

En /token, los errores de concesión de OAuth para authorization_code y refresh_token usan el cuerpo estándar con error y error_description. Los límites de tasa devuelven RATE_LIMIT_REACHED (429), y los fallos internos inesperados devuelven SERVER_500 (500). Las solicitudes mal formadas rechazadas antes de identificar la concesión pueden recibir un desafío HTTP Basic (401), o TOKEN_INVALID_REQUEST si se proporcionaron credenciales de Basic.

Tokens Bearer (credenciales de cliente)

Las tareas de CI, los servidores y otros clientes sin interfaz que disponen de una Auth Key y un Auth Secret los intercambian por un token Bearer de corta duración mediante la concesión client_credentials de OAuth 2.0, gestionada directamente por la API de Transloadit. Usa este método cuando no haya un navegador en el que dar el consentimiento; los clientes MCP interactivos deben conectarse mediante URL como se ha descrito anteriormente. Para consultar la referencia completa del endpoint, consulta la documentación de la API de /token.

Usar el token

Pasa el token como Authorization: Bearer <access_token> en las solicitudes a la API. Cuando una solicitud se autentica con un token Bearer válido, API2 considera satisfecha Signature Authentication y omite la validación de la Signature. Signature Authentication solo se exige para las solicitudes con clave y secreto. Las comprobaciones de ámbitos y audiencia siguen aplicándose. El servidor MCP acepta la audiencia mcp y la retransmite a API2 con una credencial de servicio; se rechaza cuando se presenta directamente a los endpoints habituales de API2. Puedes omitir auth.key en params, pero el contenedor params sigue siendo obligatorio para los endpoints que lo esperan.

curl --fail-with-body -sS --request POST \
  --url 'https://api2.transloadit.com/assemblies' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
  --form 'params={"template_id":"YOUR_TEMPLATE_ID"}'

Autenticación automática de MCP para /ai/chat

Si tus Steps de /ai/chat llaman a un servidor MCP alojado por Transloadit, API2 puede generar e inyectar un token Bearer de corta duración automáticamente (autenticación automática). Esto se habilita de forma explícita para cada entrada de servidor MCP:

{
  "mcp_servers": [
    {
      "type": "http",
      "url": "https://api2.transloadit.com/mcp",
      "auth": "transloadit"
    }
  ]
}

Comportamiento:

  • Si se establece auth: "transloadit" y no hay ninguna cabecera Authorization, API2 genera un token e inyecta Authorization: Bearer <token>.
  • Si ya se proporciona Authorization en mcp_servers[].headers, se deja sin cambios.
  • La autenticación automática solo funciona a través de HTTPS para hosts de dominio raíz y subdominios gestionados por Transloadit: transloadit.com, *.transloadit.com, transloadit.dev, *.transloadit.dev, transloadit.website, *.transloadit.website, transloadit.work, *.transloadit.work.
  • La URL debe usar el puerto 443 y la ruta exacta /mcp o una subruta bajo /mcp/.
  • La URL no debe contener credenciales, una cadena de consulta ni un fragmento.
  • La Auth Key debe conceder al menos uno de estos ámbitos seguros de MCP: assemblies:write, assemblies:read, templates:read.
  • El token generado se limita a la intersección de esos ámbitos seguros de MCP y los ámbitos de la Auth Key; nunca obtiene un ámbito que la Auth Key no conceda.

Preguntas frecuentes

¿Incluye Transloadit Signatures en sus solicitudes?

Transloadit firma las solicitudes de webhook para que tu servidor pueda verificar su autenticidad. La firma de webhooks es independiente del HMAC que autentica las solicitudes a la API enviadas a Transloadit.

¿Por qué no puedo usar mi Auth Secret como token Bearer?

Salvo en el intercambio de tokens entre servidores descrito anteriormente, tu Auth Secret no debe transmitirse nunca a un cliente ni incluirse en los parámetros de las solicitudes a la API. POST /token lo envía como contraseña de HTTP Basic a través de HTTPS y solo debe llamarse desde tu back-end. Para las solicitudes firmadas, el secreto permanece en tu back-end y se usa como clave HMAC. Esto impide que un actor malicioso intercepte una solicitud firmada y falsifique solicitudes dirigidas a tu cuenta. Mantén seguro tu Auth Secret usando el sistema de gestión de secretos que prefieras. Algunos ejemplos son: Vault, AWS Secrets Manager, GCP Secret Manager y Kubernetes Secrets, pero hay muchos más que podrían ser adecuados según la plataforma de back-end que elijas.

¿En qué orden deben estar las claves del cuerpo?

El orden que elijas para las claves del cuerpo puede ser arbitrario, pero es importante tener en cuenta que, sea cual sea el orden elegido, debe ser coherente con la generación de tu Signature. El hash generado depende del contenido del JSON, y un orden distinto generará un hash distinto, lo que significa que tu solicitud será denegada.