Should I use JWTs for authentication tokens?

"Just use the normal session mechanism that comes with your web framework and that you were using before someone told you that Google uses jwt. It has stood the test of time and is probably fine."

You don't need to be Facebook or Google to have more than one service in your infrastructure that needs to authenticate a user's existing session without forcing the user to log in again. Sharing the session across multiple services is its own distributed systems problem with numerous security implications to be aware of and bearer tokens might be a good alternative.

If all you have is a single monolith web app that is the identity provider, makes all authentication decisions etc then yes, you don't need JWTs probably. There is a huge gap between that and being Google/Facebook.

Apart from that, Google and Facebook don't even use JWTs between the browser and backends after the initial login but actually do have some sort of distributed session concept last time I checked.

Okay I'll bite...

This post doesn't seem to address microservice architectures at all? For me, this is the primary reason to use JWT's -- so you can pass authentication ("claims", or whatever you want to call them) through your chain of microservice service-to-service calls. If you don't have microservices then there's much less reason to use JWT's.

I'm not saying the article is a strawman exactly, but it does seem to miss the primary use case of JWT's. At least, the way I've used them in anger.

Also, the "JWT's can be insecure if you use the wrong library or configure them incorrectly" argument, while having some points, seems to me more of an argument that you should really do due diligence on any libraries you use for security. The better JWT libraries are not insecure by default.

I wouldn't use JWT's if I were making a monolith, but there are lots of companies who (for better or worse) use microservices.

JWT's are perfectly fine if you don't care about session revocation and their simplicity is an asset. They're easy to work with and lots of library code is available in pretty much any language. The validation mistakes of the past have at this point been rectified.

Not needing a DB connection to verify means you don't need to plumb a DB credentials or identity based auth into your service - simple.

Being able to decode it to see its contents really aids debugging, you don't need to look in the DB - simple.

If you have a lot of individual services which share the same auth system, you can manage logins into multiple apps and API's really easily.

That article seems to dislike JWT's, but they're just a tool. You can use them in a simple way that's good enough for you, or you can overengineer a JWT based authentication mechanism, in which case they're terrible. Whether or not to use them doesn't really depend on their nature, but rather, your approach.

External services use jwts pretty often, so if you have to handle jwts anyway, using jwts means that there's only one primitive, set of libraries, and concepts for your devs to know.

"You don't need all of that!" sure but you probably already have it somewhere in your codebase and it's pretty universal. You also probably don't utilize every feature of http itself, that isn't a cogent argument against using http.

JWTs are supported by a large number of tools, libraries, middleware appliances, etc; there's a huge ecosystem out there to support it.

You also might delegate auth to a third party like Auth0 or FusionAuth so that you don't handle any PII, because all of the PII is handled by a vendor, and you only store application-specific data.

"You want to implement logout" means a few things; in most apps you just ... have the client forget the token and you go about your day and it's fine. "but what about if a nefarious actor stole the token!!!" you might say, but hand-rolled session tokens have the same problem.

"You want to turn off access for all users" is something you can do in http middleware; e.g., I have used middleware that do things like "only allow through requests that have jwts with the 'admin' role in their claims because we have turned off the system from users for downtime", and that works fine. (specifically I wrote a traefik plugin to do this in an afternoon).

"You want to ban a single specific user really quickly" is a thing JWT won't do out of box.

Even running in smaller environments:

1) You may not want your application servers having direct access to your auth service or auth database. You may not have the resources to control employee access to sensitive data when it’s shared across services. You may want to spend limited resources for security audits on the systems that contain the most sensitive data, and having them separated from everything else is helpful.

2) Depending on what 3rd party services you use it may not even be practical to have connectivity between auth and other services, and if you do, the latency may be bad enough that you wouldn’t want it to be blocking every request. This is especially compelling for hybrid environments, e.g. the 20 year old database in a colo with your user data, and a new service being built for you by consultants on a PaaS.

3) People act like revocation is such a nightmare, but you only need the auth service to sign invalidation tokens to be passed to the client-facing services, and those services only need to retain them for the max TTL of the auth tokens, after which they can be evicted. Yes, that’s something that could be motivated by having a massive environment like Google, it could also just be a way to keep costs down when you’re paying by the byte of storage or by the outbound request on some cloud. You could try to make the argument that storing invalidation data is just as bad as storing session data, but the key questions are “Where?” and “For how long?”, and then in some circumstances it breaks down very quickly.

4) You may not want sensitive user data stored in the jurisdictions where you want to host your apps. That’s not a big company problem, it’s dependent on the nature of the services you provide.

Some people get entirely too dogmatic about their “XYZ is wrong, don’t do it!” beliefs. At the time I implemented JWT in our system, many years ago; it was the most straightforward way to solve the problems that I had. I read about the pitfalls and have yet to experience any of them. So in short.. “no regrats” from this heathen.

Here's the thing: neither Google, nor Facebook is using JWT for their access or refresh tokens. The only place they use JWT, as far as I know, is for the ID Token in their Open ID Connect Flow, since this is a mandatory (and terribly misguided) part of the spec.

I keep seeing the idea that JWT was designed for Google or Facebook scale being repeated over and over, but the reality is that neither company uses it. Last time I checked, both used rather short access and refresh tokens and it appears that at least the refresh token (if not both) is stateful.

Implementing stateful tokens on a global scale and sharing them across hundreds of service is HARD, but it's easier when you are Google or Facebook, and you've got enough resources to throw at this trouble.

