Service tokens y mTLS: identidad para máquinas

Todo lo anterior daba por supuesto un navegador y una persona detrás. Ahora quita las dos cosas. El cron que sincroniza el catálogo a las tres de la mañana no sabe leer una pantalla de inicio de sesión; el proveedor de pagos que te avisa por webhook no tiene cuenta en tu directorio; el servicio interno que llama a tu API de facturación no puede introducir un segundo factor. Y sin embargo todos ellos necesitan exactamente lo mismo que un usuario: llegar a tu Worker habiendo demostrado que son quienes dicen. Esta lección cierra el nivel con las dos formas de conseguirlo, un secreto compartido y un par de claves, y con la comparación entre ambas, que resulta ser una de las distinciones más consecuentes de toda la criptografía aplicada.

El problema de la máquina que llama

El flujo de la lección dos termina en una redirección hacia el proveedor de identidad. Para un navegador eso es transparente; para un cliente automático es un error. Recibe una respuesta de redirección hacia un dominio que no conoce, y en el mejor de los casos falla con claridad y en el peor la sigue, aterriza en una página HTML y guarda ese HTML como si fuera tu respuesta JSON. Por eso Access distingue una acción específica, Service Auth, que no redirige jamás: o la credencial viene en la petición, o la respuesta es un error inmediato.

Esa acción se evalúa antes que las de identidad humana, lo cual no es un capricho sino una necesidad. Si se evaluase después, una política de Allow colocada arriba interceptaría al cliente automático y lo mandaría al proveedor de identidad antes de que nadie mirase su credencial de máquina. El orden garantiza que el tráfico sin persona detrás se resuelva sin persona detrás.

Conviene separar desde el principio dos casos que se confunden y tienen soluciones opuestas. Cuando tú controlas al llamante, porque es tu cron, tu proceso por lotes o el servicio de un socio con quien hablas, puedes imponerle una credencial y todo lo de esta lección se aplica. Cuando no lo controlas, porque es la pasarela de pagos avisándote de un cobro o el proveedor de correo notificando un rebote, no hay ninguna credencial que puedas exigirle: solo puedes verificar la firma que ese tercero calcula sobre el cuerpo con un secreto compartido. Ese camino no pasa por Access en absoluto, y el error de intentar meterlo aquí produce sistemas donde el webhook simplemente deja de llegar sin que nadie se entere durante semanas.

El secreto portador y su impuesto

Un service token de Access son dos valores: un identificador de cliente, que termina en .access y no es secreto, y un secreto de cliente que se muestra una única vez en el momento de crearlo. El cliente los envía en dos cabeceras y Access los valida en el borde.

curl https://api.ejemplo.com/sincronizar \
  -H "CF-Access-Client-Id: $CF_CLIENT_ID" \
  -H "CF-Access-Client-Secret: $CF_CLIENT_SECRET"

Cuando la validación pasa, Access emite un JWT igual al de una persona salvo en dos campos, y esa diferencia es la que tu Worker debe usar: el sujeto viene vacío y aparece common_name con el identificador de cliente. Toda la verificación de la lección tres sigue aplicando sin cambios, y ese campo te permite distinguir sin ambigüedad una llamada de máquina de una llamada de persona, que es una distinción que tu lógica de autorización casi siempre quiere hacer.

const claims = await identidad(request);
if (!claims) return new Response("no autorizado", { status: 403 });

const esMaquina = Boolean(claims.common_name) && !claims.sub;
if (esMaquina && request.method !== "POST") {
  return new Response("operacion no permitida a un cliente automatico", { status: 403 });
}

Ese fragmento hace algo que conviene convertir en costumbre: acotar por tipo de llamante y no solo por identidad. Una máquina suele necesitar dos o tres operaciones concretas y ninguna más, mientras que una persona necesita explorar. Reflejar esa diferencia en el código cuesta tres líneas y reduce el alcance de un secreto filtrado a lo que ese secreto tenía que poder hacer.

Desde tu lado, el secreto se guarda como cualquier otro: nunca en el manifiesto, nunca en una variable de texto plano, sino como secreto cifrado o en el almacén de secretos, y se lee desde env en el momento de la llamada saliente.

La duración del token es configurable y el valor por defecto es generoso, del orden de un año, lo que en la práctica significa que muchos despliegues acaban con credenciales que llevan más tiempo vivas que la mitad del equipo que las usa. Elegir una vida corta obliga a automatizar la renovación desde el primer día, y esa obligación es precisamente el beneficio: un mecanismo de rotación que se ejercita cada mes funciona el día que hace falta, y uno que no se ha ejecutado nunca es una hipótesis.

La rotación es la contrapartida obligatoria, y hacerla sin corte exige solapamiento. El patrón correcto tiene cuatro pasos y ninguno se puede saltar: emites el token nuevo, lo despliegas en todos los llamantes, verificas en los registros de acceso que el identificador antiguo ya no aparece, y solo entonces revocas. Invertir el tercero y el cuarto es la causa más habitual de una avería nocturna en un proceso por lotes que nadie recordaba que existía. Una política que admita cualquier service token válido de la organización simplifica la rotación y a cambio renuncia a distinguir quién llama, lo cual solo es aceptable si de verdad da igual.

