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 de params más pequeño de este tipo.

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

El campo key hace referencia a la Auth Key asociada a tu Workspace de Transloadit, que encontrarás en la página Credenciales. Lo 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 diferentes, como se describe en la documentación de cada endpoint y más abajo.

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 params.auth.expires futura. Esto se aplica incluso cuando la Signature Authentication del Workspace está desactivada. Una Auth Key por sí sola no es suficiente; las solicitudes autenticadas con token Bearer no necesitan una firma ni una caducidad aparte. Los Builtin Templates públicos de Storage son la excepción: solo pueden atender solicitudes sin firmar cuando cada importación de Storage permanece dentro de un prefijo público declarado. Esto no autoriza Assemblies sin firmar con Steps arbitrarios ni el acceso a rutas privadas de Storage.

Signature Authentication

Te recomendamos activar la Signature Authentication en tu cuenta, sobre todo si integras Transloadit desde un entorno no confiable (como desde el navegador con Uppy). Puedes activar la Signature Authentication desde la configuración del Workspace.

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

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

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

  1. Ve a la configuración del Workspace de tu cuenta.
  2. En la sección de configuración de la API, activa la opción Requerir una Signature correcta.
  3. Espera a que se complete el guardado automático.

Los tokens Bearer válidos omiten los requisitos de firma, incluida 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 URLs de estado y cancelación de Assemblies o las de carga reanudable. Mantén privados los IDs de las Assemblies y las URLs de capacidad, y sigue las indicaciones de autenticación de cada endpoint.

Cómo generar firmas

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": {
    // …
  }
}

En este ejemplo, auth.key es la Auth Key de las credenciales de API de tu cuenta.

Para firmar esta solicitud, hay que añadir el campo adicional auth.expires. Esto lo añade a nuestro payload, que está protegido por nuestra firma. Si alguien lo cambiara, Transloadit rechazaría la solicitud porque la firma ya no coincidiría. Habrías firmado un payload distinto del que recibimos. Si la firma sí coincide, naturalmente compararemos la fecha y rechazaremos la solicitud según lo indicado. Así, a un tercero que se haya hecho con este payload le resultará muy difícil repetir las solicitudes indefinidamente. Porque, aunque nuestro HTTPS con calificación A+ ya debería contribuir mucho 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 el 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 firma de esta solicitud:

  1. Desde tu front-end, convierte el objeto JavaScript anterior en una cadena JSON y envíala a tu back-end.
  2. Desde tu back-end, calcula una firma HMAC hexadecimal conforme a RFC 6234 sobre la cadena, con tu Auth Secret como clave y el algoritmo configurado en el signature_algo de tu Auth Key. Las Auth Keys nuevas usan sha384 de forma predeterminada. Las Auth Keys heredadas sin un algoritmo configurado aceptan sha384, sha256 o sha1. Antepón a 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 hecho las comprobaciones adecuadas para garantizar que se trataba de una solicitud auténtica de tu front-end).
  3. Desde tu front-end, añade a tu solicitud un campo POST multipart signature que contenga este valor (por ejemplo, con un campo oculto en un formulario HTML).

La solicitud completa debería verse de forma 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 firma siguiendo el mismo proceso y comparamos las dos firmas. Si las firmas son diferentes, nuestros servidores responderán con INVALID_SIGNATURE.

En resumen, el proceso es el siguiente:

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

Esto permite a Transloadit autenticar a quien hace la llamada y verificar la integridad de params, ya que un tercero no podría calcular una firma 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 SDKs, que gestionan la generación de firmas automáticamente y están bien probados.

Ejemplos de código para distintos lenguajes

Los ejemplos siguientes muestran cómo crear Assemblies con nuestros SDKs oficiales. Los SDKs gestionan internamente toda la generación de firmas, 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 firma 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 la firma

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'

URLs firmadas de Smart CDN

Para firmar una URL de Smart CDN se usa un proceso similar al de las firmas normales de la API. Se calcula un digest HMAC sobre una cadena derivada de la URL de Smart CDN, con el Auth Secret como clave. Para que la firma sea válida, la Auth Key utilizada debe estar habilitada para el uso de Smart CDN.

La generación de una firma 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 la Smart CDN deja de aceptar la firma. Esto es útil para limitar temporalmente el acceso a un archivo. El momento de caducidad se representa como el número de milisegundos desde la época UNIX (la medianoche del inicio del 1 de enero de 1970, UTC). Aunque este parámetro es opcional, te recomendamos encarecidamente establecer siempre un tiempo de caducidad. Por ejemplo, una firma 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 firma. Si este parámetro no se establece, la API de Transloadit supone que se ha usado para la firma el par de Auth Key más antiguo habilitado para Smart CDN. Establecer 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, igual que 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 estar codificados como URL para garantizar que solo contengan caracteres seguros para URL. Ten en cuenta que la cadena no empieza con una barra inicial. El carácter ? debe omitirse si [sorted-parameters] está vacío.
  5. Calcula una firma 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. Antepón a la firma 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 a la URL la firma hexadecimal con prefijo en 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 estar codificados como URL para garantizar que solo contengan caracteres seguros para URL. Después, puedes enviar esta URL firmada a tu front-end o usarla allí hasta que se alcance la fecha de caducidad.