And if you do need to implement a stateful token, you've got every reason to choose your own format. Your applications are using your own authentication libraries and infrastructure (e.g. API gateways), so you don't have to worry about complicating their life with a non-standard format. The upside for using your own stateless format is that you avoid all the design issues with JWT (alg=none, algorithm confusion, questionable support for outdated algorithms from the 1970s) and you can design a far more compact format that takes a fraction of the size of JWT[1].

There's a reason JWT got popular with scrappy startups, enterprises hobby projects and Udemy/Medium tutorial authors: they're very easy to spin up and library support is everywhere. I don't mean to say JWT is the right choice for any of these uses — it probably isn't. But it's the easy choice, the worse-is-better solution. The worse solution needs only be better in one respect to win: it should be easier to implement, copy and spread.

In the end of the day, JWT is not a good solution for either Google-scale companies or small startups. But it's the small startups that usually lack the resources and awareness to adopt another solution.

[1] https://fly.io/blog/api-tokens-a-tedious-survey/#protobuf

> By just using a “normal” opaque session token and storing it in the database, the same way Google does with the refresh token, and dropping all jwt authentication token nonsense.

Not only is this true, but most actual deployments of JWTs just have you swap a JWT (ID Token) for a opaque session token.

That said, I really like having a JWT signed by an IDP which states the user's identity because if designed correctly you only need to trust one party IDP. For instance Google (the IDP) is the ideal party to identify a gmail email address since you already have to trust them for this. I created OpenPubkey to leverage JWTs, while minimizing and in some cases removing trust.

OpenPubkey[0, 1] let's you turn JWTs bearer tokens into certificates. This lets you use digital signatures with ephemeral secrets.

[0]: https://github.com/openpubkey/openpubkey [1]: https://eprint.iacr.org/2023/296

I would add two pros of jwts (I guess oauth 2 and oidc more specifically)

1. It standardizes your auth system. While sessions auth is mostly implemented in the same way across systems, learning oauth and oidc gives you a standard across the industry.

2. Jwts give an easy path to make “front end” applications and api authentication work in the same way. This in theory reduces your security surface area as all of your authnz code can be shared across your offerings.

I typically use a service like AWS cognito (using their built-in hosted UI) to handle authentication for my apps. That gives me MFA, Google/Facebook login, email verification, etc for free and has a generous free tier.

I have a template that's backed by terraform and the authentication client is in lambda so the whole thing is serverless, self-contained and practically free. So I just run "terraform apply" and I have scalable auth for my new service.

https://github.com/alshdavid/template-cognito (only 1 dependency on AWS, everything else is stdlib)

If any service I create is lucky enough to break out of the free-tier and cost is an issue, then I can just move to another OAuth2/OIDC provider. The auth mechanism Cognito uses is just a specification meaning I am not coupled to any one service provider (though the user accounts themselves are). Cognito, Auth0, IdentifyServer, or whatever - I can migrate if cost becomes a problem.

The big issue with JWTs are that, if lost, they give permissions to attackers without revocability.

For this reason, I keep auth-tokens short lived and refresh them often. Refresh-tokens are revocable and live for a few days. This means that a lost auth-token is only harmful for a few minutes while a lost refresh token is only harmful until revoked or expired.

Tokens are stored as path-specific http-only cookies so the only vector for attack is if a user physically opens devtools and gives an attacker the token - or if the attacker has access to the computer (physically or via a malicious terminal script).

High risk operations (e.g. delete account, delete content, anything high risk) requires "step-up" authentication - so a user is asked to re-authenticate in those cases.

Overall, when you consider that rolling your own authentication comes with the liability associated with holding user data (companies must announce a breach to users, etc) - if a service provider like Cognito is compromised, you won't be liable or the only one affected.

JWTs have security concerns, but on balance, when used with third party provider, a sensible configuration and considering the risk of rolling your own - they are fine.

Browser sessions are not the only authentication scenario.

> absolutely no one who is not Google/Facebook needs to put up with the ensuing tradeoffs. If you process less than 10k requests per second, you’re not Google nor are you Facebook

What's the magic property that flips when you pass 10K requests per second? Are we sure it's at 10K requests per second, not 8K? or 5K? In general, at that kind of scale I'd think JWTs would become less appealing - AWS operates on IAM for example.

And why are Google and Facebook the best examples of companies who are operating at scale? There are different kinds of scale than just 'ad auctions per second'. I would imagine the access management concerns of, say, JP Morgan Chase are at least as complex and challenging to scale as those of Facebook.

We don't use JWTs because we think we're google scale, we use them because they're kinda cool. Cheap, stateless auth across services is really handy. If I rolled my own solution, it would just look like a shitty jwt.

There are definitely arguments to me made against ridiculous over-engineering, modern web dev has taken the problems of 1% of engineers and made them problems for 100% of engineers, but I think this is a bit of a silly one to focus on

Authentication is often the first thing I want to break out of the application and backend anyway. Good password hashing is expensive... Why should an entire application have to go down when your login is being DDoSed?

More so, A revocation list on something like Redis can expire with a token and a lot less expensive than an rdbms lookup with joins.

Not too mention, why add extra load with extra DB calls in the first place?

You don't have to be Google scale to want to separate logins from the main service. And that's just for starters.

The more confidently people make blanket pronouncements, the less you should believe them. There are a lot of use cases for OAuth2 and OIDC that are not covered by “just use a web session”.

The real thing to push back on is the logout requirement. Everyone pretends they need this, when what almost everyone should do is just mandate appropriately short token lifetimes and revoke refresh tokens as needed.

