Crear un JWT firmado
Emitir un JWT correcto significa alinear con precisión el encabezado, el conjunto de claims y la firma, y un formato de expiración equivocado o un claim de audience faltante puede romper en silencio todos los servicios que dependen de él. Esta API emite un token correctamente firmado a partir de los claims que le proporcione, usando HS256 o RS256, para que deje de programar a mano la lógica de tokens en scripts, pruebas y servicios internos.
Ejecutar — gratis
Corre en su navegador. Gratis y sin límite: sus datos no salen de esta página.
Quién necesita emitir tokens fuera de un sistema de autenticación completo
Los proveedores de identidad completos existen para los flujos de inicio de sesión de usuarios, pero mucho trabajo legítimo ocurre fuera de ese camino: llamadas entre servicios que necesitan un token de vida corta, entornos de prueba que requieren un token que represente un rol de usuario específico, scripts de staging que suplantan a un tenant para reproducir un error, y herramientas internas que emiten tokens con permisos acotados para accesos temporales. Levantar un servidor de autenticación completo para esos casos es excesivo; una sola llamada de firma no lo es.
Cómo se ve la solicitud
Envíe POST /dev/jwt-sign con su payload de claims — cosas como sub, exp, aud y cualquier campo personalizado que sus servicios esperen — junto con el algoritmo y la clave: un secreto compartido para HS256, o una clave privada para RS256. La tarea corre de forma asíncrona, devolviendo un task_id de inmediato, y el token terminado y listo para usar llega por webhook firmado o por un enlace firmado válido durante 24 horas.
Por qué HS256 y RS256 cubren casi todos los casos
HS256 firma y verifica con el mismo secreto compartido, lo cual es rápido y simple cuando un solo servicio o un grupo pequeño y confiable controla ambos extremos. RS256 firma con una clave privada pero permite que cualquiera verifique con la clave pública correspondiente, que es justo lo que necesita cuando varios servicios independientes deben comprobar tokens sin llegar a poseer el secreto de firma. Desde que el estándar del JWT se publicó en el RFC 7519 en 2015, esta combinación se convirtió en la opción por defecto en la gran mayoría de los sistemas en producción.
Cómo encaja en pipelines automatizados
Los equipos llaman a este endpoint desde suites de pruebas de CI que necesitan tokens frescos en cada corrida, desde herramientas administrativas internas que emiten tokens de acceso acotados bajo demanda, desde microservicios que generan tokens de vida corta para llamar a un servicio par, y desde scripts de pruebas de carga que necesitan miles de tokens distintos pero válidos sin levantar un flujo de login real para cada uno.
Qué recibe y qué no
La respuesta es la cadena del token firmado, sin nada adjunto, y la clave que envía para firmar se usa solo para esa operación puntual y luego se descarta, sin registrarla ni reutilizarla. Los claims estructuralmente inválidos, como un exp que no es numérico, se rechazan con un error específico antes de firmar nada, y como las tareas fallidas nunca se cobran, iterar sobre la estructura de sus claims no tiene costo adicional.
Qué puede hacer con ella
Pruebas de CI e integración
Genere un token fresco y correctamente firmado para cada caso de prueba sin mantener un servidor de autenticación simulado.
Llamadas entre servicios
Emita tokens de vida corta para que un job de backend se autentique contra una API par sin compartir credenciales de larga duración.
Suplantación en staging y QA
Genere un token que represente a un usuario o rol de tenant específico para reproducir un error reportado en un entorno controlado.
Herramientas internas con acceso acotado
Emita tokens con permisos estrechos bajo demanda para dashboards internos o scripts administrativos que necesitan acceso temporal y auditable.
Preguntas frecuentes
¿Cómo genero un JWT con esta API?
Envíe POST /dev/jwt-sign con sus claims, el algoritmo y la clave de firma, y el token terminado llega por webhook o enlace firmado.
¿Qué algoritmos pueden firmar mis tokens?
HS256 con secreto compartido y RS256 con clave privada, cubriendo tanto la firma simétrica como la asimétrica.
¿Es gratuita la API para generar JWT?
La herramienta de arriba es gratis en su navegador. La API es de pago: cada llamada se descuenta de su saldo prepago de ForHosting KIT — se recarga desde $10.00 (no caduca), se paga el precio publicado de cada solicitud, y una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens, y una tarea fallida no se cobra.
¿Cuánto cuesta generar un token?
$0.002 por solicitud sin importar el algoritmo, y un intento de firma fallido nunca se cobra.
¿Puedo definir una expiración o claims personalizados?
Sí, usted controla todo el payload de claims, incluyendo exp, aud, sub y cualquier campo personalizado que sus servicios necesiten.
¿Guardan las claves de firma que envío?
No, las claves se usan únicamente para firmar ese token puntual y se descartan de inmediato después, nunca se retienen ni se usan para entrenar modelos.
¿Puedo generar tokens en lote?
Sí, envíe tantas solicitudes de firma independientes como necesite; cada una se cobra y procesa por separado al mismo precio por solicitud.
¿Qué pasa si mi payload de claims es inválido?
La API lo rechaza con un error específico y accionable antes de firmar nada, para que corrija la estructura sin tener que adivinar.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/dev/jwt-sign \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"items":["valor-1","valor-2"]}'const res = await fetch("https://api.kit.forhosting.com/dev/jwt-sign", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"items": [
"valor-1",
"valor-2"
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/jwt-sign",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"items": [
"valor-1",
"valor-2"
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/jwt-sign", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"items":["valor-1","valor-2"]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"items":["valor-1","valor-2"]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/jwt-sign", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"items": [
"valor-1",
"valor-2"
]
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.jwt_sign",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |