Jwt Types
You choose between two main jwt types by picking either signed tokens or encrypted tokens. Signed tokens prove who sent the data, while encrypted tokens hide the data from readers. Most engineering teams start with signed tokens to log users into an app. They store user roles and group names right inside the token body. When teams make these roles too broad, one stolen token gives full admin power. A user with a broad token can run any command across your back-end systems. How the core jwt typ
Types: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You choose between two main jwt types by picking either signed tokens or encrypted tokens. Signed tokens prove who sent the data, while encrypted tokens hide the data from readers. Most engineering teams start with signed tokens to log users into an app. They store user roles and group names right inside the token body. When teams make these roles too broad, one stolen token gives full admin power. A user with a broad token can run any command across your back-end systems.
How the core jwt types work in practice
The JSON Web Token standard splits into two main formats for different security needs. The first format is a JSON Web Signature, which most teams call a signed token. A signed token has three parts separated by dots in a plain text string. The first part tells the app which math rule created the signature. The second part holds the claims, such as the user ID and role name. The third part is the digital signature created with a secret key. Any person or app with the token can decode and read the claims. The signature only proves that no one changed those claims after login.
The second format is a JSON Web Encryption token, also known as an encrypted token. An encrypted token has five parts separated by dots and hides the inner text. The sender locks the token content with a shared key or a public key. Only the system holding the matching private key can manage and read the claims. Teams use this format when the token carries private data across public networks.
How teams use token roles and where gaps remain
Beyond cryptographic formats, teams also split tokens by how the app uses them. Identity tokens prove that a user logged in through a central provider. Access tokens tell a back-end service which API routes a user can call. Refresh tokens stay on the client device to ask for new tokens when old ones expire. This setup works well to control who can log into an app.
Still, token claims only check permissions at the moment a session starts. Once an engineer or app holds a valid token, the back end trusts every request. Standard tokens cannot see what specific database queries or shell commands run in flight. If a token grants read rights to a database, the user can pull every row by default. The token itself cannot rewrite emails, phone numbers, card numbers, or national IDs in results. It also cannot pause a dangerous delete command to ask a manager for approval.
Types: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Choosing the right token setup for your team
Pick signed tokens when your back-end services only need to check user roles fast. Make sure you never put secrets, passwords, or private user fields inside a signed token. Keep the expiration time short so a leaked token stops working within minutes. Store your signing keys in a safe key manager and rotate them on a schedule.
Pick encrypted tokens when the token must pass through untrusted client apps or browsers. Use them if you must include sensitive claims that outside systems should not read. Keep in mind that encrypted tokens take more CPU time to lock and manage. Even with strong encryption, always pair your token checks with strict action controls on the server.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between JWS and JWE?
A JWS token signs data so you can verify the sender, but anyone can read it. A JWE token encrypts the payload so only the key holder can read the claims.
Can users read the data inside a standard signed token?
Yes, the body of a signed token uses basic text encoding, not encryption. Anyone who copies the token string can decode it and read every claim inside.
How long should an access token stay valid?
Most teams set access tokens to expire in five to fifteen minutes. Short lifetimes limit the damage if an attacker steals a token from a user device.