Since JWTs can't handle revocation on their own, the main benefit (other than the ability to do validation without a central authority) of JWTs over opaque tokens is the ability to embed data that an untrusted holder (ie client) can make use of. For example, attach the display name of the user and their avatar profile, so that even after the token expires the application can represent to the user who the token is (could be used for example to show a "Sign back in, Tom" view). This makes a Switch User feature very elegant to implement: the application need only store the signed authentication tokens, and those tokens are self describing.

Additionally, when using asymmetric validation, you can rely on JWTs as licenses: Your software can restrict offline features based on a locally stored token, simply by checking that the JWT was signed by the authority. In tandem with the ability to store metadata, your app (with code held by the untrusted user) can use the token to determine the user's license features without requiring an always on connection. (Obviously patching out the license checks is another matter)

These features can be layered on top of opaque tokens, but since a JWT has all the benefits of an opaque token (store the opaque token as a claim just like the rest of the metadata), it's actually a complete package that does it all without needing to roll it yourself.

You can implement a blocklist of all the revoked JWT and publish it to all servers. The list should be small, because only otherwise valid tokens need to be included. It becomes so much more complicated than a simple check-the-db setup though.

I don't think I would start with JWT if I did this again.

Some people made the distinction here, jwt on the front end vs the micro services across the network.

I've experienced more than once, issues where the auth service has bugs and the logged out session is still valid for a long time. Or an attacker that figured out the micro services blueprint and now had authed access to the entire network.

Jwt is still useful between services, however the front end can do just fine with a session id that can be easily revoked.

I keep reading criticism of JWTs that involves impersonation or replay attacks. With JWT (or non JWT bearer tokens) you use a refresh token. It seems to me that if an attacker gets a JWT they also have the refresh token. So how are JWTs inherently more insecure than other authentication methods? Almost all data passed over the wire nowadays is TLS encrypted.

In my projects, we have used encrypted JWTs and it seems to me a fine solution. Log out can be implemented in a user facing client by deleting the JWT and refresh token. Given a short enough expiration time, this is sufficient for most use cases involving user facing applications. Isn’t it? Generally, at least in the domains of the applications I’ve worked on, users only intend to log out of their current application when logging out. Meaning if they are signed in on their phone and on their desktop browser, when they sign out in the browser they don’t intend to also log out of their phone application.

The only downside I see is that if you want to log out of all sessions it is impossible to implement without maintaining session state in the server.

I'm unconvinced of the author's actual understanding of common JWT usage.

Suppose you use Azure. You may have one or more app registrations with defined roles as well as apis exposed within the Azure config. It's convenient to acquire an access token that can be sent to various apis, each of which can accept the token without having to worry about session state or really anything to do with authentication other than validating the token's legitimacy. If I wanted to roll my own security, maybe JWT isn't how I would choose to do it, but I definitely don't want to do that.

The article is just as wrong as articles that say you should use JWTs. They are both wrong because they lack context, at least in their opening. Interestingly, the article eventually does give context, but saying "it depends on what you need to do" apparently doesn't get as many clicks as starting by saying "no".

For the record, I use JWTs, I have hardly any scale at all. I have none of the requirements that would hit the database on each request. It works just fine and I didn't need to consult an article to tell me what to think because, and this is the crazy part I know, I'm able to break apart my business requirements and decide for myself what is needed (or not). JWTs work just fine in my case. YMMV.

A former student of mine (Vera Yaseneva) redesigned our old auth architecture using jwts and I’m pretty happy with how it turned out. Maybe it is overkill for our simple autograder server, but it was fun getting it to work and I’m sure it is more secure than the old architecture which had many many flaws… it was a maintenance nightmare for years. After the redesign it has been a breeze. Here is the project https://github.com/quickfeed/quickfeed

The security arch is mainly in web/auth and web/interceptor packages if anyone is interested in learning from the code. It uses connectrpc, which has a nice interceptor arch.

Happy to share Vera’s thesis report if anyone is interested…

So what’s “Facebook scale”? Is there an edge TPS number? Number of discrete major services? If you are consistently doing 10TPS on 3 services, sure. But many systems are bigger than that.

Everyone wants to be big. You can either frontload those problems, and risk drowning in irrelevant complexity, or defer them. The problem with deferring is that switching lanes appears like it will be expensive and time consuming.

The secret is that if you solve actual problems, rather than dreams and future hopes, the answers are almost always obvious. The work may be painful and people may be angry, but the rationale will be clear.

You should not use JWT if you have a single application in your organization. However, whenever you have multiple applications, you need some form of central authentication / authorization service. Otherwise, you would have to maintain auth databases in each application, each application will need to be logged-in separately, you won't be able to implement a simple "suspend a user's accounts after X unsuccessful auth attempt", you won't have a central auth log.

A big problem not addressed when not using a signature based authorization scheme is that you need to hit your database for every access attempt. This makes you much more susceptible to ddos attacks.

You need to be able to turn away malicious users as fast as possible. If you take the time to check a database first, that's a precious resource they can consume.

"Add a cache!", you might say? What if they use random client id and client secret for every request, how do you cache against that?

Oh man, he goes straight to stateful services as an alternative to JWTs. What an absolute nightmare, if JWTs are too hard stateful services are certainly more difficult.

So first of all, JWT is part of the OpenID Connect specification. So if you want to be either a service provider or identity provider for OIDC, you need to use JWTs as an authentication token in at least some cases.

