Ask HN: What's the current sentiment on JWT for stateless auth tokens ?, Hacker News

**************

********************

********

****************** be clear though you generally set the validity to be relatively short and refresh often, so that way you don’t have to worry too much; you can then “revoke” a token by refusing to refresh it.

**********

****************************

**********

But then it isn’t stateless, right? Because you need to know which current tokens are unrefreshable.
To me, JWT works great for things like physical people getting access to a physically isolated building, like a military research site that’s disconnected from the internet. Some secure other place holds the private key and signs the JWT token then you can wave in anywhere you need to go until the validity period is up. Then you have to go back to the secure place to get a new key, verifying the same way you did the first time and the secure place can broadcast its public key to the sites you want access to. It’s essentially a great mechanism where you don’t have constant communication links.

But I just don’t get it for servers. Also, everyone considering using a JWT token should know about the “algorithm none” setting and ensure that their stack isn’t vulnerable to it.

**********

****************

********

. **************

****************************** But then it isn’t stateless, right? Because you need to know which current tokens are unrefreshable.
You only have to involve state in 1 request every – 80 minutes upon refresh. All other requests can be done without having to check for revocation. This is a pretty nice real-world tradeoff.

**************************************

**************************

****************************************

********************************************

******************************

While I haven’t taken the leap to using a JWT in any of these cases yet and am a little bearish on them, I do also feel like the baby goes out with the bath-water, here.Nothing about adopting JWT says you can’t still use a full auth check for state-changing endpoints, and use a stateless session to shave some evaluation time off of frequent read-only requests for data that isn’t terribly sensitive.

You probably shouldn’t do it lightly or prematurely since it makes it harder to reason about authentication, but I think it’s worth considering whenever you’re optimizing.
************************

****************

****************************************

**************************************************************************

Actually creating a JWT token is not stateless, but at least your architecture is not centralized. If your auth server goes down, that’s a problem no matter what.
A common validity period is around 1 hour, which is good enough that most users won’t need to refresh very many times per day.

Also: you don’t necessarily need to track tokens that aren’t refreshable. A typical architecture might have a timestamp stored per user that specifies the earliest token creation date that’s valid for refresh. That way you can invalidate all tokens without needing to ever store them; something you might need to do for password reset, for example.

****************

always have to authenticate the JWT anyways to verify data hasn’t been changed. The stateless part is the fact that the sensitive data is stored in the JWT itself instead of retrieved from a DB. As long as you can validate the HMAC / Signature then you can assume the contents of the JWT haven’t been altered and can therefore trust the client’s data.**********************

******************************************************************

****************

******************

****************************

************ ******************** Why would you need to make a request to another server for this purpose?

Hint: you don’t – but I figure taking the Socratic approach may be more convincing.

************************

**********************************************************************

******************************************

********************************************************************

********

******************)
could pre share a public key, but a common way is to use the discovery mechanism in OIDC to automatically manage key distribution / rolling.

********************************************

**************************

****************

********
Don ‘t see the word “refresh” in there. Guessing they are assuming you use JWT identically to how you might use a session cookie, which is not how I’ve ever seen it used, personally.

**********************************************

************************************************

************************************************************

**********************

************

the diagram in the bottom right they seem to think you cannot revoke the long term token. I agree that it does not align with my understanding of whats capable with oauth2 style tokens, for example.

**********************************************

**************************************

box should probably read: “You can’t revoke the long-term tokensin a stateless manner, so supposing you truly manage ZERO state,then you’re back to square one. ”
That seems like the charitable interpretation. Note that the author’s point has notBeen that JWT is useless, but rather that trying to use stateless JWT for sessions is a bad idea.
If the point of Using for JWT was to avoid all server side state in authn / authz flow – which is the case for many, many developers, and that is the intended audience of the author’s post – then one of two things: you either contradict yourself and implement server Side revocation for refresh tokens, or you let the lifetime of your sessions be the same as the refresh token – and in the case of refresh tokens with no expiry, the user (or anyone with their refresh token) can stay logged in forever.

**************

****************************************************

For ******************** more secure apps we use single use tokens and expire within a very short period of issuance, ie invalidated upon use, and exp (expiry) set a few seconds after iat (issued at). Not optimum for performance because you need to get a new token with every request, but means you never have to worry about having to revoke them. Not heard of anyone in the finance sector using JWT for session management, but that’s not what they’re for.

