[_sdegutis]

EDIT: I misunderstood what was meant by minting tokens, my entire comment is pointless. Save yourself the time.

What's the headache about minting tokens? You create a new uuid() on the server, store it in the DB in its own table which has references to accounts, keep an isValid field next to it for server-side invalidation, and store it in localStorage in the client. Is there a security flaw or something in this?

[blattimwind]

So you've minted a token, stored that in the DB as well, and every time you see that token you verify the signature and then you look the token up in your DB to see if it's still valid. You do realize that at that point you could've just handed out a random string instead and avoid (1) creating and verifying signatures and (2) the size inflation created by those signatures, because you're not even getting any of the theoretical advantages of minting tokens.

[ad_hominem]

If you're just handing out the random string without signing it (or performing some other constant-time comparison when validating), you're vulnerable to timing attacks

[_sdegutis]

It is a random string, I just created it with uuid(). Nothing was ever verified. Is minting tokens an official term that has to do with JWT? I thought it was just short-hand for the process I just described.

[blattimwind]

Minting tokens specifically refers to JWT-like constructions AKA "[probably-RSA-]signed cookies".

Generating a sufficiently (16-32 bytes) long string of randomness and using just that as a session ID stored in a database is a perfectly fine technique, scales well enough and is quite hard to get wrong.

[tebruno99]

When you hit a critical size your database can no longer handle the throughput of the lookups. You'll then install memcache or some other tech and the stack JUST FOR handling the tokens is a majority of your datacenter load.

Most startups and projects never hit this size, they usually fold before that level of growth. It is much lower than one would assume though since every request made to an API has to do the lookups etc.

[blattimwind]

> When you hit a critical size your database can no longer handle the throughput of the lookups.

If your data store(s) can't handle the load of looking up a ~32 byte token (that is, if you are sane and not using JWT), then how exactly are they supposed to hold up to whatever your business logic part of the app is doing?

[randomdata]

localStorage can be vulnerable to XSS attacks in cases where cookies are not.

[jondubois]

OMG, where do people get this info? It's BS.

As an attacker, if I have successfully injected my JavaScript code into your webpage, I can make HTTP requests on your server to do whatever I want with that user's account (their cookie containing their Session ID will automatically be attached to those malicious requests; so they will look like real requests from that user).

And yes, this attack also works with httpOnly cookies; I don't need to be able to read the cookie in order to use it.

The httpOnly flag is practically useless; I don't think any hacker worth their salt would want to steal session IDs for later use (session IDs and JWTs have a way of expiring quite quickly); usually with an XSS attack, you want to do the attack in-place from inside the victim's own browser.

[pram]

You can put a JWT in a cookie :V