We use JWT in a localstore and a cookie that stores a JWT (two different systems). Tip for library for validating JWT: https://github.com/sikt-no/clj-jwt (shameless plug? I am involved in that project.)

You should stick to the lowest surface area that satisfies your needs. I'd go out on a limb and say that as much as 90% of all websites can work without any issues with the simplest session based cookies.

If you have a database and don't have distributed web services or thirdparty auth, then session cookies are the way to go. Use a 128-bit random number (be sure to set -Djava.security.egd=file:/dev/urandom) as a session ID , store it in a secure cookie on the client side and in a session table in your DB using that very number as its primary key. That's it, job done. At least, when it comes to sessions themselves - you still need password hashing and validation and most likely other somewhat tangential things, like CSRF tokens.

I enjoyed this http://fly.io blog post last time I had the same question: https://fly.io/blog/api-tokens-a-tedious-survey/

Ah, glad the author of the article and I agree on the matter. :)

Oh, wait - it's by tptacek. Of course we agree - I've gotten most of my auth knowledge by reading his articles and comments, lol.

Session based cookies, JWT?Both. Short lived JWTs and a session cookie for renewing said JWT (JWT with everything pinned though so there's no negotiation involved)

Just in case you missed it, I explicitly wrote that we're in agreement. :) And no, my goal is not to argue against everything. When someone says "you should use X", I expect them to be able to know accurately and precisely why I should be using X. Especially when the crux of the original question is about auth in web apps, without any additional requirements whatsoever.

And just in case that article by Thomas Ptacek (an actual professional security researcher, not some random guy on the internet, with experience in his domain almost as long as my life) got lost in all our chit-chat (sorry, folks), I'll let myself quote the most relevant part: > Frankly, the biggest knock against simple random tokens is that they’re boring. If you can get away with using them — and most applications can — you probably should. Give yourself permission by saying you’re doing it for security reasons. Security is a problem for all the fancy tokens [...] That's exactly what my point has been in this thread. And he has no money in saying that.

Thanks guys for sharing your experience on this topic :hugging_face: And I am sorry the arguments heated up a little bit.

Very interesting discussion 🙂 one more point about random tokens: would you store them directly or would you store a hash of the token? the reason is the same as for passwords: on a db leak an attacker could get access to all user accounts

Quoting https://news.ycombinator.com/item?id=16006394: > We hash passwords because passwords are valuable across sites; it's a big deal to compromise someone's password, even on a random low-value application. That's not true of API keys. If your database is compromised, the API keys don't matter anymore. Don't bother encrypting them. > You also won't find any advice to encrypt session IDs on the OWASP website. What is advised on this matter is to re-require pwd auth before doing sensitive things and timing sessions out.

You can use tools.build (https://clojure.org/guides/tools_build#_mixed_java_clojure_build) to compile the java code before the clojure code. You can also use something to orchestrate the tasks, like babashka tasks (https://book.babashka.org/#tasks) or make.