**************

can revoke all JWTs by changing the signing key on your server. All previously issued JWTs will be invalid.

**********

**************************************************

So now every user has to log back in again every time you upgrade your server, simply changing the signing key or when your backend gets compromised.

Additionally JWEs don’t support forward-secrecy meaning that I can MITM and collect all JWEs passing through, find the key in your compromised backend and decrypt ALL these collected tokens.
No need to do this with JWTs since they’re unencrypted by default.

************************

**********************

****************

**********

Your server shouldn’t be getting compromised on a regular basis. The occasional black swan event occurs, and sometimes you have no other choice.

**********************************************

****************************************************************** [2] **************

Users get compromised though and will want to revoke sessions. But this is why you just set a time limit on your JWT, so that they can revoke and within N minutes the old sessions will die. Just keep N low.

**************************************

********

******************)

Sure , but that’s the nuclear option. Imagine if Facebook did that every time one account was compromised or they fired a staffer?

******************************************

****************

(******************

Facebook as the largest userbase of any application in existence. Its needs may not equate to your needs. For example, an enterprise b2b app with a few hundred customers could probably “deal with” the nuclear option.

******************

**************************************************************************************************

Man I’m not sure I agree with that. Blowing up a bunch of your clients that rely on your services randomly because one account was compromised is not acceptable for really any professional business regardless of the number of clients.
**********************

**************************************

**************************************************************************************************

********

****************** Blowing them up “is a mischaracterization of the situation. You are not mutating their data. You’re only asking them to login again.

[2]

******************

**************************

******************************

************************************************************************************

‘d be pretty upset if I got kicked out of a work app every time one of a few hundred companies fired someone (or even had to do a password reset for a security reason).

****************************

********************

issue is not remembering the password.

The issue is I just logged in 90 seconds ago, typed up a few paragraphs, and when I go to submit I have to do itagain, because someone in another company using the tool got phished and needs a new password.It’s frustrating enough when Gmail makes me put my password in after days and I just clicked into an email I wanted to read. Having it happen all day long would make me want to kill someone. (************************

******************************

******************************************************************************************

**************************************************************************

******************************************************************************************************

********

was not suggesting mutating the signing key multiple times per day or once per 80 seconds. At that point, you might as well just have a very early JWT expiration timestamp specified.

)**********************************************************************

******************************************************************

**********************

comment thread started with “if you need them to be revocable.” Any tool with “a few hundred [enterprise] customers” needs to be able to revoke access for terminated employees, compromised accounts, and the like, and those revocations will occur frequently and in many cases need to have immediate impact. (**********************************************

**********

**************************************************************

************** (******************

So wait, why does the refresh token not work? Why wouldn’t you verify user permissions when generating a new access token?

************************************************************************

**************************************

**************

******************** Remember that the author’s intended audience is developers who want to use JWTs specifically to avoid server side state in the authentication / authorization logic. The point is that, if you want to revoke the refresh token, you have to maintain a blacklist somewhere, and now you’ve contradicted your original goal of avoiding all state, which means that choosing JWT for this particular purpose was illogical, and probably warrants further thought. (TBC, in logic, if your hypothesis leads to a contradiction, then your hypothesis must be false, which is exactly what we’re seeing here in this scenario.)

**************************************************

********************************************************************************************

**************************************

****************

need a really short refresh cycle for that to be useful to customers. If your customer FooCorp fired Bob, they want to be able to disable his access immediately, not in 3 days when his access token next needs a refresh.

**********************************************

********************************************************************************************

********************************************************************

**************

****************************************************************************************************************

****************** If you keep using plain sessions you got a SPOF
What single point of failure is inherent with plain server side sessions and a session cookie ?

****************

********************

********

********************. .. ok so assuming you then don’t have a HA environment (Really! ?) if the server is down the sessions and the tokens are irrelevant because there’s nothing being served and nothing to use / check them and provide back resources.

**********************

************************

**********************************************************************************************

************************************************************************************

****************************************************************************************

my experience, don’t use JWT’s for carrying application state.

In more words, if you need to carry application state and you Haven’t outgrown the simple database cluster, then just use the tried and true formula of carrying state via SQL database. Pretty much every engineer these days understands how the architecture works, it’s fast and reliable due to the sheer maturity of the components involved, and you don’t add cryptography and maliciously crafted input attack surfaces to your auth system (see the recent talk at BlackHat about Outlook accepting unverified auth tokens). In this case using a predictable and mature approach is a good thing.

On the other hand, JWT’s work well for (1) federated authentication, though revocation is still hard, and (2) carrying authorization claims. The reason is that these aren’t state in the sense of application state. They’re attestations of an existing fact and you’re using the signature mechanism to let one service trust another without having to talk directly to each other or to protect any shared secrets. You need to send signed payloads containing user ID’s and lists of claims anyway, and JWT’s meet those requirements pretty well.

************************************************************************************

************************************************************************************** [2] **************

am fine with using JWT-alikes for bearer tokens. Good for one request or a very time-limited duration.
Some use cases:1) Sign In with Google gives your browser a time-limited JWT that it then provides to the application you’re trying to sign in to. The application’s server checks the validity of the token (without having to contact Google, except for daily key refreshes) and can upgrade that to a session for your browser using its normal session-management machinery. The idea is to transfer a piece of information between two systems (Google and the server app) through an untrusted system (your browser). For that, the JWT works well enough.

2) I wrote a proxy to convert one’s external SSO session cookie to a JWT internally. That ways apps can check the user without having to make any requests to a user service, and can propagate that safely to other backends. It was very time-limited (min (RPC deadline, global deadline) a few seconds of slop in both directions) and never exposed outside of an internal network.

Some anti-patterns:

You don’t want to store sessions in a database, so you store the state in a JWT that the user stores in their browser cache. This has the problem that you can’t revoke the token when the user is fired or gets hacked, which is a big problem. (You can of course add a database that only stores revocations … but you now have that check inside your request path, so you should have just done it the other way around and saved the user from having to send you a giant cookie on every request.)

**********************************************

****************************************************************************************************

**************

‘issuing date’ to the token, revoke all before a given issue date by a single date field in your auth table. Effectively clears all tokens. Would that work, if done up front?

**************************************

********
have to check this date on every request.
I think, on some level, you can make a revocation database scale better than a validity database. You store the revocation in some durable datastore. Then you have some service in front of this that calculates the entire set of revoked tokens, and pushes that to each auth gateway. Then the auth gateway can check if a token is revoked without putting any load on a database. It has to do this for every request, but you can scale the auth gateway horizontally rather easily.

(When an auth gateway starts, it gets a copy of the full revocation table again.)On some level, you do need the ability to push revocations to your auth server, because when you hit the kill switch on a session, you really want it to close all their open TCP connections (HTTP / 2, Websockets, SSH, etc.)Having said that, starting simple is the best approach. I used MySQL to store sessions at my last job. Every request went from Envoy ->ext_authz ->authentication / authorization service ->MySQL and this whole flow added only 1-3ms of latency per request. Someday you will hit scaling limits of using MySQL for this, but it’s a long way in the future. Do the simple and reliable thing first, then make it complicated later.

******************************

****************

************************

************

‘m bearish on JWTs in many cases for reasons enumerated here and elsewhere.
But I do use them in one place with a revocation scheme similar to this. On init, instances build an in-memory bitwise blacklist that token IDs are checked against.
This arrangement probably already implies this, but just in case: this is at a very small scale where the complexity of pushing revocations isn’t justifiable, power granted to the token-holder is limited and easy to clean up if misused, and revocations are so rare that restarting instances to update the blacklists is tolerable).

