¿Son los tokens reales JWTs?

No, access_token y refresh_token son nuevos UUIDs, no JWTs firmados. Si su cliente descodifica el token de acceso y lee claims de él, esta plantilla no lo satisfará; acompáñala con la plantilla JWKS y un token firmado real en su lugar.

¿Valida la concesión o las credenciales de cliente?

No. Nunca verifica client_id, client_secret o el código de autorización, y siempre devuelve la misma respuesta exitosa. Para probar la ruta de falla, crea un segundo mock devolviendo un 400 con un cuerpo de error OAuth2.

¿Cómo pruebo la caducidad y el refresco de los tokens?

Baja expires_in a unos pocos segundos para que la lógica de refresco de tu cliente se dispare enseguida. Como cada llamada devuelve un refresh_token nuevo, también puedes confirmar que tu código guarda el último y no reutiliza el original.

Simular una respuesta de token de OAuth2

Un mock POST que devuelve una respuesta de token en forma de RFC 6749 con un access_token y un refresh_token nuevos.

Esta plantilla devuelve una respuesta de token con la forma que define el RFC 6749 — access_token, token_type, expires_in, refresh_token y scope — con valores nuevos en cada llamada. Te permite construir la mitad cliente de un flujo OAuth2 antes de que haya un proveedor de identidad disponible, y comprobar que tu código almacena, refresca y caduca los tokens correctamente.

Sustituye a un endpoint de API de terceros.

Payload de respuesta

{
  "access_token": "{{faker.uuid}}",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "{{faker.uuid}}",
  "scope": "read write"
}

Campos que vale la pena conocer

Campo	Lo que significa
access_token	Un nuevo UUID en cada llamada a través de {{faker.uuid}}, no un token firmado real.
token_type	Codificado rígidamente como Bearer.
expires_in	Un tiempo de vida codificado en segundos; edítalo para probar el manejo de caducidad.
refresh_token	Un nuevo UUID a través de {{faker.uuid}}.
scope	Ámbitos (scopes) concedidos separados por espacio; edítalo para probar la lógica basada en alcance.

Crear el mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"access_token\":\"{{faker.uuid}}\",\"token_type\":\"Bearer\",\"expires_in\":3600,\"refresh_token\":\"{{faker.uuid}}\",\"scope\":\"read write\"}"
}'

Llamarlo

curl -X POST https://quickmock.dev/m/<slug>

Lo que obtienes

POST /m/<slug> -> 200 an RFC 6749-shaped token response
access_token/refresh_token are fresh UUIDs each call

En qué se diferencia de la realidad

access_token y refresh_token son solo nuevos UUID, no verdaderos JWT firmados, y el mock nunca comprueba client_id, client_secret ni un código de autorización; siempre devuelve la misma respuesta de éxito.

Fuentes

Preguntas frecuentes

¿Son los tokens reales JWTs?: No, access_token y refresh_token son nuevos UUIDs, no JWTs firmados. Si su cliente descodifica el token de acceso y lee claims de él, esta plantilla no lo satisfará; acompáñala con la plantilla JWKS y un token firmado real en su lugar.
¿Valida la concesión o las credenciales de cliente?: No. Nunca verifica client_id, client_secret o el código de autorización, y siempre devuelve la misma respuesta exitosa. Para probar la ruta de falla, crea un segundo mock devolviendo un 400 con un cuerpo de error OAuth2.
¿Cómo pruebo la caducidad y el refresco de los tokens?: Baja expires_in a unos pocos segundos para que la lógica de refresco de tu cliente se dispare enseguida. Como cada llamada devuelve un refresh_token nuevo, también puedes confirmar que tu código guarda el último y no reutiliza el original.

¿Listo para usarlo?

Ábrelo en el generador de mocks para ajustarlo primero

Combina bien con esta guía: Simular un endpoint de API REST

Plantillas relacionadas

← Todas las plantillas

Última actualización: 2026-10-17