Note that we also had COVID and shifted to remote gigs in Germany. This means that we compete with people located in smaller cities or even villages which probably have a pretty good pay rate bump.
Sublime Text editor is my day-dreaming destination when I feel depressed of work. It makes me really happy that 2-3 people can actually build something, sell a piece of it in an non-disturbing way, and do this for a living.
It's also one of the best shareware models ( Is this even a word these days? ), that I've ever stumbled upon.
> which day to day tech workers working on internal B2B do not face
That's so true. Good luck explaining to management that the front-end app needs additional cloud resources, such as a server, so we are on the edge of the trend with SSR.
Most apps behind a login face tough architectural / security meetings, defending SSR for their use-case.
Wow. I hope this won’t spread further. Looking at DAX, Deutsche Bank shares dropped as well as HSBC.
When I first read the news, I thought about another hit for the crypto, however looking at what happens I’m a bit worried where will the avalanche reach next Monday.
Both DB and HSBC have an LCR of around 130% so in theory able to sustain a bank run (depending on the magnitude - I think LCR is calibrated on a post Lehman scenario).
Why wouldn't events like this reinforce the value of crypto as an alternative to traditional big bank big gov't currency? It's operated in a completely different way that isn't based on debt creation.
Raycast is an amazing tool, I use it everyday and have a few custom scripts to do stuff. Highly recommend.
It's super nice to press cmd + space and type a common thing I do without having to think. I use it to move windows around, switch from light/dark mode (frontend dev) switch focus between Firefox, terminal and IDEs, control Spotify, manage my Asana tasks, the list goes on :)
> Now it's really hard to argue with architects / developers why cookie authentication / bearer token makes more sense than JWTs.
Because that's a nonsensical argument? JWT is just a token + validation. Nothing more. You can use JWTs in cookie authentication, you can use them as bearer tokens. The only thing JWTs are doing is carrying a payload and signing it.
Now, if you want to talk about Oath2 or OIDC then maybe there's a different argument to be had.
> Now, if you want to talk about Oath2 or OIDC then maybe there's a different argument to be had.
I imagine that is the main argument. People use JWT because it's standardized on the authentication protocol... The same authentication protocols that are horrible in many more ways than simply using a bad token format.
Yet everybody jumped into them when Google commanded.
JWTs aren't for transmitting sensitive data or encrypting things. JWTs are about having claims that can't be forged by the client.
So why would you put a JWT in a cookie? To give the end user a set of claims that they can't change, they can only read and give back to the server. Those claims can include things like user id, or session id, or whatever you might imagine.
Now, could you accomplish the same thing with an encrypted cookie? Absolutely. I'm not arguing about what you can or can't do with stuff. But rather again commenters saying "JWT is such and such and forces so and so". It's nothing but a signed set of claims.
stop being snarky, there are RFC's describing JWS and JWE, people just use the term JWT generically and let the context dictate what they're actually referring to.
I did not know that encryption had made it in the JWT spec. My comment was supposed to convey surprise, not some sort of snark or sarcasm. I read the spec after the OP comment and learned something new today.
Because cookies can be set to HttpOnly, making them inaccessible to JavaScript. They're also automatically included in all requests, so if you want to download a file that requires authentication, you don't have to do some convoluted JavaScript trickery to accomplish it. It can just be a regular link.
I feel like the people who bash JWTs have never actually built a real-life application using them. Yes, there are footguns. But they are dead-simple to mitigate, and they are far from the only footguns in the world of web applications.
Yes, you can't fully "log out" without a centralized database. But who cares? A JWT in an HttpOnly and Secure (requires HTTPS) cookie is very well locked-down. I'm not worried about an attacker being able to retrieve it, because if they can then the client is pretty well owned at that point and the attacker can do whatever they want.
I deal with applications that run multiple instances. To support that, it would require either an affinity cookie to "stick" the session to a single instance (which could go down at any time based on load) or a centralized session database. I don't like either of those options, so I use JWT cookies.
Have a B2B product where you'll have, maybe, someday, and I'm exaggerating here, X00,000 DAUs? Just set up cookie auth and track the sessions in Redis. Session revocation is super-super simple and you'll easily be able to handle any security vendor questionnaire asking how you lock out terminated accounts.
I agree. Not enough critical thinking was happening when I saw devs start adopting JWT without clearly stating why, other than "current best practices is to use JWT... end of discussion".
My concerns with JWT from early on is that the data stored in them was potentially stale. Front-end developers would always request fresh data at each interaction. Second, the JWTs were so long. We had to keep passing these long JWTs around.... mainly for testing stuff out, we had long lived tokens, especially in dev, so I think we passed them around to replicate API calls. So you felt how long they were.... and in my head I kept thinking about all this useless data being passed around taking up CPU/network/memory resources. So I would just remove JWT and replace the tokens with UUIDs. Everyone was happy about it, but they were confused as to why they were needed in the first place. I would just respond with, well when you find out let me know and I can add them back.
Issue tokens that have a reasonably short TTL - say, half an hour - and let clients use their refresh token to obtain a new token after that. On refresh requests, ask the database whether the refresh token has been invalidated, if it is, return 403 (bonus points for checking the expiration date first and delete expired and invalidated tokens from the invalid-list).
This reduces the necessary database roundtrips, while still supporting a logout flow.
I'd actually argue that yes, that is acceptable for more businesses than you might think. We're talking about a session staying usable after logging out for 30 minutes in the worst case.
For this to be exploitable, you'll have to jump several other hoops, like accessing localStorage of another application, for example.
I'm not the person you replied to, but in most implementations I've seen - they don't. Front end or app is politely asked to delete the token to simulate the user logging out, but the token isn't revoked in any meaningful fashion.
No additional checks are performed on the back-end to verify whether the token has been revoked as that would reintroduce a round trip to the database you're trying to avoid in the first place.
Well, when dealing with OIDC / OAuth you can bind the tokens to the user session or trigger back channel logouts.
But anyways its not really easy to tell an RP to stop using a token.
No one - OP included - is arguing that there are no good use cases at all. Just that most situations don't call for it, and you're better off with something less complex.
As explained in the article, if that's the case then you can't really trust the JWT anymore only for it's cryptographic signature and you rely on an internal store entry that makes the token valid / invalid.
This makes no benefits as to bearer token or any random string that the server "knows" is a valid authenticated request via internal store, like a DB.