Seguridad y vida útil de la caché

Las URLs 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 almacenable 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, en general, disminuyen la latencia y el volumen de codificación.
  • En la práctica, la vida útil efectiva de la caché de una respuesta firmada de Smart CDN está limitada por el tiempo de vida restante de la firma.

Eso significa que el equilibrio es sencillo:

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

Elige la ventana de caducidad según la sensibilidad del contenido y cuánta reutilización de la caché quieras. Para muchos casos de uso de imágenes y vistas previas, una ventana de caducidad moderada ofrece un buen equilibrio. Para contenido muy sensible, usa una mucho más corta.

Código de ejemplo

A continuación encontrarás ejemplos en distintos lenguajes para generar URLs firmadas de Smart CDN con nuestros SDKs.

// 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 después de la cancelación

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

En un proyecto de Node.js de confianza del lado del servidor, 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 aparece 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 de 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 firmas. Si tu clave usa otro algoritmo de firma, pásalo como segundo argumento a calcSignature. Coloca los filtros del endpoint dentro del objeto que se pasa como su 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 solo 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 más 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 un encabezado WWW-Authenticate: Bearer resource_metadata="https://api2.transloadit.com/.well-known/oauth-protected-resource/mcp". Ese documento RFC 9728 indica 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 que se describen a continuación.
  2. Identificación del cliente. Presenta un Client ID Metadata Document: una URL HTTPS que es el client_id y sirve JSON con el mismo client_id, un client_name y las 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 incluye un client_id opaco. Los URIs de redirección deben ser URLs HTTPS, que se comparan de forma exacta, o URLs de loopback http://localhost / http://127.0.0.1, que se aceptan en cualquier puerto. Las solicitudes de token 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, como 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 un client_assertion de RFC 7523, todas las solicitudes posteriores de token y de revocación para esa concesión también deben incluir uno. 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 configurada del endpoint de token o su origen (sin barra final) para este despliegue del servidor. Tiene un exp que no supera los cinco minutos en el futuro 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, al URI de redirección, al challenge y al Workspace, y caduca a los 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 nuevo par y retira el token de actualización presentado; los tokens de actualización duran 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é es el token. resource=https://api2.transloadit.com/mcp (el valor predeterminado cuando se omite) genera un token mcp que incluye como máximo los ámbitos seguros de MCP (assemblies:write, assemblies:read, templates:read), restringidos a lo que otorga 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: incluye los ámbitos solicitados restringidos a los ámbitos de la Auth Key, o todo lo que otorga la clave cuando se omite scope, salvo que una concesión nunca incluye la gestión de Auth Keys ni de credenciales de Template (auth_keys:*, template_credentials:* ni los read/write globales que la implican), por lo que no puede crear ni revelar credenciales duraderas. Cualquier otro resource recibe como respuesta 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 frecuencia pueden devolver RATE_LIMIT_REACHED.

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

Tokens Bearer (credenciales de cliente)

Los trabajos 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 con la concesión client_credentials de OAuth 2.0, que gestiona directamente 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 describe arriba. Para ver la referencia completa del endpoint, consulta la documentación de la API /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 la Signature Authentication y omite la validación de la firma. La Signature Authentication solo se exige en las solicitudes con clave y secreto. Las comprobaciones de ámbito y audiencia siguen aplicándose. La audiencia mcp la acepta el servidor MCP, que la retransmite a API2 con una credencial de servicio; se rechaza cuando se presenta directamente a los endpoints normales de API2. Puedes omitir auth.key en params, pero el envoltorio 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"}'

Auto-auth de MCP para /ai/chat

Si tus Steps de /ai/chat llaman a un servidor MCP alojado por Transloadit, API2 puede generar e inyectar automáticamente un token Bearer de corta duración (auto-auth). Se activa de forma opcional 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 ningún encabezado Authorization, API2 genera un token e inyecta Authorization: Bearer <token>.
  • Si ya se proporciona Authorization en mcp_servers[].headers, se deja intacto.
  • La auto-auth solo funciona mediante HTTPS para dominios apex 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 otorgar al menos uno de estos ámbitos seguros de MCP: assemblies:write, assemblies:read, templates:read.
  • El token generado se restringe 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 otorgue.

Preguntas frecuentes

¿Incluye Transloadit firmas 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 de servidor a servidor descrito arriba, tu Auth Secret nunca debe transmitirse a un cliente ni incluirse en los parámetros de las solicitudes a la API. POST /token lo envía como contraseña HTTP Basic mediante HTTPS y solo debe llamarse desde tu back-end. En 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 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; sin embargo, es importante tener en cuenta que el orden que elijas debe ser coherente con la generación de tu firma. El hash generado depende del contenido del JSON, y un orden diferente generará un hash diferente, lo que significa que tu solicitud será denegada.