Transloadit is enterprise-ready

Kevin van Zonneveld

Co-founder · Amsterdam, The Netherlands ·

Every security questionnaire asks the same things. Who can sign in, and how do you remove them? What can a leaked key do? What do you commit to in writing? Transloadit now has a clear answer to each, so your review can move on to the next vendor.

Single sign-on for your Workspace

Members of Enterprise Workspaces can now sign in to the Console through SAML 2.0. Your identity provider decides who gets in, and you manage access in one place instead of in yet another user list.

SSO is in early access, so it starts with us: email our sales team, and we enable it for your Workspace and help you set it up. The Workspace owner then opens Settings → Single sign-on (SAML) in the Console. There they copy our service provider entity ID, ACS URL, and metadata URL into the identity provider, and paste the identity provider's entity ID, SSO URL, X.509 certificate, and email attribute back into Transloadit. Saving asks for your password again. The identity provider must sign its assertions and send a persistent NameID.

Teammates then choose Continue with SSO on the login page and enter their Workspace slug. A few details that security reviewers tend to ask about:

Provisioning. Turn on Allow just-in-time user provisioning and new people get an account with the User role on their first sign-in, within your plan's seats. With it off, only existing members and invited people can sign in.
Offboarding. People who only ever sign in through SSO have no Transloadit password, so once your identity provider stops vouching for them, they cannot start a new session. Remove someone from the Workspace and their SSO session ends on their next request.
Scope. SSO sits next to password sign-in rather than replacing it, and logins start at Transloadit (SP-initiated). Members who already have a password can still use it.

Passkeys as your second factor

Two-factor authentication in the Console used to mean a six-digit code sent by email. You can now use a passkey instead: Face ID, Touch ID, or a hardware security key. A passkey only works on the site it was created for, so a look-alike login page cannot phish it.

Open User settings → Sign-in security → Two-factor authentication, choose Passkey, and follow your browser's prompt. You can switch back to email codes at any time. Passkeys apply to accounts that sign in with a password. Google and GitHub sign-ins keep relying on that provider.

Signing requests with SHA-384

Signature authentication proves that a request comes from someone who holds your secret. New Auth Keys now default to HMAC-SHA384 signatures. Each key has its own algorithm setting: SHA-384 is recommended, SHA-1 is deprecated, and keys that sign Smart CDN URLs use SHA-256. Once a key has an algorithm set, we only accept signatures made with that algorithm. Older keys stay on “Legacy compatibility”, which accepts SHA-1, SHA-256, and SHA-384 until you switch them over.

Our Node SDK already signs with SHA-384. If you sign requests yourself, prefix the hex digest with sha384:. Here is a small helper that uses only Node's built-in crypto and fetch:

// sign.mjs
import { createHmac } from 'node:crypto'

export async function api2(method, path, fields, key, secret) {
  const expires = new Date(Date.now() + 10 * 60 * 1000).toISOString()
  const params = JSON.stringify({ auth: { key, expires }, ...fields })
  const hmac = createHmac('sha384', secret).update(params).digest('hex')
  const body = new URLSearchParams({ params, signature: `sha384:${hmac}` })
  const res = await fetch(`https://api2.transloadit.com${path}`, { method, body })
  return res.json()
}

This script uses it to create an Assembly that imports an image and resizes it:

// assembly.mjs
import { api2 } from './sign.mjs'

const { TRANSLOADIT_KEY, TRANSLOADIT_SECRET } = process.env
const steps = {
  imported: { robot: '/http/import', url: 'https://demos.transloadit.com/inputs/chameleon.jpg' },
  thumb: { use: 'imported', robot: '/image/resize', width: 200, height: 200 },
}
const assembly = await api2('POST', '/assemblies', { steps }, TRANSLOADIT_KEY, TRANSLOADIT_SECRET)
console.log(assembly.ok ?? assembly.error, assembly.assembly_id ?? assembly.message)

Run it with Node.js 18 or later:

$ export TRANSLOADIT_KEY=MY_AUTH_KEY TRANSLOADIT_SECRET=MY_SECRET_KEY
$ node assembly.mjs
ASSEMBLY_EXECUTING 1aa00d5b547b…

A few seconds later, the Assembly reports ASSEMBLY_COMPLETED with a 200×133 thumbnail. The authentication docs cover the full signing contract.

Scoped Auth Keys

A key that can do everything is a liability when it leaks. Every new Auth Key now needs at least one scope, and each scope covers one area of the API: Assemblies, Templates, Template Credentials, Auth Keys, billing, queues, Smart CDN signing, and more. Give each app and environment its own key with only the permissions it needs, and revoke one without touching the others.

In the Console, go to Credentials and click New Auth Key. The Private image delivery (Smart CDN signing) preset creates a key that can sign Smart CDN URLs but cannot create standalone Assemblies or manage Storage. Choose Custom to tick the scopes yourself. The API offers the same through creating an Auth Key and listing the available scopes.

We check the scope on each call. The key behind these examples can create Assemblies, but not new keys:

// create-key.mjs
import { api2 } from './sign.mjs'

const { TRANSLOADIT_KEY, TRANSLOADIT_SECRET } = process.env
const fields = { scope: 'assemblies:write', description: 'my-app staging' }
const res = await api2('POST', '/auth_keys', fields, TRANSLOADIT_KEY, TRANSLOADIT_SECRET)
console.log(res.ok ?? res.error, res.required_scope ?? res.auth_key.scope)

$ node create-key.mjs
INSUFFICIENT_AUTH_SCOPE auth_keys:write

A key with the auth_keys:write scope gets AUTH_KEY_CREATED instead, along with the new key's secret. Store that secret right away: it is not shown again unless you set can_show_auth_secret when creating the key.

The paperwork

The security page collects what procurement asks for:

SOC 2 Type II. Our attestation report is available on request.
ISO 27001. Transloadit is ISO/IEC 27001 certified, as we announced in June. The certificate and related security documents are available on request.
SLA. Our service level agreement is public. It sets an annual uptime commitment and a commitment on how long files wait in the queue, and it grants service credits when we miss either one.

For finance teams, the Billing Admin role from June lets someone manage the plan, invoices, billing email, and payment method without full Workspace admin rights.

Getting started

Passkeys, scoped Auth Keys, and SHA-384 signatures are available on every plan today. SAML single sign-on is in early access for the Enterprise plan on our pricing page. To enable SSO, request the SOC 2 Type II report, or walk through a security questionnaire together, email our sales team.