Secondly, you don't have to hit the database on every request. Unless you have really strict security requirements, you can have a short expiration time on the jwt with a refresh mechanism, and then you only have to check the database say once every 5 minutes.

Related to the above point, the database you check for the "session" token isn't necessarily the same as the one used for other data used in the request, even if you are much smaller than Google or Facebook. It might not even ve the same type of database.

Finally, even if it makes sense to use a "traditional" session cookie for brower sessions, that probably doesn't make sense for an external API, where the client may not have persistent cookies at all, and there may not really be a concept of a session.

So as was mentioned in another comment, I think the answer to the title question is a solid "it depends".

Here I was hoping someone was using the James Webb Telescope to do some crazy authentication process that I never could have imagined. Was hoping something like the Cloudflare lava lamp wall, but much slower.

JWTs are rather convenient for API access, especially for APIs that are hit at high req/s rate, as they allow to decouple auth check and actual request processing. In more complicated cases you can use JWT subject for some simple preflight ACL checks as well.

While I could agree with the sentiment "consider using opaque auth tokens instead of JWTs in most use cases" I can't get behind the opinion-presented-as-factual-statement tone of the article. There are valid use cases to offload authentication to the client rather than verifying an opaque token with every request. One advantage is that community support for JWTs is large, but home-grown, ad-hoc opaque token solutions not so much. Another is that any claim at all can be stored in the JWT: IP address, user name, opaque token, whatever makes your app secure. While these same claims could be stored in a database, now you have extra overhead and maintenance dealing with them.

I would like to see an open-source project from this author that uses his proposed solution.

I'm thankful every day I don't have to work on a team where JWTs are a valid solution, and nobody suggests them regardless. What a nightmare.

“No.”

Whenever I see such a simple answer to a complex question, I know it’s probably an oversimplification.

The real answer is a solid “it depends on what you want to achieve.”

Say you handle invalidation by maintaining a cached table of revoked tokens. Is this table larger or smaller than the table of all users?

Perhaps you would like to embed some RBAC info in the token. Is validating both the token and it’s absence from your revocation table more efficient than looking up all of the other information?

Perhaps you need to do this on a distributed basis. Is the overhead of maintaining such a table more or less than making all the DB calls and creating a central choke point in your architecture?

Fair enough, access token/refresh token pairs all have those issues described in the article. But why hating against JWTs (pronounced 'JOT' btw) in general? There are other stateless techniques making use of a JWT, which are very easy and secure to implement. For examples the single auth token approach, with maybe a 2 days expiry and a renew window if the user is active. For some scenarios this is perfectly fine, it is stateless and has no refresh token. User logs out by just deleting the token client side.

Using JWT from Keycloak just to obtain a session cookie. Is this a common pattern or a smell?

Probably a waste of time to answer due to the long thread here. But short answer: you can store tokens in a server session which will manage it for you. In case you need to refresh it, you are redirected to the idp and get a refreshed token which again stored inside the session. So you can handle any "microservice" scenario as was called here, not sure why micro is important... Also, it is a misconseption that the tokens,as it where, are not stored on the oidc providing service. How are you going to logout someone or invalidate or simply track devices? It is going to be stored somewhere and there is nothing wrong with it. It is matter of scale, if you are not facebook the addition is miniscule, especially with distributed cache. Again, a misconseption it is not being used already, e.g. on keycloak if you want HA you have to enable distributed cache. So really naive thinking that session is bad or jwt is bad. They are simply tools used by protocols and the only question is usually what do you prefer unless you get to the edge cases of performance which unless you are facebook, my face would look daughtful to begin with if you raise this argument.

1. You can set JWT as cookie value, I think author is describing OAuth 2 problems, not JWT problems. Interestingly JWT is not mentioned in OAuth 2 spec [0].

2. JWT doesn't have to contain user details, it can be a simple reference token used for introspection [1]. This approach removes problems with invalidation and logout since identity service should store invalidated tokens.

3. JWT can contain refresh token id (or hash) and check for invalidated refresh tokens in (distributed) cache. Cache entry should not be long lived, and refresh token shouldn't be long lived if you are using proper refresh token rotation with family invalidation in case of a leak.

That being said cookies are still simplest and safest bet for simple monolith applications.

[0] https://datatracker.ietf.org/doc/html/rfc6749

[1] https://datatracker.ietf.org/doc/html/rfc7662

The JWT has some extra fluff for the client, but only the Bearer token is used for secure communication. And every call to an API validates the Bearer token with an identity service. There is no automatic security because you have a token. That Bearer token (not the JWT) must clearly be validated and also validated with whatever functionality (Claims) is potentially being requested.

The meta data in the JWT is sort of a short cut to let the front-end make assumptions, but it has no bearing on the actual capabilities. Only a valid Bearer token can determine if a call is secure (authenticated) and has the correct permissions (authorized).

So, you don't need a JWT, but without it, you're still going to need a way to send mundane meta data back to the front-end. This used to be (and still can be) a separate call for "config" or "permissions" data, but why bother. Just create claims in your identity server, mark your API's with those claims and token validation, and you're in great shape.

This article has a pretty narrow view of what uses a JWT can be put to. Yeah, in his limited examples, JWT is overengineered. And for non-distributed systems, JWT is overengineered. But there are plenty of use cases where JWT can simplify things and minimize complexity. Eg, when network connectivity is restricted and the consuming service cannot talk to the issuing service. Or when using a single token to auth against multiple remote systems. Or when latency is high between the central auth system and the consuming service. Or when you don’t have tight TTL/revocation concerns and you just want to auth once a day or week. Or when you just need a one-time token to establish some other service relationship. Or when you want to scope down permissions to subsets of what’s possible, or embed arbitrary auth metadata into the token, JWT has solutions for you.

