41–50 of 135 posts
JWTs are useful, but there are a few things that are not immediately obvious. 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) I…
A possible alternative is to just make the JWT expiry very short; like one hour; then you don't really need to explicitly invalidate the token.
With a real time bidirectional transport like WebSockets, you can make the JWT expiry even shorter; like 10 minutes and you can auto refresh it by pushing a replacement token to clients every 8 minutes or so. If the expiry is so short, you don't need the ability to invalidate tokens.
Getting your laptop stolen while you are logged into a service which relies on JWT is like getting your credit card stolen; it will probably take at least 10 minutes for you call your bank to disable it.
JWTs are useful, but there are a few things that are not immediately obvious. 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) I…
> 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it Not a JWT expert but isn't this the point of a JWT or am I missing something. Sharing data between servers & clients while being able to make sure the data wasn't changed. > 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conf…
But yeah, if your server accepts JWT's, reject anything that doesn't use an algorithm from your whitelist, which usually contains just one entry.
https://security.stackexchange.com/questions/161734/why-does...
The token may as well just be an AUTENTICATION token, such as the app’s id with timestamp signed with the shared secret. (Or even better, an asymmetric private key, where the shared secret is replaced by TWO keypairs, one from app-to-platform and one from platform-to-app.)
Then you use this app id to look things up in an Access Control List (ACL).
Then stuff becomes easy. Forget all the oAuth crap. The app is just another user with an ID in your system. Users may grant access to other users, for different streams of data. The access can have various read/write/admin levels etc. It can be changed anytime. Finally, users can have LABELS (or Roles) which determine in one fell swoop what an app can do. That is similar to “scopes” in oAuth.
I don’t just talk about it — this is how we handle it in our platform:
This page doesn’t have any discussion of strategies for expiring JWT, one of the biggest security issues with this auth mechanism. Even the code sample doesn’t include an expiration.
The JWT has a built-in field called exp, which is the time the token is expired. This is built in. However if you need to 'expire' a JWT token early, there isn't a good way to do it. If your token has a JTI, then you could add a blacklist for that JTI (say in redis, with a TTL until the token's exp time). But that is left to the implementor.
Earlier quoted context omitted.
You can have unsigned, signed, or encrypted JWTs. You're correct that many JWT libraries only do signed tokens by default, but there's a whole spec devoted to encryption: https://tools.ietf.org/html/rfc7516 (whether or not your library of choice implements it is a separate question)
This is one of the things I truly appreciate about JWT. They made it a) easy and b) possible to do signing, encryption, or both. If you've ever taken a shot at learning the specs behind SAML, the simplicity of JWT is hugely refreshing.
Also, finding information and documentation on JWT and related technologies on-line is a lot easier.
I think that is probably thinking of time when you had to do everything yourself (host your own mysql server, create indexes, cache, etc). Now you can easily save your sessions using stuff like DynamoDb.. it costs almost nothing and read times are blazing fast even when there are millions of rows. Doesn't make a lot of sense to use JWT after this.
I think storing JWTs might make sense for some advanced scenarios where you have multiple services with varying security requirements but when you store JWTs, you lose a lot of the benefits of having a stateless token which doesn't require a database lookup. A possible alternative is to just make the JWT expiry very short; like one hour; then you don't really need to explicitly invalidate the token. With a real time…
There are other ways to pass claims -- like using bearer tokens in the HTTP header, or using OAuth 2. (All with TLS, of course)
This page doesn’t have any discussion of strategies for expiring JWT, one of the biggest security issues with this auth mechanism. Even the code sample doesn’t include an expiration.
The JWT has a built-in field called exp, which is the time the token is expired. This is built in. However if you need to 'expire' a JWT token early, there isn't a good way to do it. If your token has a JTI, then you could add a blacklist for that JTI (say in redis, with a TTL until the token's exp time). But that is left to the implementor.