Visión General y Alcance
El estándar RFC 7519 reserva nombres de claims específicos de 3 letras para optimizar el tamaño del payload y garantizar la interoperabilidad entre servidores de identidad y recursos protegidos.
Tabla de Especificaciones y Matriz
Filtro instantáneo por palabra clave, código o directiva
| Clave / Código | Definición y Detalles | Jerarquía Semántica GEO | Especificación y Notas |
|---|---|---|---|
| iss | iss (Issuer) Identifies the principal that issued the JWT (e.g. auth.example.com). "iss": "https://auth.example.com" | ●iss ↳JWT claim ↳registered claim ↳token authority issuer | RFC 7519 §4.1.1 Case-sensitive string or URI; receivers must verify this matches their trusted identity provider. |
| sub | sub (Subject) Identifies the principal that is the subject of the JWT (e.g. user ID). "sub": "usr_948194a2b" | ●sub ↳JWT claim ↳registered claim ↳principal subject identifier | RFC 7519 §4.1.2 Must be locally unique in the context of the issuer or globally unique. |
| aud | aud (Audience) Identifies the recipients that the JWT is intended for (e.g. client ID or API service URI). "aud": "https://api.example.com/v1" | ●aud ↳JWT claim ↳registered claim ↳intended recipient scope | RFC 7519 §4.1.3 If the receiving service is not present in the aud claim, the token MUST be rejected. |
| exp | exp (Expiration Time) Identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. "exp": 1791244800 | ●exp ↳JWT claim ↳registered claim ↳expiration timestamp limit | RFC 7519 §4.1.4 Must be a NumericDate integer (seconds since Unix epoch: 1970-01-01T00:00:00Z UTC). |
| nbf | nbf (Not Before) Identifies the time before which the JWT MUST NOT be accepted for processing. "nbf": 1791241200 | ●nbf ↳JWT claim ↳registered claim ↳activation timestamp limit | RFC 7519 §4.1.5 NumericDate integer; useful for future-dated activation of subscription passes. |
| iat | iat (Issued At) Identifies the time at which the JWT was created and issued. "iat": 1791241200 | ●iat ↳JWT claim ↳registered claim ↳token generation timestamp | RFC 7519 §4.1.6 Can be used to determine age of the token or revoke tokens issued prior to a password change. |
| jti | jti (JWT ID) Provides a unique identifier for the JWT; useful for one-time tokens and replay prevention. "jti": "d3b07384-d113-46d4-8da8-da2b7a0f968a" | ●jti ↳JWT claim ↳registered claim ↳unique token nonce identifier | RFC 7519 §4.1.7 Allows servers to maintain a blacklist of revoked jti UUIDs. |
Decoded JWT Payload Example with Standard Claims
{
"iss": "https://auth.curious-techie.com",
"sub": "user_01HZX87QW5B",
"aud": "https://api.curious-techie.com",
"exp": 1791244800,
"nbf": 1791241200,
"iat": 1791241200,
"jti": "9f8c6e2b-4a51-419b-b0b3-1e52f75a6c38",
"role": "admin",
"email": "alex@curious-techie.com"
}All registered timestamps are in seconds since 1970 (not milliseconds), adhering to RFC 7519 NumericDate format.
Preguntas y Respuestas sobre Estándares
Are JWT claims encrypted by default?↓
References & Primary Sources
Every source below directly substantiates technical statements and protocol behaviors explained in Referencia de Claims JWT (RFC 7519). Curious-Techie prioritizes official Internet standards (IETF RFCs, W3C Recommendations, WHATWG specifications) and established security bodies (OWASP, NIST). Zero sponsored or secondary links.
- [1]IETFPrimary SpecificationRFC 7519 • Section 3 & 4Verified Primary SourceTechnical Claim Supported:
Defines the compact, URL-safe format of JSON Web Tokens consisting of three Base64URL segments (Header, Payload, Signature) and registered claims (iss, sub, aud, exp, nbf, iat, jti).
“A JWT is represented as the concatenation of the Encoded JWT Header, the Encoded JWT Claims Set, and the Encoded JWT Signature or Encoded JWT Encryption Data, with the parts being separated by period ('.') characters.”Source URI: https://datatracker.ietf.org/doc/html/rfc7519 - [2]IETFPrimary SpecificationRFC 7515 • Section 4 (Cryptographic Signatures)Verified Primary SourceTechnical Claim Supported:
Defines digital signatures and MAC algorithms (HS256, RS256, ES256) used to secure JWT integrity and verify token authorship.
Source URI: https://datatracker.ietf.org/doc/html/rfc7515 - [3]IETFAuthoritative Security StandardRFC 8725 • Security Considerations § 3Verified Primary SourceTechnical Claim Supported:
Mandates explicit algorithm validation on receiving servers, prohibiting the insecure "alg: none" algorithm and enforcing strict signature verification.
Source URI: https://datatracker.ietf.org/doc/html/rfc8725 - [4]OWASPAuthoritative Security StandardOWASP Cheat Sheet Series • Token Storage & RevocationVerified Primary SourceTechnical Claim Supported:
Details token theft mitigation, recommending storage in secure HttpOnly cookies over localStorage and outlining token revocation strategies.
Ecosistema Técnico Relacionado y Próximos Pasos
Herramientas Relacionadas
Guías Técnicas Relacionadas
Ultimate Guide to JWT Authentication & Security
Master token issuance, asymmetric signing keys (RS256 vs HS256), refresh token rotation, and secure cookie storage.
Ultimate Guide to Web Authentication & OAuth
Architecting modern authentication systems: sessions, JWTs, OAuth 2.0, and OpenID Connect.
Artículos Técnicos Relacionados
What Is a JSON Web Token (JWT)?
Direct definition and architectural breakdown of stateless token exchange.
JWT vs Session-Based Authentication: Architecture & Performance
Compare database session lookups with stateless JWT verification across scalability and revocation.
Troubleshooting: JWT Works in Postman but Fails in Browser
Diagnose and remediate CORS header stripping, HttpOnly cookie constraints, and preflight authorization failures.
Preguntas Relacionadas
Can a JWT Be Decrypted by Anyone?
Answer: Yes, standard JSON Web Tokens (JWS) are signed, not encrypted. Anyone can decode and inspect the payload without the secret key.
Why Shouldn't You Store JWTs in LocalStorage?
Answer: Storing tokens in localStorage exposes them to instant exfiltration by any Cross-Site Scripting (XSS) vulnerability.
Can an Expired JWT Token Still Be Verified?
Answer: Yes, the cryptographic signature remains mathematically valid, but compliant libraries reject the token because exp is checked after signature verification.
Laboratorios Prácticos de Diagnóstico
Continuar Aprendiendo
JWT Interactive Tampering & Validation Lab
Put your theoretical understanding into practice by tampering with claims and testing signature rejection in the live sandbox.