#JWT: 'Attacking JWT using X509 Certificates': how an attacker could sign the JWT token with their own private key and modify the header value to specify their public key for signature verification:
#AppSec
#APIsecurity
https://trustedsec.com/blog/attacking-jwt-using-x509-certificates
Day 7
✅ 24 test suites, 153 tests passing.
Solid coverage across service and controller layers in my modular monorepo. Strict typing (TypeScript), full DTO validation, and realistic mocks across complex relations (TypeORM).
Next: fine-tuning error handling & exploring e2e strategies.
https://write.as/bmariusz/24-test-suites-153-tests-passing-scaling-confidence-with-every-assertion
#TypeScript #NestJS #Nextjs #InsuranceTech #Microservices #monorepo #rbac #codingdays #swagger #jwt #jwt_auth #programming
I've been working on and with #JWT in authorization and authentication contexts a lot recently.
This ecosystem is a mess, especially in the #javascript corner.
A significant portion of implementations don't even verify the tokens they get. They just presume it's from some trusted server. It's dead easy to forge that.
Then, many more do verify, but use libraries full of features. A self-signed jwt is valid and verified. But not from e.g. the auth server you expect.
1/3
Day 6
TL;DR: Groups, memberships, hierarchy — all dynamic now.
Released backend v0.3.0 🎉
✅ Users can belong to multiple groups with typed roles
✅ Groups can form hierarchical or overlapping structures
✅ Roles are normalized via reference types
Built with NestJS + TypeORM. Documented via Swagger.
https://write.as/bmariusz/building-a-flexible-group-structure-with-nestjs-and-typeorm
#TypeScript #NestJS #Nextjs #InsuranceTech #Microservices #monorepo #rbac #codingdays #swagger #jwt #jwt_auth #programming
Day 5
TL;DR: Continued work on backend security — role-based access is now fully wired up.
✅ Got fine-grained role-based access control fully working today.
• Roles loaded from PostgreSQL
• Injected into JWT during login
• Validated via custom `@Roles()` + `RolesGuard`
• Authenticated via `@UseGuards(JwtAuthGuard)` globally
• Introduced `@Public()` decorator to bypass guards for public endpoints
• Swagger supports Bearer token for testing
Took a while to get the role propagation into the token right — the key was enriching the `validateUser()` result, not just fetching data from DB.
Modular, clean, and no magic. Feels good. 👌
more on: https://write.as/bmariusz/continuation-securing-routes-with-jwt-and-role-based-access-control
#CloudNative #TypeScript #NestJS #Nextjs #InsuranceTech #Microservices #monorepo
#codingdays #swagger #jwt #jwt_auth #programming
Day 4
TL;DR: Full Swagger docs + JWT auth with registration and login are live.
Today’s work focused on two key improvements.
1. Swagger documentation was extended across all API layers. DTOs, entities, and controllers were enriched with `@ApiTags`, `@ApiOperation`, `@ApiResponse`, and detailed `@ApiBody` annotations — including real-life examples for request bodies.
2. JWT-based authentication was implemented. A secure registration flow was added, with password hashing via bcrypt. A login endpoint now issues access tokens containing user ID, email, and roles. All logic is encapsulated using Passport strategies (local and JWT). The next step will be protecting routes with guards and role-based access.
#CloudNative #TypeScript #NestJS #Nextjs #InsuranceTech #Microservices #monorepo
#codingdays #swagger #jwt #jwt_auth #programming
:ruby: Let's support kids.
By "kids", I of course mean support for Key IDs (kids) in JWT assertions (IETF rfc7515 JSON Web Signature - JWS compliant)
Of course, I also mean #FreePalestine, and #SayNoToGenocide
For a full writeup:
https://dev.to/galtzo/ann-oauth2-v2012-w-support-for-kids-57be
The Curious Case of the Tampered Token
https://myfear.substack.com/p/jwt-quarkus-murder-mystery
#Java #Quarkus #JWT #Security #Microprofile
Ah, yes, the riveting tale of JWT's "epic" decade-long #journey through the digital wilderness, where it single-handedly transformed the world of JSON-based tokens... or at least, that's what Mike wants us to believe. 🎉🔐 So, buckle up for another thrilling decade of self-congratulatory musings and cryptographic jargon. 🥳📜
https://self-issued.info/?p=2708 #JWT #DigitalTokens #CryptoCulture #JSONAdventure #HackerNews #ngated
Ten Years of JSON Web Token (JWT) and Preparing for the Future
https://self-issued.info/?p=2708
#HackerNews #JSONWebToken #JWT #TenYears #TechTrends #FuturePreparation
🚀 Triple drop this week:
🔍 Chapter 1 of my Docker security series is live. We break down namespaces, cgroups, OverlayFS and why isolation ≠ security.
🛠️ Meet Valeris: a Rust CLI tool that scans live Docker containers for misconfigurations like root users, leaked secrets, and dangerous mounts.
🔓 And in this week’s newsletter, we go deep into JWT hacking:
- alg: none
- RS256 ➝ HS256 confusion
- kid injection
- jwk abuse
- real-world CVEs and labs
📖 Blog: https://www.kayssel.com/post/docker-security-1/
🐙 Repo: https://github.com/rsgbengi/valeris
📬 Newsletter (JWTs): https://www.kayssel.com/newsletter/issue-6/
Learn. Break. Build. 💥
#cybersecurity #rustlang #docker #jwt #infosec #devsecops #opensource
Several years ago, I was working on our local #OIDC identity provider at work ... part of which was looking at a #JWT (JSON Web Token) quite frequently.
Now I implemented JWT myself (from the ground up in pure #C) for #swad to make it independent of sessions.
Well, dejavu here ... even back then, I always chuckled a bit how every JWT basically says "ey ... EY!" to me 🤪 🤡 (see it? *scnr*)
🔍 Vous cherchez une alternative open source à Postman ?
➡️ Testez Bruno, un client API local qui respecte votre vie privée, fonctionne sans cloud, et gère les JWT en toute simplicité.
J’ai fait une démo complète avec une API publique + une API sécurisée par token.
📺 Regardez ici : https://youtu.be/NSa6AYp8zA8
#DevTools #API #Bruno #Postman #OpenSource #PrivacyByDesign #JWT #RESTAPI
Cloudflare is hiring Principal Billing Systems Engineer
🔧 #golang #api #docker #jwt #kafka #kubernetes #mysql #postgresql #redis #sql #principalengineer
🌎 Remote
⏰ Full-time
🏢 Cloudflare
Job details https://jobsfordevelopers.com/jobs/principal-billing-systems-engineer-at-cloudflare-com-may-6-2025-50fd8b?utm_source=mastodon.world&utm_medium=social&utm_campaign=posting
#jobalert #jobsearch #hiring
More progress, I decoupled the challenge for the #Anubis-like proof-of-work checker from the #session. Again doing something slightly similar to what Anubis does: Instead of a completely random challenge, create it by hashing some data making it reproducible:
* an expiry timestamp
* the remote address (the real one obtained from proxy headers)
* the user-agent
* Accept, Accept-Language and Accept-Encoding
The challenge now expires after 2 minutes. The client has to post back the expiry timestamp so the exact same challenge can be reproduced for validation.
Still some work to do for making #swad "session-less". Next step, decouple the rate-limiter for failed logins, then finally move to storing all auth info in a signed #JWT.
This is going nice so far, I can now correctly sign my #JWT (using #LibreSSL of course, so OpenSSL/LibreSSL will probably be an unconditional dependency for #swad in the next release)
Doing some first experiments, here's how a #JWT for #swad might look like, containing a custom property that has the "auth info" that's currently stored in the server-side #session ... 🤔
Now add a JOSE header, base64-encode and sign that beast...
First step towards implementing #JWT in #swad done, just committed a good 1000 LOC and now my #poser lib can do #JSON 😎
https://github.com/Zirias/poser/commit/7f1772e85c869d544f8a12099ed6545e163dc163
Forgot to clarify:
People implement #JWT in literally any project, of any complexity and requirements, because their framework includes this feature, so why not.
It's a standardized, somewhat secure and maybe the only convenient way to generate SSO/OAuth tokens.
What I dislike (tl;dr of the post) is JSON in base64 and complexity of revocation.
Sometimes (most of the time?) you should just use random tokens.
Or at least your own binary format for data-containing tokens (it's not that hard to reserve one byte for system information and put it there, then fill the remaining 63 bytes, or whatever length you have, with randomness).
Upd: consider this to be a draft for a blog post. I was explained there actually are some usecases for JWT outside SSO. See also a tl;dr and some clarifications.
Classical authentication flow involves generating a random token on the backend, assigning it with a user account, sending it back as a cookie.
On every request, the server checks if a provided token is valid and who it is assigned to (who exactly sent the request).
They say searching for a token in a database is slow and inefficient, so they invented JSON Web Tokens and even promoted this standard to IETF and made JWT a "best practice", or at least very popular way of doing sessions.
It consists of header, payload and signature.
{base64(header)}.{base64(payload)} is signed with a secret key, known only to the server, to ensure later that the token is actually generated by this server (otherwise, a hacker could easily change isAdmin to true in his JWT payload) and finally we build a token: b64 of header json, dot, b64 of payload json, dot, b64 of signature.I already said about JSON-in-base64 in the post above. If you want urlsafe token, then do it urlsafe, without JSON. Why encode your plaintext multiple times.
The payload part can be decoded by anyone, and maybe you don't want an attacker to easily find out that a session belongs to an admin. Storing only ID inside of the body is clearly an overkill, you still need a database to know the user permissions.
The biggest problem with JWTs is revocation.
If a hacker steals our cookie, we can log out or click "terminate session". If it's a classical session cookie.
JWT is not stored on the server at all and the only check is signature verification. We can't somehow mark it revoked — a client already got a valid JWT with "revoked":false and it continues being valid as it was signed by the server with the same correct secret key.
Let's use JWTs with a short expiration time! Uhmm, no, it does nothing except annoying a user with a login form — an attacker could be quick enough to take a session, and logging out in your browser wouldn't invalidate the JWT.
Then maybe store a list of revoked JWTs anywhere? Yes. It's a common solution.
But remember why this kind of tokens was invented? Searching for a session in a database is a slow-ish operation, we don't want to do it.
So let's use Bloom filter. It's a space-efficient probabilistic data structure allowing to check whether an element is present in a set very quickly. Its performance comes with an accuracy trade-off: it can emit false positives — but not false negatives; so in our case the positive result means "JWT is probably revoked", the negative one is "JWT is definitely valid (if signature is OK)". When there's a probability that JWT is invalid, do a search in a hashmap / linear or binary search in a list / [other algo] in [whatever you use to store the revoked JWTs].
That's the mechanism used also by Mozilla's CRLite — TLS certificate revocation list compiled from all CAs' sources and built into Bloom filter space-efficient structure, regularly updated in browsers, performing the cert check locally (unlike OCSP, requiring an additional request for verification).
But, wait, don't lie to yourself, it's not a database-free token. We still need to store something somewhere, and even made the system extremely complex. Aren't classical auth tokens better?
I also wonder how much JWT's signature verification takes less or more CPU time than a PostgreSQL query to find a token. When awaiting I/O, we can do smth useful in parallel, but when performing cryptographic operations, CPU is busy.
Hey, I have a solution for storing and verifying session tokens. Use a Redis-like database (Valkey, Dragonfly, Redis) for fast lookup, or even something embedded (RocksDB, libmdbx?) to not deal with sockets and make it faster. Tokens are keys, user IDs or objects with user info are values.
#jwt #authentication #revocation #simplicity #performance #infosec