********************

****************

**************************

**********

****************** 1-3ms of latency per request.
Is that a big problem in practice? I always wonder about the tangible benefits of this approach.

**************************************

****************************

**********************************************************************************************************************

Yeah , I am quite OK with these numbers. The sessions-in-a-database-table is fast, simple, and accurate.

)************************************************************************************************

**************************************
************************************

Optimization if revocation is not common: – Keep a last revocation time somewhere that is cheap to frequently poll (Redis) or broadcast it to all your nodes – Keep a revocation table – Use iat and exp with your JWTs – On revocation update the table and the last revocation time. – On validation, only check the revocation table if iat

********************************************************************************************************

****************************************************************************************

******************************************************************************************

****************************************************************************************************************************

‘ve given up the benefits of a stateless token if you’re looking in the database to check it’s state all the time.

**********************************************************************************************

************************************************************************************

******************************************************************************************************************

**************************************

************************************************************************************************************************************************************

**************************************************************************************************

JWT helped me to achieve authentication and authorization without needing to make a trip to database on every API call. I use to store user role code in the token.
I kept the token expiry to an hour or two depending on the usecase. Added logic to client to refresh the token right before expiry of existing token. Otherwise, on token expiry, server returns and client can attempt to refresh token or send user to login page.

If there is a need of instant revocation, then I can maintain a list of revoked tokens for the duration of token life (1-2 hours) in cache layer. After 1-2 hours token will be expired anyway.

