The string 'JSON Web Token' doesn't appear anywhere on the web page. If you're going to use an acronym expand it out the first time you use it.
I expected this to be about Java Web Toolkit until I saw it was implemented in many languages.
JWT is Awesome
61–70 of 170 posts
Re: JWT is Awesome
#62Earlier quoted context omitted.
If you cryptographically sign the session cookie, as suggested in the video, then you accomplish the exact same thing as a JWT token - so, then why use JWT at all, if you going to look up the session data from the database in any case. 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.
depends on if need to call other apis like microservices, you can use the JWT on behalf of the user to request the contents from other services. JWT also introduces `scope` which determine services user consented and allowed your backend to call. These things are not supported by a simple session cookie.
I mean they're not supported OOB but you're just describing a session cookie with some signed metadata. If "the ecosystem" and interoperability with existing services is the goal then has the advantage.
If you're talking about something bespoke then it probably doesn't.
Re: JWT is Awesome
#63The string 'JSON Web Token' doesn't appear anywhere on the web page. If you're going to use an acronym expand it out the first time you use it.
Like JSON? I think for some acronyms, JSON and JWT included, those are their "proper" names, with the expanded name being just a curious historical note.
Then at least link the first instance to the Wikipedia page or something. After reading the first couple of paragraphs I had no idea what this article was about.
Re: JWT is Awesome
#64Earlier quoted context omitted.
depends on if need to call other apis like microservices, you can use the JWT on behalf of the user to request the contents from other services. JWT also introduces `scope` which determine services user consented and allowed your backend to call. These things are not supported by a simple session cookie.
That's precisely the use case for JWT I recently had to work with, where cookies are irrelevant. 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.
I mean is all this complexity really worth "I can send data to an untrusted client so that it can later send it back to me?" compared to just storing that data somewhere like Redis?
Re: JWT is Awesome
#65I would be interested in opinions on the approach taken by Laravel Airlock. It seems to be a hybrid approach between stateless auth and session.
Re: JWT is Awesome
#66Earlier quoted context omitted.
Judging from the number of stars of the various git repositories for different languages, there are a few people using it but not a whole lot. The most popular implementation seems to be php based. That suggest to me it's still early days for this. E.g. the Java implementation only has 13 stars, which is not a lot. Also it has a native dependency, which is not ideal. E.g. JWT has a pure Java implementation from oauth…
Popularity != value. Get over false signals.
Popularity definitely is value when designing APIs for public consumption. JWT has a concrete edge here. This is why I asked HN about their opinions on Paseto, if there's a chance it'll overtake JWT/JWE in popularity, then that makes it more suitable for APIs.
In the context of security, popularity has the added benefit that there's enough eyeballs, so all bugs are shallow.
Re: JWT is Awesome
#67The string 'JSON Web Token' doesn't appear anywhere on the web page. If you're going to use an acronym expand it out the first time you use it.
Like JSON? I think for some acronyms, JSON and JWT included, those are their "proper" names, with the expanded name being just a curious historical note.
I agree for JSON, not JWT.
Re: JWT is Awesome
#68https://news.ycombinator.com/item?id=21785888 tptacek 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 attenuation already). 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…
Just not Macaroons again :( 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 custo…
> - immature implementations, I'll just leave this here: https://github.com/nitram509/macaroons.js/blob/master/src/ma...
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);
enc_plaintext.fill(0);
Re: JWT is Awesome
#69would you secure api via JWT? Session token are not an option, basic auth can be an alternative.
I wouldn't call it a best-practice, but I've done this.
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.
Re: JWT is Awesome
#70Earlier quoted context omitted.
If you cryptographically sign the session cookie, as suggested in the video, then you accomplish the exact same thing as a JWT token - so, then why use JWT at all, if you going to look up the session data from the database in any case. 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.
depends on if need to call other apis like microservices, you can use the JWT on behalf of the user to request the contents from other services. JWT also introduces `scope` which determine services user consented and allowed your backend to call. These things are not supported by a simple session cookie.
Delegation via JWT replay downstream? Maybe, I guess, if those other services all have the same "aud(ience)" requirements, or don't bother checking audience. Probably not a design to hang one's hat on.