But if you just think of this author’s narrow view of what system designs look like, then skip the JWT.

This is a bit nonsensical. Using the same logic regarding logout/revocation you would also be opposed to using Kerberos, say. So let's discuss the whole logout/revocation case.

In a typical Windows/AD or Unix installation you might have Kerberos (definitely in the Windows/AD case, possibly in the Unix case) and a directory (definitely in both cases, though in the Unix case it might be purely local), and you use the authentication system (Kerberos, say) in such a way that it allows you to elide some directory lookups on Windows/AD or not at all on Unix. Either way you get a worst-case latency for revocation of the user's service ticket's lifetime (Windows) or whatever you do to stop locked user processes (Unix). Well, that's the theory, but in practice many SSHv2/whatever implementations do not force session end at ticket expiration. So Windows/AD uses group policy for revocation. On the Unix side... we don't really have a standard solution, but essentially one can build a daemon that periodically looks for and kills processes running as now-locked users.

(For SSHv2, if you build re-authentication into a KEX, like GSS-KEX does, then you can force re-authentication and session end when authentication expires. In practice on Unix systems it's not really possible to elide a directory, so this is not necessary.)

Now for HTTPS apps it's a different story. You can use cookie expiration and force re-authentication so that revocation latency is bearer token lifetime, then keep bearer token lifetimes short. If you don't control the token issuer then you can still impose a shorter cookie lifetime in your app and demand a fresh token when you force re-authentication.

In any case, one does not need a revoked token/ticket/whatever list!

But it is true that bearer tokens don't completely elide the need for a directory for things like SSH logins onto hosts. But they do for HTTPS apps.

So I think TFA is just wrong.

I see a flaw in the argument. He shifted from saying you'd use a 5 minute access token timeout to querying the DB on every request. There can actually be a big difference between those two scenarios. Some web APIs can be bursty. Even caching credentials for 5 minutes could take significant load off the DB.

It’s a great analysis but I think it’s too either-or.

If you have a monolith anyways then yes, why use a distributed systems solution like JWT? Completely agree.

But if you already have an auth service, making it optional for the majority of requests is a distributed systems win. Even if you need to implement forced logout or some other features which require hitting the auth database, they can be optional requests. If the auth service is available, you get better security, otherwise the services can decide whether to continue or not.

This is better than your entire app going down or slowing down with the auth service. Though the refresh token bit is still a challenge, it’s a smaller one than a hard dependency on the auth service on every request.

Again, if your auth service is just a component in your monolith, the author is completely right. It’s context-specific.

The beauty of JWTs is that, if you have to ask "do I need JWTs?", you probably don't need JWTs.

At TableCheck we use JWTs to enable user logins across several sub-apps, using an auth service we built in-house using Elixir.

It’s a well-documented standard and we’ve never had an issue with them since launching.

The supposed drawback that sessions must live for X minutes, is just not a problem in practice.

Yes. I mean, no; you should use macaroons [1] instead, which are better than JWTs but are built on similar ideas.

[1]: https://fly.io/blog/macaroons-escalated-quickly/

Wrote a brief recap of "permission" and "login" for authentication from my work in JavaScript malwares.

It was a rush outline article with citations.

Large binning, salting of hash, and revocatable are my criteria.

Some toolkits that went out the window firstly are:

* auth0,

* Fusion auth, and

* Gluu.

So, some of the basic criteria are:

* User and password login instead of plain HTTP session cookies.

* HTTP-only over TLS v1.2+ (secured HTTP, HTTPS)

* ECDSA 1K or better

* SameSite [1]

* __Host prefix [1]

* preload HTTP Strict-Transport-Security header line [2]

* Bearer token supplied by API clients

* Don’t listen on port 80… like ever. Or revoke token if over non-port 443.

* DO NOT use JWT [3]

* DO NOT use CORS [4]

Hope the citations help more.

JWT, not recommended, IMHO.

https://egbert.net/blog/articles/authentication-for-api.html

JWT make the most sense for zero trust machine to machine authentication, where you might also want to authorize certain verbs/actions/roles after confirming the requester's identity. For example, I use a JWT-based authentication and role-based authorization scheme for a fleet of Raspberry Pis communicating with each other on a LAN or network overlay, and also with a multi-tenant API on a public internet-facing VM. The Pis manage 3D print jobs.

For users/people/apps, I usually rely on session-based authentication. Sometimes I need light RBAC at this layer too (users, teams, admins, etc).

I don't get why he is pretty sure everybody has only one database which stores user data and application data. At work we have user data in Keycloack and application data in at least 20 different databases.

I don’t think it is either-or type of choice. A lot, if not all arguments against that use of JWT disappear if you’re ok with compromise solution: user management actions will take time to propagate. If JWT lifetime is 5 mins, it means that all actions like logout, deactivating account etc will take 5 mins to finalize - and you’d be hitting the database exactly once per 5 mins for the purpose of checking if user is still active, refresh token is not barred by log out etc.

The article misses the point of JWT: it's dead simple to implement.

I don't implement JWT because I fancy big data terascale technologies. I do it because it's mostly stateless, meaning it's very easy to mock locally, and easy to deploy.

> You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request.

No, you just remove the JWT from the local storage. Sure, the user could then relogin if he copied it, but if it's on his own will, why not. And if he got his JWT stolen before logout, bah anyway any token could have been stolen that way, whatever the tech.

> You need to be able to block users entirely, so you check a “user active” flag in the database. You hit the database on each request.

Right but that contradicts the whole premise of the article, being that you probably don't need fancy features. 99.9% of websites don't need to ban users _instantly_. If you have a fair JWT expiration, it's usually OK.

I'd argue for the exact opposite of the article. If you want dead simple Auth, without fancy tech, just use JWT.

I worked in a backend team that introduced JWT, before I got there. The problem we had with JWT was that the data was stale. Even if it wasn't stale, it needed to be treated as stale because every service wanted the up to date data, even within 1 sec that data is old. The user could have changed something in their account from the time that the JWT was issued. I removed JWT and went back to the old UUIDs as tokens.

> In this setup the refresh token, not the authentication token, is the real session token

Yes, and why is that a problem? It is the best of both worlds as the verification of access token is standardized and fast while refresh token could be used at the first call of the session. Yes, it could happen that the user is logged in for 5 more minutes if the user is in middle of session, but it's really such a edge case which most companies don't need to worry about.

In general, a breadcrumb or cookie with symmetrically encrypted session UUID, epoch time, IP, and transaction counter is wise. You should also permute the servers hash salt with date daily to boot session campers.

If for some unknown reason the recovered client transaction counter losses its expected position, than you know someone has tampered with the session, and or stolen your clients session token.

Donate to the FOSS project of your choice if you find this useful. =3

Everyone’s talking about how you MUST hit the database for revocations / invalidations, and how it may defeat the purpose.

How is no one thinking of a mere pub-sub topic? Set the TTL on the topic to whatever your max JWT TTL is, make your applications subscribe to the beginning of the topic upon startup, problem solved.

You need to load up the certificates from configuration to verify the signatures anyways, it doesn’t cost any more to load up a Kafka consumer writing to a tiny map.

Yes if the JWT token can only become invalid based on an expiration time. You can add the expiration time in the token and check it during authentication.

No if the token can become invalid due to other reasons because lets say the user deletes the token because it got leaked. But since you have no way of invalidating the token other than changing the encryption key, you can't selectively invalidate that one token.

I personally love jwts. It's been suggested in other comments that you can just store tokens in a dB or something.

Why would I, I can just issue a jwt and move on, I don't need to store anything apart from a key to check it with.

And using jwts with nodejs (which I use most frequently) is a super simple and easy npm install, it's almost zero effort to use a jwt.

Start with usual session based authentication. Keep it until you see the absolute need to move to JWT. And make sure you understand JWT and "invalidating JWT" before using it - https://github.com/gitcommitshow/auth-jwt?tab=readme-ov-file...

I’d like to hear a reply from someone at Supabase

Nothing wrong with JWT bearer tokens as a technology.

However, too many times they're implemented incorrectly or without forethought. I've seen a few teams who used the bearer token, set the age really high, and never bothered to implement a refresh mechanism.

Fast forward a few months and someone says it is not possible to log someone out of our service.

I like the idea of using JWTs as opaque tokens. It sets you up nicely to migrate to using them semantically and there's very little downside (you just need a JWT library where the tokens are minted and then it's just string equality everywhere else) if you never actually end up using JWTs.