************************************** [2] **************

memory caches have scalable concerns and require sticky load balancer. You’d need to decentralize the cache (eg create a db for the session information) to allow horizontal scaling of services so this approach is generally considered old-school.

JWT has its own slew of problems, most of them are temporal (eg invalidation of all sessions), usability (eg short expiry), or additional security vectors (many poor JWT implementations, accidentally authenticating invalid tokens w / o signing, careless storage of readable values)

**************************************

****************************

****************

************************************************************************************************************************************************

hmm never had an issue with in memory caching and scalability (except in the old days of memcache). One can send a unique and hard to guess pair of identifiers and drop the lb stickiness. Anyway depends on the use case, but i feel like given the symptoms you describe there are a few other ways of doing it without jwt.

************************************** () ****************

************************************************************************************************************************************************************************

JWT are effectively that, a signed token that contains the session information.

You could build a session cache, either in memory or out of process, but it would still be more work than the token approach**************************

**************************************

(Typically) , before stuff like JWT was popular, you would store a session in the db and the session id in a cookie. Then you would hit the db each request to check if the session was valid.

() ************

************************************************************************************

**************************************************************************************************************************

******************

******

JOSE and COSE fill a void not filled by anything else on the market.
Sure, Branca may compare to just a JWT, but can it does compare to a JWS let alone JOSE.

If all you need is stateless auth tokens, use Branca or a good JWT library.
IMHO, the problem is the libraries, not the JOSE (JWS / JWE / JWK / JWT / JWA) standard. IMHO, after ~ 4 years there’s still no good Javascript or Go library for JOSE, but potentially a few good JWT focused libraries.

