What is a JWT and why you shouldn't store secrets inside it?
Published on 2026-10-20 by frfrand
JWT explicado desde cero: header, payload y firma, diferencias con cifrado, expiración y precauciones de seguridad.
A JWT is a token format that allows transporting claims or data between systems. Many applications use it to exchange information about sessions and permissions. The name comes from JSON Web Token.
The most important warning is this: a signed JWT is normally not encrypted. That it looks like an illegible string does not mean it is a safe place to store passwords.
The three parts that usually appear
A signed compact JWT usually contains three segments separated by dots:
encabezado.contenido.firmaThe header indicates information such as the algorithm. The content —or payload— carries claims known as claims. The signature allows verifying integrity and authenticity under certain conditions, if validated correctly.
The segments use representations that can be decoded. That is why a user identifier or an expiration date can be read without knowing a secret password.
What is it for?
Imagine that a user authenticates in an application. The server can issue a token that another component validates to recognize certain claims during its validity.
In some architectures that simplifies communication between services. In others, a traditional session maintained on the server is simpler and allows immediate revocation with fewer complications.
There is no obligation to use JWT just because you are developing a modern API.
What do exp, iss and aud mean?
exp is a common expiration claim, iss identifies the issuer, and aud indicates the intended audience.
A secure implementation does not limit itself to checking the signature. It must also verify which issuer is trusted, for which audience the token was issued, whether it has already expired, and whether the declared permissions are relevant to the operation.
A token valid for another API should not be able to be reused indiscriminately in yours.
Does JWT mean I don't need a database?
Not necessarily. Your application can still query permissions, account statuses, or resources. A user can lose access to a project before the received token expires.
If all authorization depends on outdated claims, you could allow actions that have already been revoked. The expiration policy and revocation mechanism must be designed with that risk in mind.
Where is the token stored in the browser?
It is a decision with trade-offs. Storing it in JavaScript-accessible storage can increase the impact of certain XSS attacks. Cookies with appropriate attributes can reduce certain risks, but CSRF, domain scope, and duration must also be considered.
There is no single answer without knowing the architecture. Avoid repeating recipes like "JWT always in localStorage" or "JWT always in cookies" without evaluating the threat model.
Common mistakes
Put secrets in the payload. If the token is not encrypted, that data is recoverable.
Accept unexpected algorithms or issuers. Validation must be strict and use a trusted configuration.
Use excessive expirations without revocation. If the token is leaked, it may allow access for longer than reasonable.
Confuse JWT with OAuth. One is a format; the other is an authorization framework. They can be used together, but they are not synonyms.
An example in ArduMaker
If an application hosted on a VPS managed from ArduMaker uses JWT tokens, the application server must validate them correctly and check permissions on each resource. Hosting does not automatically turn an insecure token into a trusted one.
To remember: the signature of a JWT helps verify its integrity, not to hide its content. Security depends on how it is issued, validated, stored, and revoked.
Sources: RFC 7519, JSON Web Token · JWT best practices in OWASP.