Lmst

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*)

#coding #nonsense

🔍 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)

jwt.io verifying the signature of my little toy token

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.

Header says what cryptographical algorithm is used for the signature, e. g. HMAC-SHA-256.
Body/payload contains info about a user (e. g.: id, isAdmin), that in case of a classical auth would be retrieved from a database on the server side.
{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

Seems a first step is almost done, adding #JSON support to my #poser lib. This could be the foundation for #JWT support in #swad. 😎

Need to do more thorough testing I guess, but at least the two example documents from #rfc8259 work fine ... the test tool does a full #deserialization / #serialization roundtrip (with specific internal representations of the data types supported by JSON).

edit: Look at the "Longitude" value of the second object in the second example 😏 I only noticed myself right now, but of course that's the desired behavior.

Testing JSON serialization in poser with the examples provided by RFC 8259

What's worse?

#AWS #JWT

@matuzalem He, thanks 😉

I still have doubts whether the server-side sessions might consume too much RAM on really really busy sites, this "lab test" with jmeter can only tell me there is a somewhat relevant need for RAM.

I already did some research on using #JWT (json web token) with #C, which would be the obvious choice for auth info NOT stored in a server-side session. It's a complex topic though, and I'd still need server-side state at least for rate-limiting (to make bruteforcing unfeasible)...

Would be great to have some numbers from the current version used on a "busy" site. 🙃

Discord Activity（Embeded Apps）でSupabaseを使う
https://qiita.com/mono0218/items/d2df926fa9dd3913590f?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #ハッカソン #JWT #discord #Hono #Supabse

Как я ушёл с Kotlin (Spring Boot) на Go (Gin) и сделал AI-чат с WebSocket и GPT-4

Меня зовут Артём, я занимаюсь коммерческой разработкой с 2019 года. Последние несколько лет я активно использовал Spring Boot для создания backend-сервисов на Java и Kotlin. Но в какой-то момент захотелось попробовать что-то новое. Не потому что Spring надоел, а просто чтобы выйти из зоны комфорта и узнать, как чувствует себя проект на другом языке. Я решил: возьму уже начатый pet-проект, перепишу его на Go — и посмотрю, как изменится подход, скорость разработки, ощущения.

https://habr.com/ru/articles/910122/

#go #gpt4 #websocket #docker #github_actions #petproject #jwt #kotlin

Good morning! ☕

Now that I can't find any other bugs in #swad any more, I'm thinking again about how I could improve it.

Would anyone consider deploying it on a busy site right now? Either as a replacement for #Anubis (proof-of-work against bots), or for simple non-federated #authentication, or maybe even both?

I'm currently not sure how well it would scale. The reason is the design with server-side sessions, which is simple and very light-weight "on the wire", but needs server-side RAM for each and every client. It's hard to guess how this would turn out on very busy sites.

So, I'm thinking about moving to a stateless design. The obvious technical choice for that would be to issue a signed #JWT (Json Web Token), just like Anubis does it as well. This would have a few consequences though:

* OpenSSL/LibreSSL would be a hard build dependency. Right now, it's only needed if the proof-of-work checker and/or TLS support is enabled.
* You'd need an X509 certificate in any case to operate swad, even without TLS, just for signing the JWTs.
* My current CSRF-protection would stop working (it's based on random tokens stored in the session). Probably not THAT bad, the login itself doesn't need it at all, and once logged in, the only action swad supports is logout, which then COULD be spoofed, but that's more an annoyance than a security threat... 🤔
* I would *still* need some server-side RAM for each and every client to implement the rate-limits for failed logins. At least, that's not as much RAM as currently.

Any thoughts? Should I work on going (almost) "stateless"?

[Перевод] Первые шаги в Spring Security с JWT

Команда Spring АйО перевела статью о работе с JWT в Spring Security с примерами и объяснениями. Прочитав данную статью, вы узнаете, как сделать первые шаги в создании приложения, в котором за безопасность отвечают токены JWT и фреймворк Spring Security, работающие в гармоничном тандеме.

https://habr.com/ru/companies/spring_aio/articles/909448/

#Java #Kotlin #Spring_Security #JWT #token #claim

If you are a SaaS product with SDKs that offer user authentication features (ie. allowing your customers to supply signed user JWTs to API requests), please also think about key material lifecycles and treat security as a firstclass citizen in your product. I don’t want to be forced to copy and paste my public keys into your UI manually. That’s not necessary, error prone and renders scheduled key rotations nearly impossible. JWKs are a great alternative! Thanks.

#jwt #jwk #authentication

Eight years ago, I wrote about the purpose of #jwt and it‘s still one of my most read articles. I was hoping that in the meantime everyone got the message 😅

https://www.jbspeakr.cc/purpose-jwt-stateless-authentication/