****************************************************************************************************************** (https://blog.zamicol.com/) ******************************************************************************************************************************************************************************************************************************************************************************************************* / / its -jose-not-jwt-pedantic-c …

************************

********************************************************************************************************************************************************************************

****************************************************************************************************************

************** (*******************

****************** why do you need stateless auth tokens?
So you aren’t hitting some validation server on every HTTP request to validate a token. Said validation server adds a very nasty point of failure & potential for page latency.

Going mostly stateless via JWT lets you balance the desire for fast token revocation times and load on your auth server. Even if your revocation time is a minute, meaning your clients need to refresh their token once every sixty seconds, that can still substantially lighten the load on your auth server. High security stuff can always validate the token on every request but stuff that does not matter as much can have a much more policy.

************************************************************************************

**********************************************************************************************************************************

**********************

Today I would still use alternatives like PASETO [0] or Branca [1] tokens which the latter is a fernet-like secure alternative to JWTs.

The problem with JWTs is that they are discouraged by many cryptographers due to their “cryptographic agility” and provide a mixture of protocols which includes weak ciphers and configurations to shoot the programmer in the foot. Why include insecure ciphers in the first place? The mentioned alternatives stick to a single cipher for its intended purpose. JWTs are inefficient for performance and are bloated in their data structure and have a performance hit when you parse the token to extract its properties compared with the same operation in other alternatives (simple session cookie require zero parsing and thus is faster).

And using them for sessions poses it own pitfalls [2] which you are better off with the alternatives or plain old session cookies.
They say that JWTs are “good when”. used right “but with those above footguns, that’s like saying C is safe when used right, rather than having safe defaults.

[0]https: //paseto.io/

**************************************************************************************************************************** (https://branca.io/) [2]http://cryto.net/~joepie / blog / 2019 / / 19 / stop-using-jwt-fo …(**************************************

**********

**********************************************************************************************************************************

**********************************************************************************************************************

************************************************************************************

********************************************************************************************************************************************

********

my experience, the idea that JWT is stateless is wrong. When your client log-out you will need to keep the token in a blacklist and check all requests against it to make sure it is not reused until it expires.

Since you need to keep a list of invalid tokens, it’s not easier to just use standard token. If what’s you like in JWT is the ability to store a payload that your backend gets back, you can keep that in your store alongside the token and read it at the same time you check the token is valid. IMO, JWT only makes sense when an other entity is doing the authentication of your clients.

**************

**************************

************************************************************************************************************************************************************************************

************************************************************************************

************************************************************************************************************************************************

******************)

cares what the current thinking is – define your problem and implement the solution that makes the most sense to you.
IMHO, the problems with JWT are overblown. Yes, people have made huge mistakes implementing JWTs, but the fault lies with the implementation not the standard.Stateless authentication tokens are always going to problems with revocation. There is always going to be a limit on how much you can cram into them. These problems are not unique to JWTs.

JWT has the advantage of being a standard with good support across languages. Other schemes might be slightly better at handling larger amounts of session data. Take your pick.

**********************

************************

**************************************************************************************************************************************************

**************

**************************

******************************

************************************************************************************************************************************************************

Some of the mistakes people commonly make – insecure ciphers, for example – should’ve been addressed (inin the standard.

************************************************************************************

******************************************************************************************************************************************

We need FIDO2 or some other standardized security key protocol in our devices.
I recently got an Apple Watch and having to just tap on my wrist to authenticate is amazing.

Would love to just be able to give a website one way to contact me and have it ping my device to authenticate with faceid, touchid, Windows hello, or an smart watch. (Basically, a magic link on steroids.

************************************************************************************************************************************************************************

************************************************************************************

**************************************************************************************************************************************** [2] **************

JWT bearer tokens have worked well in my experience, though I haven’t used PASETO. The main benefit is being able to use the same authentication mechanism for mobile and web apps.
The largest drawback is the inability to revoke tokens without giving up statelessness. Keeping a KV blacklist isn’t the end of the world, especially if expiration times for tokens are short. But at that point, the cost / benefit vs cookies sessions gets blurry.

Some general JWT tips: * Use a sufficiently long secret key if you’re using HMAC based signing ( https: // auth0.com/blog/brute-forcing-hs – is-possible-the-i …

)). * Use bearer tokens to avoid CSRF attack surfaces. (*********************** Avoid long (or non-existant) exp iration times.

************************

****************************************************************************************************************************************************************************

************************************************************************************

**************************************************************************************************************************************************

**********

**********************************************

JWTs aren’t just bad because they embody poor cryptographic engineering, but they are also bad because (stateless authentication) ******************************** in itself is poor security engineering for almost every application. (*********************>What solution would you choose today for stateless auth tokens?

Issue token (=random

************************************************************************************

****************************************************************************************************************************************************

************************

One ****************** of the secrity experts here at HN always recommends against it for auth. Go to the search box on HN and type “author: tptacek jwt”. Make sure you are searching within comments. You will see his multiple responses over the years.
I have mostly stuck to plain old server side sessions that are easy to revoke. If anyone is using Go, I highly recommend this library: (************************************************************************************************************************************************ (https://github.com/alexedwards/scs)
**********************

**************

****************** I have mostly stuck to plain old server side sessions that are easy to revoke.
But you have implicitly made a tradeoff. Your front-end infrastructure now has a very strong dependency on your auth server. Any minor hiccup in the auth system will blow up your downstream clients. Worse, in large sites you will be sending a ton of traffic to your auth server.

You’ve also introduced a source of latency to your page-load times as each request now needs to call the auth server to validate the token. Whatever the response time of the auth system now gets added to the front-end response time. Going with tokens that can be validated on the front-end system can dramatically lighten load on your auth system and reduce your front-end response time. The only major trade-off is you can’t kick somebody out instantly. The bad-actor can do whatever until the token expires – a knob you control. And even then, for shit that matters, you can always have the front-end server validate the auth token on each request anyway.

************************************************************************************

We use encrypted JWT tokens. I’m not sure it was the best choice, but it was the simplest for our needs.
Basically the developer is responsible for generating & distributing auth tokens for each device that they want to use our service.

This service is designed to fit into games and AR apps, so we didn’t want to force our own oauth flow on the end user. This way, the developer can generate a token on behalf of the end user, and distribute it how they see fit. (assuming one token per user, but it don; t overly matter, it’s still tied to their account.)

************************************************************************************

************

Frankly , I just went back to sessions.

Everyone thinks they’re building the next Facebook, but most of us aren’t gonna stress out even a single Redis instance.**********

**************************************************

************************************************************************************************************************************************************************

************** (****************************

********
Yea , I went back to sessions (with Redis) as well. So much simpler, since all of the major web frameworks / libraries have much better support for traditional sessions than JWT …
One place I still might use JWT is in service-to-service auth.

**************************************************************************************************************************************** [2]

************************************** ********** ******************** Because ****************** then you have all the headaches of JWT, without any of the benefits of stateless auth tokens.

(********************

************************************************************************************************************************************************ () ****************************************************************************************************************************************************

******************************************************************************************************************************************************

******************

see no reason to sign a session cookie that was issued by and will be validated against some authentication service. Especially if the cookie is sourced from a cryptographically-secure pseudorandom sequence of bytes which is sufficiently long to avoid collisions with other such sequences (eg

********************************************************************************************************************************************************************************************************************************************************************************************** (bits of entropy should typically do per session cookie).
) In my implementations of such schemes, I will typically feed the CSPRNG output with a time-based salt into SHA 256 or SHA in order to generate the final token, which is simply stored on both ends (user session db row on server & cookie on client). At this point, the server can simply 1: 1 the supplied client token with the row in the database to determine if the session is valid and which claims to return (or which are validated final server response to return as the case may be).
Advantages with using a token made out of pure entropy soup are that it’s consistent throughout the entire user’s session, and confers absolutely zero information regarding the nature of that session. Disadvantages are honestly unclear. I feel like JWT and other stateless schemes started as a bandaid to re-couple the authentication domains of disparate business services, but by way of the various clients.

********************

**************************************

****************************************************************************************************************************************************************************************

********

********************** property you use is known as an ephemeral session key and is a requirement for perfect forward secrecy. (Not being able to crack previous messages by compromising a key in the future)

() ************

**************************

. **************

can store data in the server-side session the user is never intended to see. If you want to store that in a JWT, you’re going to have to encrypt it, not just sign, and even that may clue them in that something’s going on – if you perform some potentially spammy act on a site and suddenly the JWT gets updated with a big encrypted block, you probably know you tripped some flag.

() ************

************************************************************************************

******************************************************************************************************************************************************************************

*****************
********

think there are two great options:

– (https://paseto.io

) ************************– http://macaroons.io

I use simple http only cookies with the following setup: (*********************************************************************************************************************************************************************************************** “cookie_name=cookie_value; Domain=sub.domain.com; Path=/; Secure; HttpOnly; SameSite=Strict; Max-Age=

This is valid for a year when you can decide if you want to renew it. Everything else stays on our end and we controll sessions, permissions, etc. Javascript (in theory) cannot access these cookies.

************** (****************

What makes macaroons great? I read the whole documentation and the macaroon.js docs. It seems to be under-documented, the library last updated 3 years ago. I couldn’t really grasp how the mechanism is safe re. clients adding “self-attenuations” that would amount to a DoS on the receiving service. Is anyone using this in production?********************

************** () ****************

********************************************************************************************************************************************************************************

**************************************************************************************************************************************************************************

are you sure you’re protected from CSRF from older browsers? There’s still plenty of IE going around on old desktops in libraries and such.

************************************************************************************

**************************************************************************************************************************************************************************************************

******************)

The biggest thing to worry about is a hash length extension attack. (https://blog.skullsecurity.org/) ********************************************************************************************************************************************************************************************************************************************************************************************************** / / everything-you-need-to-k …

This requires avoiding the use of a MAC hashing algorithm such as sha1 or even sha 320 Because it’s possible to append data and generate a valid signature from a previous oracle. Alternatively, you could use SHA2 to generate a – bit key and then truncate the key to or use an HMAC

**************************

**************************** (****************************************************************************************************************************************************************************************************** (***************** (******************************************************************************************************************************************************************************************************** (Read More)(**********************************************************************************************************************************************************************************************************