Encrypted Jwt
An encrypted jwt hides token claims from clients by wrapping the payload in JSON Web Encryption. You create one by encrypting the data with a shared key or a public key. Most engineering teams start with standard signed tokens to handle user logins across web apps. Anyone who grabs a signed token can base64 decode and read the JSON claims inside. When teams put sensitive roles or scopes into those claims, they switch to encryption. Still, broad roles inside an encrypted token still grant excessi
Jwt: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An encrypted jwt hides token claims from clients by wrapping the payload in JSON Web Encryption. You create one by encrypting the data with a shared key or a public key. Most engineering teams start with standard signed tokens to handle user logins across web apps. Anyone who grabs a signed token can base64 decode and read the JSON claims inside. When teams put sensitive roles or scopes into those claims, they switch to encryption. Still, broad roles inside an encrypted token still grant excessive permissions once the backend decrypts it.
How an encrypted jwt works in practice
Standard JSON Web Tokens only sign the payload to stop tampering. The JSON Web Encryption standard turns that readable text into ciphertext. When a user logs in, the identity provider builds the claims list. Next, it generates a random content encryption key for that single token. The system encrypts the claims with this random key using an authenticated cipher. Then, the provider encrypts that random key using the public key of the receiving service. It packages the header, encrypted key, initialization vector, ciphertext, and tag into five dot-separated parts.
When the backend app gets the request, it reverses this process. The app uses its private key to manage the content encryption key. Next, it checks the integrity tag to make sure no one changed the bytes. Finally, it decrypts the payload and reads the user claims and permissions. Teams often sign the token first and then encrypt the signed result. This nested step proves who made the token while keeping the contents secret.
Choosing keys and rotation workflows
Key management makes or breaks your token security setup. Asymmetric keys work best when one login server sends tokens to many backend apps. The login server holds the public keys, while each backend guards its own private key. Symmetric keys work well when the same app both creates and reads the token. Both methods need a clear plan for key rotation.
You should put a key identifier inside the public token header. When a backend gets a token, it reads the header to pick the right decryption key. During key rotation, the backend keeps both the old and new private keys active. Once all old tokens expire, you can delete the old key from the store. Keep token lifetimes short so compromised tokens expire within minutes.
Jwt: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What token encryption solves and what it misses
Encrypting your tokens solves privacy problems on the client side and across the network. Browsers, mobile apps, and network logs cannot read the user metadata inside the token. This stops attackers from mapping out internal role names, tenant identifiers, or user emails. It also keeps state data safe when you store session info on the client.
Still, an encrypted jwt only checks who logs in and hides the transit payload. Once the backend app decrypts the token, the user gets every permission tied to that role. The token cannot see or control what individual requests, queries, or commands do in flight. If an engineer or service holds a broad admin claim, they can run destructive actions. Token encryption also does not filter sensitive data coming back from the database. If a query returns customer emails, phone numbers, card numbers, or national IDs, the app sends them out. Teams need controls at the command level and data masking that rewrites matched fields in results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between JWS and JWE?
JWS signs the token so receivers know the sender and see that nobody changed the claims. Anyone can still decode and read a JWS payload. JWE encrypts the payload so only the holder of the private key can read the claims.
Should I sign and encrypt my token at the same time?
Yes, signing before encrypting is the safest pattern when the issuer and receiver are different systems. The encryption hides the payload, while the inner signature proves the identity provider created the token. If the same app creates and reads the token, authenticated encryption alone is enough.
Does an encrypted jwt replace TLS in transit?
No, you must still run TLS on every network call. Token encryption only protects the token string itself in browser storage or logs. TLS protects the rest of the HTTP request, including headers, URL paths, and request bodies.