01
Revisar la unidad
exp, nbf e iat usan NumericDate en segundos Unix. No copies sin convertir una marca en milisegundos.
Referencia para desarrolladores
Claims JWT y errores OAuth
Busca un claim o error OAuth y compara ubicación de respuesta, ejemplo ficticio y fuente RFC.
claims JWT
Coincidencias
exp
Contexto de respuesta: Claim JWT · RFC 7519
Significado: Vencimiento en formato NumericDate, en segundos Unix.
Comparar segundos Unix, no milisegundos.
Ejemplo ficticio de respuesta
{ "exp": 1893456000 }Son datos ficticios; no los uses como credenciales.
La búsqueda queda en el navegador; los enlaces de fuente se abren solo al elegirlos.
Categoría
1 de 23 entradas
RFC 7519 / 6749 / 6750Revisado el 23/09/2026
Los claims JWT como exp y aud explican el contenido de un token, pero no prueban que su firma sea válida. Esta referencia permite revisar los campos sin pegar credenciales.
Un mismo error OAuth aparece en lugares distintos: redirección, JSON del token o cabecera Bearer. Cada entrada conserva ese contexto. En algunos proveedores aparecen como notificaciones de token; revisa allí los requisitos propios.
Por qué consultar estos claims JWT
Por qué consultar estos claims JWT
Significado sin credenciales
Los claims JWT muestran un valor ficticio junto a la sección RFC. exp usa segundos Unix; ver el payload no equivale a validar el token.
Separar errores iguales
invalid_request puede ir en la consulta de redirección, en JSON o en WWW-Authenticate. La forma de respuesta ayuda a localizar el fallo.
Del campo al contexto
02
Identificar el endpoint
Ante errores OAuth, distingue autorización, token y recurso antes de aplicar una explicación.
03
Seguir la fuente
Abre la sección RFC y la documentación del proveedor; usa un depurador aparte para un token real.
Códigos con ejemplos y fuentes
Siete campos registrados
Los siete claims JWT de RFC 7519 tienen un ejemplo ficticio y enlace a su definición.
Errores por endpoint
RFC 6749 separa errores de autorización y de token aunque compartan el mismo código.
Respuesta Bearer
RFC 6750 aporta ejemplos de WWW-Authenticate y estado HTTP recomendado.
Alcance de esta referencia
- Sin veredicto de identidad
- Esta página de claims JWT no acepta tokens, verifica firmas ni determina el estado de una sesión.
- Conjunto fijo
- Incluye RFC 7519, 6749 y 6750, sin incorporar automáticamente OIDC ni extensiones del proveedor.
- Texto humano, no código
- error_description es opcional; la lógica debe usar error y endpoint, no una frase variable.
- No introducir credenciales
- No pegues JWT reales, claves de firma ni códigos de autorización, tampoco en parámetros de URL. Solo se consultan datos fijos.
- Sin consulta de red
- La búsqueda no contacta al proveedor de identidad ni pasa valores automáticamente a otras herramientas. Examina la solicitud real por separado.
- Mantener el contexto
- invalid_request cambia de ubicación según el endpoint; invalid_token e insufficient_scope también requieren tratamiento Bearer distinto.
- Sin caducidad en vivo
- Los ejemplos NumericDate usan segundos Unix. Un valor fijo no indica si tu sesión o un token no introducido han caducado.
Preguntas sobre claims JWT
¿Qué significan iss y aud en un JWT?
iss identifica al emisor y aud al destinatario previsto. El servicio debe validar ambos en su contexto.
¿Es obligatorio exp en todos los JWT?
No siempre. RFC 7519 registra exp, pero cada perfil decide qué campos exige.
¿En qué se diferencian invalid_grant e invalid_client?
invalid_client indica fallo de autenticación del cliente; invalid_grant afecta la concesión o el token de actualización.
¿Se puede usar error_description como código estable?
No conviene. Es texto opcional para personas y su redacción cambia entre proveedores.
¿Decodificar un JWT demuestra que es válido?
No. Después hay que comprobar firma, emisor, destinatario, tiempo y política de la aplicación.
¿Falta una entrada o hay algún error?
Consultar claims JWT
Empieza por exp o un error OAuth, mira el endpoint y la fuente RFC antes de tratar credenciales reales.