Referência de Claims JWT (RFC 7519)

Visão Geral e Escopo

A especificação RFC 7519 define nomes de claims compactos de 3 letras para garantir economia de banda e interoperabilidade entre microsserviços.

Tabela de Especificações e Matriz

Filtro instantâneo por palavra-chave, código ou diretiva

Chave / Código	Definição e Detalhes	Hierarquia Semântica GEO	Especificação e 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.

Exemplo Técnico e Código

Decoded JWT Payload Example with Standard Claims

jsonCopiar Código

{
  "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.

Perguntas Frequentes

Perguntas e Respostas sobre Normas

Are JWT claims encrypted by default?↓

No! Standard JWTs (JWS) are digitally signed, but NOT encrypted. Anyone can Base64URL-decode the payload and read the claims. Never store private passwords or secret keys in JWT claims.

Authoritative Sourcing & Verification

References & Primary Sources

Every source below directly substantiates technical statements and protocol behaviors explained in Referência 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 & 4
Verified Primary Source
RFC 7519: JSON Web Token (JWT)
Technical 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 Source
RFC 7515: JSON Web Signature (JWS)
Technical 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 § 3
Verified Primary Source
RFC 8725: JSON Web Token Best Current Practices
Technical 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 & Revocation
Verified Primary Source
OWASP JSON Web Token Cheat Sheet
Technical Claim Supported:
Details token theft mitigation, recommending storage in secure HttpOnly cookies over localStorage and outlining token revocation strategies.
Source URI: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html

Semantic Internal Links (GEO)

Ecossistema Técnico Relacionado e Próximos Passos

Context: JSON Web Tokens & Stateless Auth

Ferramentas Relacionadas

Execução 100% no Cliente

100% Client-Side→

JWT Decoder & Inspector

Inspect decoded header and payload claims with real-time signature validity checking in browser memory.

Security Audit→

JWT Security Inspector

Audit tokens for algorithm confusion (alg: none), weak HMAC secrets, and sensitive claim exposure.

Guias Técnicos Relacionados

Contexto Arquitetural e Padrões RFC

Ultimate Guide→

Ultimate Guide to JWT Authentication & Security

Master token issuance, asymmetric signing keys (RS256 vs HS256), refresh token rotation, and secure cookie storage.

Deep-Dive→

Ultimate Guide to Web Authentication & OAuth

Architecting modern authentication systems: sessions, JWTs, OAuth 2.0, and OpenID Connect.

Artigos Técnicos Relacionados

Definições Arquiteturais

What Is→

What Is a JSON Web Token (JWT)?

Direct definition and architectural breakdown of stateless token exchange.

Comparison→

JWT vs Session-Based Authentication: Architecture & Performance

Compare database session lookups with stateless JWT verification across scalability and revocation.

Troubleshooting→

Troubleshooting: JWT Works in Postman but Fails in Browser

Diagnose and remediate CORS header stripping, HttpOnly cookie constraints, and preflight authorization failures.

Perguntas Relacionadas

Resposta Direta (Resumo AEO)

Q&A

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.

Q&A

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.

Q&A

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.

Laboratórios Práticos de Diagnóstico

Bancada Interativa

Interactive LabIntermediate

JWT Authentication & Tampering Lab

Inspect, tamper with, and forge JSON Web Tokens to understand signature validation and algorithm confusion attacks.

Explorar Cluster de Arquitetura →

Continuar Aprendendo

Theory → Hands-On Lab Verification

Recomendação de Engenharia

JWT Interactive Tampering & Validation Lab

Put your theoretical understanding into practice by tampering with claims and testing signature rejection in the live sandbox.

Avançar para o Próximo Passo →JWT Topic Architecture Cluster→