Slightly OT but why should I choose a JWT over creating some opaque token (random bytes) and storing that in a database mapping it to a user's ID?
It seems like people create short lived JWTs and then pass some opaque token to an auth endpoint to get a new JWT signed whenever the old one expires, or they store the JWTs in a database so that they can be revoked, making me question their usefulness.
Because people think their app will immediately scale to a billion users and their database is unable to service all those users. (It won't and the database can)
Alternatively, they have drank the microservice kool-aid and think that making a request to an AAA service every time the user wants to do something is just too much overhead (It isn't).
If you have a federated and perhaps also heterogeneous system then "Just use a database" isn't the easy option.
Think about all the people/organisations that emit tokens you trust, or trust tokens you emit. Would they fit in an elevator? A meeting room? A conference venue?
If the code that mints all your JWTs and the code that verifies them are two methods in a class running in the same service and maintained by the same team, that's a sign you probably didn't need JWTs and an opaque token was more likely what you should use.
I remain skeptical that JWTs are a good idea for the general case. People like them because you can do stateless auth, but if your database really can't handle a single PK-based lookup per request, I feel like you have other problems. And as you say, a lot of people end up storing them in a database somewhere anyway.
The way I've seen it work is with having short lived access tokens and a refresh token, with the refresh token being saved to a database so it can be revoked. I think the benefit over an opaque token is that you have data that can be verified to be true and then passed on to multiple places. E.g passed between microservices
> Slightly OT but why should I choose a JWT over creating some opaque token (random bytes) and storing that in a database mapping it to a user's ID?
To avoid the database lookup. Often you might want to hold some state, without the latency.
JWT is about your server being able to be stateless, whilst the client is stateful, which can speed up some... Irritating... Places of performance problems.
But you then lose the ability to revoke a token on the backend, given that requires a DB lookup. Or you have very short lived token, meaning that you don’t have real benefits versus an opaque token in DB.
IMHO JWTs only make sense in some constrained contexts, such as:
1. You want a report, click on “generate”
2. The processing starts, you receive a token to access the resource
3. Once the file is created you get can access it by using the token previously received
In those kind of short term and limited use cases they can make things a bit nicer as the “report generation service” only need to check the token.
But in practice JWTs are often used used as a general authentication/authorization mechanism, and that makes little sense (and brings a lot of overhead).
Yeah, the biggest problem I have with Debian is that they tend to take popcon statistics as evidence.
No corporate installation ever adds popcon. Nobody sensitive to their privacy adds popcon. It's a small, self-selected group, and massively overrepresents desktops and laptops at the cost of servers.
Main problem with telemetry. The reverse is also true. Software that has it enabled by default will just get data from noobs, because more technical users will disable it. (Looking at Firefox)
Mining with JavaScript or WebAssembly is no longer viable as being competitive now requires using a JIT compiler.
Nothing can really be done about it. Pool operators can ban the wallet addresses of known bot masters from connecting to their pool, but you can't really ban someone from participating in an anonymous decentralised network.
I use Gentoo Linux so it was as easy as putting the patches in a directory, and then rebuilding the kernel with the option to enable the synchronous cipher.