What about jwt's in a session cookie? I think the whole story needs more nuance. JWT's have many purposes.

Without JWT, how do you support log in using third party identity providers like Office 365, Google or Facebook?

I have used OAuth2 with and without JWTs as bearer tokens and pretty much used them the same way. JWT helps with fetching the user details without having to hit the DB/backend, and that's basically was the only difference to me.

I believe the issues he is describing is more OAuth2 rather than JWT.

While mignt not agreeing with all the reasons mentioned, verifying signature for every resource access is cpu intensive (your commercial compute provider would love you though). Comparing session id to a map is cheap. For me jwt to authenticate and random session token for resource access, problem solved

This post is not very good. JWTs exist for good reasons. They may not fit your needs, and if not, don't use them. But they exist to allow Entity A to tell Entities B through Z that A had authenticated the user and authorizes them without needing to make API calls, and they serve that purpose well.

Here is a quote from a comment in that article:

    I feel like this subject comes up every couple of months 
    with another iteration of why people think JWTs are bad.

The regularity which with this subject comes up makes me think of how Triplebyte used to pay off bloggers in the day to write posts with the title “hiring is broken”. I don’t have the proof but I am picking up a bad smell here.

Gotta be yet another of the vendors which is selling some authentication system that they host. I remember trying to promote an open source user management system in the early 2000s and nobody cared until they added killer feature “our service will get shut down when we get acquired” which somehow drew the pointy haired boss like a moth to a flame.

Isn’t JWT plaintext? Just remember your security controls

https://owasp.org/www-chapter-vancouver/assets/presentations...

Maybe it's irrelevant but for JWT to be passed as a Bearer in the header Authentication header, it needs to be accessible from the browser? Aren't httpOnly cookie safer in this regard? Or do we see set the JWT in the cookie too?

The main advantage of jwt is that is stateless, so it reduces load on database and or caching layer when checking user session. Alongside being able to share the public key to verify the token across different services

JWT is the simplest and most versatile authentication mechanism we have.

I have no idea why there is so much gaslighting about them. People keep pointing to implementation complexity, yet there exist proven, heavily used implementations for almost every language and engine imaginable. That issue is an issue of the past.