mTLS: la clave que no viaja

La alternativa cambia la naturaleza de la prueba. Con TLS mutuo el cliente presenta un certificado durante el saludo, y demuestra que posee la clave privada correspondiente sin enviarla nunca. Cloudflare permite subir la autoridad certificadora que emite esos certificados, asociarla a los nombres de anfitrión que la exigen, y a partir de ahí el resultado de la validación queda disponible como campos evaluables tanto en reglas del WAF como en selectores de política de Access, entre ellos si el certificado se verificó, si está revocado, su nombre distinguido de sujeto y su huella.

La contrapartida de mTLS está toda concentrada en una palabra: revocación. Mientras el certificado sea válido y la clave siga en manos de quien la tenga, la puerta está abierta, y retirar esa validez antes de tiempo exige que el verificador consulte una lista de revocados, que la lista esté disponible y que esté fresca. La respuesta moderna a ese problema no consiste en mejorar las listas sino en evitarlas: emitir certificados de vida muy corta, de horas en lugar de años, y renovarlos automáticamente mientras la máquina siga mereciendo el acceso. La caducidad hace por ti lo que la revocación nunca terminó de hacer bien, y de paso convierte una operación manual de emergencia en un proceso rutinario que se ejercita cada día.

Del lado saliente, un Worker que deba presentarse ante una API protegida con mTLS no puede hacerlo con un fetch normal, porque no hay dónde poner la clave. Wrangler resuelve esto subiendo el par y exponiéndolo como binding, y a partir de ahí el propio binding tiene un método fetch que realiza la petición presentando el certificado.

npx wrangler mtls-certificate upload \
  --cert cliente.pem --key cliente.key --name cert-interno

[[mtls_certificates]]
binding = "CERT_INTERNO"
certificate_id = "d3ad...beef"

const respuesta = await env.CERT_INTERNO.fetch("https://interno.ejemplo.com/facturas");

Hay un detalle de esa configuración que conviene no pasar por alto: el manifiesto guarda el identificador del certificado, no el certificado. La clave privada se subió una vez a la plataforma y ya no vuelve a existir como texto en ningún sitio que tú controles, ni en el repositorio, ni en la tubería de despliegue, ni en la memoria de tu proceso. Ese es exactamente el mismo patrón que los secretos cifrados del nivel ocho, llevado ahora a material criptográfico asimétrico.

Fíjate en la simetría con todo el nivel: la clave privada nunca aparece en tu código, no se puede imprimir, no se puede filtrar por un registro y no existe como cadena que alguien pueda copiar. El binding entrega una capacidad, no un valor, que es exactamente el modelo de capacidades que viste en el nivel dos aplicado ahora a la identidad de tu propio servicio.

Elegir sin inventar autenticación

Antes de configurar nada conviene hacerse una pregunta que ahorra la mitad del trabajo: dónde vive el llamante. Si es otro Worker de tu propia cuenta, no necesitas ninguna de las dos cosas de esta lección. Un service binding entrega la petición al Worker destino sin salir a la red, sin resolver DNS, sin coste de TLS y sin exponer un extremo público que haya que proteger. Poner un service token entre dos Workers de la misma cuenta es fabricar un secreto, un canal y un problema de rotación para resolver algo que la plataforma ya resuelve por construcción.

flowchart TD
Q[quien llama] --> A[otro Worker de tu cuenta]
A --> B[service binding sin credencial]
Q --> C[sistema externo]
C --> D[puedes gestionar una autoridad certificadora]
D --> E[mTLS con nombre comun como selector]
C --> F[no puedes gestionar PKI]
F --> G[service token con Service Auth y rotacion]
E --> H[verifica el JWT en el Worker]
G --> H

Hay una tentación intermedia que conviene desactivar antes de que aparezca: usar un service token entre dos Workers de la misma cuenta porque así el código del llamado es idéntico venga de donde venga. La uniformidad es real y el precio también, porque acabas de crear un extremo público que antes no existía, un secreto que rotar, una latencia de red y una superficie que proteger, todo para no escribir una rama. Si de verdad quieres una sola forma de autorizar, la manera correcta es que el service binding entregue el sujeto como argumento de una llamada de tipo RPC y que la lógica de autorización sea la misma función en ambos casos.

Repara en que las dos ramas terminan en el mismo sitio. Da igual cómo se haya demostrado la identidad en el borde: el Worker sigue recibiendo un JWT de Access y sigue teniendo que verificarlo con las mismas cuatro comprobaciones de la lección tres. Esa uniformidad es el mayor beneficio práctico del diseño, porque tu código de autorización no necesita saber si al otro lado había una persona con segundo factor o un proceso por lotes con un certificado: recibe un sujeto probado y decide.