- to revoke a JWT you have to blacklist it in the database so it still requires a database call to check if it's valid.
- JWT are to prevent database calls but a regular request will still hit the database anyway.
- JWT are very large payloads passed around in every request taking up more bandwidth.
- If user is banned or becomes restricted then it still requires database calls to check the state of user.
- JWT spends CPU cycles verifying signature on every request.
- JWTs just aren't good as session tokens which is how a lot of web developers try to use them as. Use a session ID instead.
Where JWT works best:
- when a client can interact with multiple services and each service doesn't need to do a network request to verify (ie federated protocols like OpenID). The client verifies the user's identity via the 3rd party.
- as a 1 time use token that's short lived, such as for downloading files where user gets a token requested from auth server and then sends it to the download server.
Once you go down the path of checking a DB along side the JWT your design has gone off the rails. Either the expiry works for you or it doesn't. Don't try to "fix" it.
"Authentication takes a few minutes to replicate throughout our systems so a SLO request should be resolved within a few minutes". Stakeholder: Ok sounds good
It isn’t all or nothing.
The token includes the time when it was created (iat attribute) so critical actions could check that the token is less than 3 minutes old.
You still could blacklist, but realistically most areas don't need a dedicated revocation check. Some critical areas might, depending on the space.
For example, you can have a complicated authentication process where you require a password, 2FA, etc. These things help ensure that the user is that user. But once that process completes, it is replaced with access_token+refresh_token. Any user can take those item and impersonate that user. Attempts to lock this down require server-side state with the ability to revoke stolen tokens if detected.
Don't get me wrong, the same issues arise if you were using cookie-based session id's or the equivalent. But once you're doing this stateful token stuff, there appears to be a lot of additional complexity without a lot of additional benefit over the traditional way.
However, if you aren't worried about this level of security, there is clearly a benefit to using this newer style.
The blacklist is smaller than storing every token and not needed if you use a short expiration and refresh often.
> JWT are to prevent database calls but a regular request will still hit the database anyway.
It's one less query per request plus not all requests need the database immediately.
> JWT are very large payloads passed around in every request taking up more bandwidth.
They are 100~ bytes instead of 10~, not "very large".
> If user is banned or becomes restricted then it still requires database calls to check the state of user.
This is the blacklist you mentioned as the first reason.
> JWT spends CPU cycles verifying signature on every request
Pretty sure this is neglible. Similar to SSL requests.
> JWTs just aren't good for authentication which is how a lot of web developers try to use them as. Use a session ID instead.
Opinion. I weighed the pros and cons and JWTs are still worth it for my authentication use cases.
HTTPS, HMAC and asymmetric keys are battle tested and proven to work as well, that was one major point of the article.
I'm not sure you read the article because the points you are making were addressed.
For the size argument, you can use cbor instead of json.
(CBOR Web Token) CWT https://tools.ietf.org/html/rfc8392
But this video says all I have to say (2018):
1 sec takeaway (More in the video):
That said, JWT's are great for stuff like 2-Factor via email link or redirecting from one domain to another. Single use, which it was built for.
JWT was meant to be stateless, if it's not, then it's just a layer of unnecessary complexity with potential security and implementation flaws.
It's possible to add additional information in a JWT. And of course it's complexity that adds additional attack surface, but at least there is some kind of standardization around it.
Basically, Clients all used NTLM to talk to the main site, but the main site would use JWT to pass the authenticated user info to the other services being called. The signature ensured that you couldn't spoof, short of being an authorized user that could get an impersonate token for calling the APIs.
But the nice thing was it meant we didn't really have to hit the DB at all in any of this, and it was way cheaper to implement than an API gateway.
If you're talking about something bespoke then it probably doesn't.
Isn't that JWT?
The web server gets a token from the API server, then prepares a few JSON messages that the web client will send asynchronously with JS. Since each message content is signed, the web client can't tamper with what is sent to the API. JWT was perfect for this 3-tiers messaging.
If you work mainly in Java for example, you'll more often see JSESSIONID which are random string identifiers, referring to a database containing active tokens and user profiles.
However if you work in Python, you'll more often see objects. Typically something like a user identifier + creation date + random bits, that is encrypted with a symmetric key. It's usually encrypted, not signed, so yet another thing than signed tokens and random cookies.
Basically a bunch of endpoints can be put up, and if they use JWTs, it is easy to hit those endpoints from any type of app.
Cookies can of course be used, but that requires pulling cookie jars into native code. Perfectly do-able, but also super awkward and potentially error prone. e.g. I remember using apps on Windows that required me to clear my Internet Explorer cookies if the native app's auth got into a broken state!
(Things aren't that bad anymore)
JWTs are also nice because I can easily write services that authenticate to each other. I can have a service running on my backend that authenticates its limited access service account, gets a JWT, and goes and talks to another service. Could I pass around cookies? Sure, but it'd be more work and more complicated than "attach this JSON blob".
Cookies are nice if everything is browser based, but I'd argue that isn't the best way to build services.
(And finally, the amount of time I've spent debugging JWT issues < the amount of time I've spent debugging cookie issues!)
At that point why not just use JWT?
If my auth service provider already uses JWT (which it does), and all the platforms I am writing on have a provided library that consumes JWT (which they do), then why would I go with a custom header?
Also having uniformity of code patterns is nice.
My web service uses the same authentication scheme as my native apps. Heck my backend DB knows how to look JWT tokens and apply permissions correctly.
Our API knows that that organization's auth server is allowed to sign tokens, the third party frontends can obtain those tokens and send them to our API, and it works (or so I hope, I'm in the reading up on all this stuff phase). Sessions using regular cookies just don't.
It was easily implmeneted, easy to understand, secure by design and not open to any of those security issues because there was no magic lib which would have allowed for some downgrade attack.
And what did it actually solve? Session stickyness. Simple and easy.
Everything else isn’t JWT. Sure you can use it with OpenID/OAuth/whatever. Sure you can store them in cookies. Sure you can use them with or without sessions. But how is any of that related to JWT specifically?
One of the articles says with JWT I have to re-implement session management. Just use a different framework then. Sessions with cookies are also not magic.
Another article basically says you don’t need OAuth 2.0 with access tokens and refresh tokens. Very true. Also not about JWT.
I recon if the library you're using doesn't force you to pin the algorithm (or opt out of pinning), your foot is probably already full of bullet holes.
Disallowing the "none" algorithm is an important implementation detail, like, maybe your JWT library demands an environment value "JWT_ALLOW_UNSAFE_SIGNING_I_KNOW_WHAT_I_AM_DOING=1" or just doesn't support it in the first place. Maybe it was foolish to ever make any allowance for this in the first place.
Since JWT is used as a wrapper around data, it is possible that your needs will vary based on deployment scenario. In some cases, that data may need to be encrypted, in other cases only signed.
In some cases I may not need integrity protection/repudiation and am already sending over a mutually authenticated/encrypted channel. The implementations may not want signing to be forced on them, impacting their compute/data budgets - but they still want to write their standards to depend on a single data format.
In general there should not be a whitelist, but a precisely known strategy going into evaluation. This is because:
- unlike TLS, you likely have a relationship with the issuers
- unlike browsers, the different components are being validated against the domain
For JWKS-based distribution, that usually means that a key identifier maps to a specific issuer and to a specific validation strategy. If you supported CA-based trust models, that specific validation strategy should come from the certificates.
You shouldn't look at the public key data and decide based on the algorithm inside the JWT how to interpret it.
Because as critics rightfully point out, without any whitelisting, you can just specify that your JWT does not have a signature and then it’s a valid token, whatever the contents.
I'm also not a fan of "sessions" other than at the client, they tend to fail at scale.
RSA or ECDSA with NIST curves for signing things doesn't strike me as "great".
Support for ed25519 signature in current implementations is pretty poor.
For python I had to glue and stick python_jwt with cryptography primitives to do ed25519.
And the most funny thing: very few clients will understand these "standard" JWT tokens.
Credential attenuation in Macaroons is
cryptographic; it's in how the tokens
are constructed. I don't see the opportunity
for a DoS (that didn't exist without
Macaroons are a really lovely, tight,
purpose-built design that happens to
capture a lot of things you want out of
an API token, including some things that
JWTs don't express naturally despite
their kitchen-sink design.
JWT is more popular because there are
libraries for it in every language, and
people don't think of tokens as a cryptographic
design (or nobody would be using JWT!), they
think of them as a library ecosystem. JWT
is definitely the stronger library ecosystem!
This is also why I probably wouldn't ever
bother recommending PASETO. If you're sophisticated
enough to evaluate token formats based on their
intrinsic design, then you should implement
Macaroons if possible (it's almost always possible).
If you're not, then you're going to use JWT.
Macaroons have many small edge cases that'll bite you when you try to use them in practice:
- there is no spec and all people re-implement the de-facto standard. If you read the whitepaper it's not what's in use.
- the de-facto implementation is full of holes, e.g. time is expressed without timezone so it's not clear if it's UTC or not.
- the implementation requires custom parser for custom binary format but the caveats in wild use (remember: there are no standard ones) still use text so it just avoids the potential benefits of encoding dates and numbers in binary.
- the highly hyped third-party macaroons are barely supported in implementations in the wild - only one level is allowed and it's not specified anywhere.
- if we're talking about third-party macaroons there is another layer of problems: no standard for caveats means your third-party service needs to be closely coupled with your own.
- immature implementations, I'll just leave this here: https://github.com/nitram509/macaroons.js/blob/master/src/ma...
JWTs have many problems but compared to Macaroons it's just JSON and base64. This is available in all programming languages with no additional cost. JWTs also have actual spec that implementations can agree on. Macaroons promise you extreme power but doesn't deliver. Several of Macaroons issues could be resolved with some effort (e.g. standarization) others - like resolving cycles in third-party caveats are IMO design flaws deeply embedded in the format.
For more info from people deploying Macaroons in the wild see https://www.youtube.com/watch?v=MZFv62qz8RU
As for tptacek's recommendation this only serves as a reminder that even if a highly respected internet figure recommends you something you still need to do your own homework instead of blindly following.
Wow. In case the master changes, here’s the highlighted code:
/* XXX get some random bytes instead */
var enc_plaintext:Buffer = new Buffer(MacaroonsConstants.MACAROON_HASH_BYTES);
That's unlikely (last commit in the project is dated Apr 22, 2017). And it's another problem with "the Macaroons ecosystem". After initial hype people discover real world issues with Macaroons and abandon their pet projects.
But we are not on the same page about Macaroons and what makes them interesting. I do not care about interoperability and standardization (I do sometimes, but not here). Apart from things like OIDC, most of the JWT usage I see is internal to projects; they're used as a utility library to do utility crypto in HTTP APIs. In those scenarios, it doesn't matter whether "your" Macaroons are the same as mine.
What's interesting about Macaroons are the underlying design.
I'm honestly surprised to hear that anyone would go into a project with something like Macaroons and expect to fit into a pre-existing ecosystem of compatible Macaroon implementations, because, as the post says, they're not widely used.
I note that the logo depicts macarons , rather than macaroons .
A parent comment also mentions PASETO:
Sadly, a paseto does not appear to be any kind of biscuit.
The PASETO site links to this searing indictment of JWTs and related things:
I am far from qualified to evaluate any of these!
PASETO is by Paragon, the authors of said searing indictment.
IMHO their argument really comes down to a difference in opinion in how cryptography should be supplied to developers. TLS and JWT standards allow for a wide variety of cryptographic algorithms, and implementations may provide various ways to negotiate that set of algorithms, such as whitelisted set.
This provides for migration over time from legacy systems to new algorithms, but creates a risk that the library author will have a security issue in their implementation of the standard, or that the application developer will misconfigure said implementation.
The alternative strategy is something like NaCL/libsodium http://nacl.cr.yp.to, where experts standardize on single packages of algorithms (or extremely limited set, such as one standard and one legacy) to implement specific cryptographic primitives.
The problem usually quoted here is one of compatibility, migration, and experimentation. There are often no provisions for older systems which cannot handle one of the profiles involved, or primitives for managing non-standard cryptographic sets. Many of these specifications also dictate removal of an old algorithm set to add a new one - making the specification only really valid in lock-step upgraded systems.
Partly (largely?) my fault. When we wrote the Macaroons paper, I was simply not aware that Americans use the French word when referring to the French variety of macaroons.
I think pedantry in auth should be celebrated.
And conversely, "biscuit", which has the former meaning in the UK and means some sort of weird scone in the USA.
1. Tokens are typically stored in localStorage. (app becomes vulnerable to CSRF & XSS attacks).
2. Tokens can be stolen. Now this is generally controlled by having a very short expiration time.
3. Short expiration times mean persisting refresh tokens to do a silent refresh.
4. Blacklisting of tokens adds complexity and defeats the purpose of decentralising the auth workflow.
5. There's technically no logout. It's all done via very short expiration times. With multiple tabs open, logging out on one tab needs to be synced with rest of the tabs via some event listeners.
6. SSR rendered pages need to send along the latest refresh token cookie so that the browser can use it.
7. The refresh token is sent by the auth server to the client as an HttpOnly cookie to prevent XSS/CSRF.
My colleagues wrote a detailed guide which goes through these considerations - https://hasura.io/blog/best-practices-of-using-jwt-with-grap...
that's a problem with every site in general, which doesn't use any kind of event listeners.
Don't get me wrong, JWT it's not silver bullet nor it was meant to be one in first place. It's not session replacement, but there are places where right implementation makes lot of sense.
2. Same for any authentication header or token
3. I'm not sure I see the problem
4. See 3, don't do it, use shorter lived tokens with a refresh if necessary.
5, see 4
7. That is absolutely an option... usually, I forward back with the token on the hash, then the first thing the app does is use the history api to pull it out and remove it from visibility... it does appear for a brief moment, but like anything else, you'd see it in devtools anyway.
Unless you have some form of fingerprinting the client who authenticated and received the JWT.
Here's some trivia, the name comes from an italian drink from the 19th century named Fernet-Branca .
 - https://github.com/fernet/spec/blob/master/Spec.md
 - https://branca.io
 - https://github.com/paragonie/paseto/tree/master/docs/01-Prot...
 - https://en.wikipedia.org/wiki/Fernet-Branca
Had a sip of my fiancee's once, it tastes like someone mixed every soda from the soda fountain with every herb and spice in their spice rack, and then squeezed a healthy dollop of toothpaste in for good measure.
Anyone here got experience using Paseto in anger? (besides CiPHPerCoder who made it)
I would love a JWT-like thing that's equally common yet better designed. But especially when using it in public APIs and the likes, acceptance has to be pretty broad. Anyone got insights as to how mainstream Paseto is getting?
Okta's a pretty big name in authn/authz and their engineers recently published an open source PASETO implementation.
JWT has been out there for a few years and there are many uses of it that are fine. I've used it in the past and it was easy set up and get started with. The main criticism seems to be that users have too much wiggle room to do silly things like using alg=noneor that certain widely used algorithm combinations have some weaknesses. I guess that's valid but not a huge concern if you know what you are doing.
Paseto looks like it improves by narrowing down the choices to some sane choices, which is a valid approach. Of course IETF could update the relevant RFCs to use the same algorithms for JWT at some point.
It's worst when you're publishing an API and you need to support web clients, plus android, IOS and ideally not make things super difficult for customers using say, erlang.
As someone who used to regularly recommend things like "Use a high level / simplified library - try keyczar! Or crypto_box! etc" it has been disheartening to see how almost any even slightly niche choice will quickly devolve to developers having to pull in a bunch of dodgy looking objective-c code written say, 3 years ago by a single unknown developer.
It's usually worked out better from a whole-system perspective to stick with very widely supported standards (flawed as they are) and maintain a checklist of known footguns. It makes me sad.
Of course if your crypto is opaque to clients / not part of your integration surface then you've got a lot more wiggle room.
Perhaps what I've taken the long-winded route to getting to is, for anything where interop is important, I believe that popularity is absolutely valuable due to network effects and momentum.
- supporting public LAMP apps
- database servers that have public IP addresses that are barely filtered
- boxes not getting updates
- under-secured Linux boxes with almost every option recompiled to on
- chmod 777 developers
- substituting signatures of checksums for signatures of data
- not using HMAC and opening themselves up to length-extension and chosen plaintext attacks
- storing SSL/SSH private keys unencrypted on unencrypted laptops
- downloading HR data to a laptop and leaving it
I actually was fired once from a big name university in the SF Bay Area for refusing to haphazardly ruin the network security of a credit card processing private campus network to facilitate a new vendor remoting into terminals.
Integrity through awareness/caution, processes and standard components.
Bringing in a bunch of random dependencies, regardless of license or support status, is inviting all sorts of gaping attack surfaces.
In the context of security, popularity has the added benefit that there's enough eyeballs, so all bugs are shallow.
Every single company has no choice but to support JWT in some capacity. Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SAML but that's a different topic).
We'll see about that. :)
> Every single company has no choice but to support JWT in some capacity.
This will change soon.
> Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SAML but that's a different topic).
The plan for PASETO has always been to make it a JWT alternative for OIDC.
First comes the XChaCha RFC.
Second comes the PASETO RFC.
Finally, the OIDC-PASETO RFC.
If they agree it's a good idea, it should pick up quickly.
>> JSON Web Tokens are Often Misused
So is everything else. Name one programming concept which isn't often misused.
>> There were two ways to attack a standards-compliant JWS library to achieve trivial token forgery
The keyword here is "were" - Just like how people in Europe "were" dying from the Bubonic plague - It doesn't mean that Europe is unsafe today.
The up-to-date reality is that JWT today has been battle-tested to an extent that few other web standards have. In a way, all the negative attention due to past issues has made it stronger.
>> JSON Web Encryption is a Foot-Gun... this is somewhat like pointing a gun with 5 out of 6 loaded chambers directly at your foot
...And using session IDs inside a cookie is like eating a cookie laced with cyanide.
Forge this. For each session:
session_id = bin2hex(random_bytes(32))
* Why wrote your own format when JWT already has predefined keys. If you write your own encoding format instead of crappy JWT interoperability you have none and have to write everything from scratch
* If you're following API first using cookies for machine to machine API interactions is ridiculous (cookies are for browsers and humans)
* JWT being fairly standard plays nice with load balancer a/auth proxies/API gateways which can off load auth or even route it before hitting the application (database calls are expensive compared to in memory cached auth and you probably have an LB anyway)
I do agree that if you need the particular way of doing authentication that JWT is designed for, JWT is indeed a great implementation and can save you a lot of time.
Iterating on how invalidation work with OpenID Connect when in a point before the author said an authentication service which can go down is a single point of failure you should avoid. So he added a spof by using openid connect...
Anyway, there is always a single point of failure somewhere. There's got to be something that authenticates users and creates tokens in the first place.
Where JWT shines is when the auth service does not need to know the clients that might want to authenticate using it. A system where it can issue tokens to any other service on behalf of a user and say, "here you go, you can use this for the next N minutes". This is very useful when it's not practical for every service/client to "register" itself with the auth service before hand like oauth.
This is absurd -- the total amount of data I needed to store in the JWT was about 10 bytes.
This inefficiency bloats requests. At a time when we're migrating to http/2, which which deliberately reduces headers to speed things up, JWT is going in the other direction.
I've found that arbitrarily re-inventing the wheel because a new thing becomes popular should be done deliberately and with great caution. More generally - I think it's important to look for solutions to fit a specific problem, not problems to fit a specific solution.
However, back to JWTs - I'm currently using them for authorization in an EXTREMELY high traffic websocket server implementation. It's really nice because it's short duration (the ones I am issuing have a expiration of 60 seconds), and allows the service to operate entirely within memory except for interacting with a Kafka cluster.
Consider that host clocks are not always in sync (even NTP could leave 10 seconds of difference) and the many authentication redirections can take quite a bit of time for slow clients. Limiting tokens to 30 or even 60 seconds is asking for troubles.
But then again, I have to work with thousands of hosts, applications and datacenters, so I feel every edge cases. A single application on a single host would not.
I mostly use them in IOT voice enabled devices that get their time limited authorization to access popular voice services through such a token. Voice enabled devices suck, but that is not the fault of JWT. I think without JWT being that common already, we wouldn't have a situation where a devices need to sign requests against voice services and we would have additional security concerns.
It is a given that you can use a complete different token or other cookie mechanisms that work just as well. But I like them to provide at least some common ground. Even if there is valid criticism about the implementation.
Authentication != authorization should always be mentioned on the topic of JWT. And yes, they are often abused to do things beyond their intended scope. I would think this to be a user error.
And then you still have to use JWTs correctly which is very easy to screw up. OIDC has improved this situation somewhat, at the cost of another layer of even more complexity that’s easy to screw up.
Then you come to realize that JWT is basically pointless except for doing MFA (which you could probably have done with a random token).
cause issues down the lime.
sign in on www.example.com -> click visit www.example2.com while being logged onto accout based on example
That being said. Please do NOT use basic auth for anything in 2020. This is the worst anti-pattern one could do for authentication.
Basic auth simply transmits the username and passwords in clear text with every request. No application should be receiving username and password in clear text besides a single auth service. The passwords will get leaked all over the place between developers debugging, verbose logs, exceptions, etc... And unlike tokens that are meaningless and expire, textual passwords last forever and are extensively re-used by user across websites.
I guess my basic heuristic is that it's decent for an API that you expect to have very few consumers (internal, partnerships), but I would hesitate to recommend them for an API aiming for wide adoption.