It is doubly ironic that people try to point to 'complexity' as an argument against them when most of them are addicted to over-engineered software stacks... JWTs are amazingly simple when compared to most other concepts in this industry.

The aversion towards JWT is weird. I used to think it's probably because some people got burned badly due to past implementation flaws and still hold a grudge... But the sheer persistence of the any-JWT movement leads me to think there may be an agenda behind it.

How could anyone possibly claim that keeping track of sessions on the back end and passing around session IDs is superior? It's way more expensive on the database/datastore, adds latency, it's hard to scale, you often end up with stale sessions because it's not fail-safe (e.g. how to clean up previously active sessions when a worker crashes? Especially if you have multiple workers.). Session IDs are MUCH more work.

I’m confused though. JWT isn’t hard to configure. Why not just use it?

My take on it is;

JWTs are good for server to server communication (short lived at ~5 minutes).

Sessions are for clients (browsers, apps, anything controlled by a person) to communicate with a server/api.

oof - this article is pushing bad advice - general disclaimer: use a third party authentication system like Okta or Cognito. It's going to save you so much grief down the road. They pretty much all use the same pattern (OIDC), so you just need to learn it once, and you're good for at least another decade. Authentication is one of the easiest and most important things to take off of your plate. Do it.

What if you want to use AzureAD or Auth0? Aren't those services completely built around jwts?

The article completely ignores single page applications where these JWT can be needed a lot.

It's the wrong question.

It's like asking what language should I use for programming a game? A common question, but of which the answer isn't a language choice. Instead it is that you approach the problem from the wrong direction.

The more useful question is what framework/service/library do I use for handling that, and then you use whatever it uses. Which most times means use whatever your web framework provides (as the blog author concluded).

The next question is what do you concretely hope to get from doing so and are there easier ways to get it (likely yes, and not some vague "but statles is better argument").

Then ask yourself how do you handle revocation? A question which is essential when using JWT and other stateless auth tokens (a answer of idk./I will think later about don't count. I don't can be a valid answer, but only very very rarely).

I think it's not an understatement to say that the huge majority of custom JWT usage falls under harmful premature optimization.

I wrote "custom" because sometimes you don't have a choice, e.g. you need to use OIDC for social login as the main form of AuthN & AuthZ and then already have some service (not just library) which fully handles OIDC/JWT including revocation for you (i.e. you don't validate the JWT stateless but ask the service every time). Through that approach (especially the later part) can have scaling limits but, eh, we are back at premature optimization ;)

JWT is not a protocol but kind of a message format from my perspective.

https://www.rfc-editor.org/rfc/rfc7519

It can be signed with HMAC SHA-256 algorithm: {"typ":"JWT", "alg":"HS256"}

Ripping off JWT from surrounding context is a road to hell.

It's worth to study JWT in context of OIDC (OpenID Connect) IDP providers.

You will quickly bump into buzzwords like client (RP), server (OP), PKCE, Token Exchange, mTLS and all kind of Implicit. Hybrid flows.

My biggest regret I didn't go through JWT related RFCs and OpenID Connect specs earlier.

[1]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFl... 3.1. Authentication using the Authorization Code Flow

[2]: https://openid.net/specs/openid-connect-core-1_0.html#Implic... 3.2. Authentication using the Implicit Flow

[3]: https://openid.net/specs/openid-connect-core-1_0.html#Hybrid... 3.3. Authentication using the Hybrid Flow

[4]: https://openid.net/specs/openid-connect-core-1_0.html#Client... 9. Client Authentication

[5]: https://openid.net/specs/openid-connect-core-1_0.html#Refres... 12. Using Refresh Tokens

[6]: https://openid.net/specs/openid-connect-discovery-1_0.html OpenID Connect Discovery 1.0 incorporating errata set 1

[7]: https://www.rfc-editor.org/rfc/rfc7523.html JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

[8]: https://www.rfc-editor.org/rfc/rfc7636.html Proof Key for Code Exchange by OAuth Public Clients

[9]: https://www.rfc-editor.org/rfc/rfc8693.html OAuth 2.0 Token Exchange

[10]: https://www.rfc-editor.org/rfc/rfc8628.html OAuth 2.0 Device Authorization Grant

[11]: https://www.rfc-editor.org/rfc/rfc8705.html OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens"

If you dont have patience for RFCs and specs, just go play with open sources IDP or better start from OpenID Connect client and server library, and try to integrate it into your "hellohell" app ;)

Very soon you will find out why developers keep building their own IDPs and how simple OpenID Connect can become a full time business

Go back here and here http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...

And reflect yourself

Trust nobody

Not to mention it's ridiculously easy to make JWT's insecure.

One huge benefit of random session tokens is also that you can't include arbitrary metadata that is sent to the client.

Decoding JWTs of web apps can give you a lot of suprises like the account email address or even password being stored inside them. For devs that don't know the difference between signing and encrypting JWTs are a footgun and even for those that do it can be confusing. The specifications are also a hard read. A handful of RFCs where you don't really know which one to lookup. JWT, JWK, JWE, JWA, WTF? It seems to do everything at once, signing and encryption, symmetric and asymmetric, and the format is always quite similar!

On the other side, if you are able to avoid the many pitfalls, JWTs can be very useful in the right place when used properly. You could probably write an equally or more secure JSON based token format from scratch without that much effort by just keeping it simple and restrictive/opinionated, though.

So then why does Auth0 use JWTs for everything..?

