3 ms·

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

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.

mikeryan 2y ago
It seems to me that if an attacker gets a JWT they also have the refresh token. No they don’t. JWTs can be used with third party services that should never see a refresh token. Those are the requests that should be presumed vulnerable.
- redwoolf 2y ago
  I’ve not come across such a use case as I’ve only ever written applications where we own both the service and the clients. Thanks for the explanation.
cryptonector 2y ago
> So how are JWTs inherently more insecure than other authentication methods? Almost all data passed over the wire nowadays is TLS encrypted. JWT's security -and that of all bearer token systems- depends utterly on the use of TLS. The security of JWT used correctly is comparable to that of Kerberos or PKI. There are some things to look out for, like that it's way way too easy to write implementations that fail open (e.g., you don't recognized a signature algorithm so you don't validate the signature but also fail to fail), but other than that there's nothing particularly bad about JWT. > Log out can be implemented in a user facing client by deleting the JWT and refresh token. Logout has to be implemented either by letting time pass w/o re-authenticating (i.e., let the session expire) or telling the server that you're logging out. You can login again, even with the same token as before (IFF it's not expired yet). There is no reason to have to "burn" a token, and that would add a significant amount of complexity akin to revocation. > 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. Sessions imply session state. What you probably meant is that if you want to revoke access then you need a revocation system, and that effectively bolts on extra state on your servers (and a pub/sub system). Generally no one wants that headache.

mikeryan 2y ago

It seems to me that if an attacker gets a JWT they also have the refresh token. No they don’t. JWTs can be used with third party services that should never see a refresh token. Those are the requests that should be presumed vulnerable.

redwoolf 2y ago
I’ve not come across such a use case as I’ve only ever written applications where we own both the service and the clients. Thanks for the explanation.

cryptonector 2y ago

> So how are JWTs inherently more insecure than other authentication methods? Almost all data passed over the wire nowadays is TLS encrypted. JWT's security -and that of all bearer token systems- depends utterly on the use of TLS. The security of JWT used correctly is comparable to that of Kerberos or PKI. There are some things to look out for, like that it's way way too easy to write implementations that fail open (e.g., you don't recognized a signature algorithm so you don't validate the signature but also fail to fail), but other than that there's nothing particularly bad about JWT. > Log out can be implemented in a user facing client by deleting the JWT and refresh token. Logout has to be implemented either by letting time pass w/o re-authenticating (i.e., let the session expire) or telling the server that you're logging out. You can login again, even with the same token as before (IFF it's not expired yet). There is no reason to have to "burn" a token, and that would add a significant amount of complexity akin to revocation. > 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. Sessions imply session state. What you probably meant is that if you want to revoke access then you need a revocation system, and that effectively bolts on extra state on your servers (and a pub/sub system). Generally no one wants that headache.