Off topic: the domain name is great!

The main claim of the article is:

> jwt as authentication tokens are constructed for Google/Facebook scale environments, and absolutely no one who is not Google/Facebook needs to put up with the ensuing tradeoffs.

The first sentence is factually incorrect. Google doesn't use JWT for most of its own authentication. Try analyzing their traffic - web and mobile apps - and you'll find that none of their 1st party applications / web use JWT. They do use JWT for OIDC, for third parties, which makes sense since with OIDC/JWT, third party sites can verify the token without talking to Google using a standard. This is largely similar for Facebook.

JWT RFC starts with:

> JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.

Notice "between two parties". Of course, nothing stops from a single party to use JWT, but claiming JWT was invented for "Google/Facebook scale environments" implying they are using it for their 1st party authentication is just factually wrong. JWT was always meant to be an information transport between two separate parties, like OIDC.

"Ensuing tradeoffs" here is essentially about stateless authentication vs stateful authentication, and even there, this "absolutely no one" is simply incorrect. There are many scenarios where stateless authentication is sufficient, even for the authentication for a single party (let alone between two separate parties). Not all applications and use cases require the security properties of stateful authentication - a sufficiently short expiration would provide sufficient security in many cases, making the loss of any security worth it for the added benefit of simplicity and reliability with the stateless authentication.

Now with more nitpick:

The article claims, since "denylist" would require a database read, it's equivalent to stateful authentication. Theoretically that's true. In practice, denylist has some nice properties, that makes it worthwhile if server-side logout is the only missing feature you need from JWT. Denylist is often very small - if most users of your application or service do not explicitly log out, the number of denylist will remain very small. With the expiration, the size can not grow indefinitely either. Thus, the denylist you maintain can be much smaller than the record of all stateful authentication - which makes it cheaper/easier to replicate / cache across your systems than the full authentication records. So "denylist" is definitely a legitimate design option, with slightly different trade-offs than a full stateful authentication.

---

If I re-interpret the main claim of the article in the way I think would make sense, it would be: services should prefer stateful authentication, and the cost of stateful authentication is lower than people imagine it to be. That I can be behind 100%. As written, the article is at best some big exaggeration with incorrect details and hidden assumptions.

Jwts are fine, just use them properly.

fine with me as long as you don't pronounce it "jay double-u tee"

no

> Now, let’s assume you are not Google. Check which of these apply to you:

> You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request.

A JWT is like a keycard. If a hotel gives you a keycard to access your room, the card itself holds the credentials which give you access to the room. That's the core principle behind JWT.

If you want to ban someone due to malicious conduct, then you need some kind of ban mechanism but this is a concern of spam prevention and attack mitigation. You need such mechanism regardless of what session mechanism you use. With JWT, you may need to do 1 lookup to check the account object (you can keep an isBanned flag on the account itself), with regular session IDs, you need 2 lookups (1 for the account object and 1 for the session object). JWT still saves you 1 lookup... Also, if gives you a lot of flexibility. For example, you may be able to keep a 'blacklist' in-memory and separate for each worker (that may be appropriate for certain use cases); you're not necessarily forced to hit a datastore or database as claimed. Banning and spam prevention should be seen as a separate concern.

Also, at small scale, there are scenarios where you don't even need a blacklist. Maybe your app is being served on an internal private network or maybe it's public but it's not so critical that you can't wait for 10 minutes or 1 hour (or whatever) for the JWT to expire for the ban to take effect. I mean, with the physical hotel scenario as an example; your keycard remains active until it expires. There are many such scenarios in the software industry where a ban doesn't need to take effect immediately.

When you need instant blocking for DDoS protection (where immediacy of the ban/block really matters), you typically rely on IPs, not specific account or session IDs.

> You need to be able to block users entirely, so you check a “user active” flag in the database. You hit the database on each request.

As above.

> You need additional relationships between the user object and other objects in the database. You hit the database on each request.

The number of times you hit the database (and the reason for each lookup) matters and it's important not to mix up different concerns.

> Your service does anything at all with data in the database. You hit the database on each request.

This is just a variation which has the same flaws as previous arguments.

The author claims that Session IDs provide:

> Greatly reduced complexity. No need to manage a secure jwt signing/authentication key

You can provide the auth key as an environment variable when you launch the service. This is well supported in all environments at any scale including Docker, Kubernetes... anyway, 99% of services rely on various secrets like API keys so you need to pass secrets as env vars anyway, what's the issue with having just one more env var to hold the JWT signing auth key? There is no added complexity there as the mechanism for handling such secrets already exists in most applications. It's rare to see an application which doesn't have secret API keys... You need them for payments (e.g. Stripe API), for database API services (e.g. MongoDB cloud), Amazon AWS, etc...

On the other hand, managing sessions on the back end requires weird workarounds like setting and constantly refreshing expiries on the session keys or running complex cleanup cron jobs because you end up with complicated situations where your worker might crash and leave behind stale sessions. Session IDs are much more complicated.

Not to mention that session lookups becomes a single point of failure and can become a bottleneck for your application as you get more users. It's really difficult to scale well. You're going to run a Redis cluster just to manage sessions? Hello LATENCY!!! Welcome DDoS headache!!! Did anyone say backpressure issues??? How are you going to clean up stale sessions when a worker crashes? Good luck.

I hope you're billing for your development work by the hour, coz you're gonna need a lot of those! I hope your health insurer covers Panadol! Don't be surprised when GlaxoSmithKline opens up a new factory next to your office.