> This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it.
This refers to invalidating individual tokens. I've just updated the title and text in the post to clarify that.
> Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here.
Compared to storing something in a cookie. The article explicitly states that this concerns JWT tokens that are not stored in a cookie. And comparing "JWT vs. Cookies" makes absolutely no sense, they're different kinds of things.
> They take the same amount of storage than signed cookies, wuhu I use JWT so often and I NEVER exceeded the cookie limit, but I wouldn't store them there anyway.
Again - the article explicitly states that this refers to stateless tokens, ie. where the data is contained in the token itself. Did you actually read the full article, or just the headers?
> JWT is as secure as any other solution and this article proves it since he isn't well informed, he just throws a bunch of stuff out and tries to be "an expert". Btw. every other solution is really dangerous as well, especially Cookies could be a total mess of security problems. The same could actually happen with Bearer Tokens.
Personal attack and hand-wavy statements without ever actually addressing any specific security concerns. Take that elsewhere. I'm here for technical discussion, not for throwing shit.
> My toughts are use the thing your most happy with and the thing you understand
No, that is not how security works.
> and the thing you can implement with code that is totally clear and especially code that is really really easy to understand. And actually JWT will mostly win this battle.
No, it won't. The typical framework will only require you to load a single plugin to get sessions working, and literally nothing else. JWT tokens require manual handling.
> I've seen a lot of people just using Session Cookies from their Framework, but eventually have no idea about their risks, they have lots of CSRF all over the place
That is a separate problem, and you don't solve that by storing your session IDs differently and trying to sidestep it. You store it by actually mitigating the problem you are having, which means adding CSRF tokens.
That's the only actually secure solution to this problem - "manually handling sessions" and "secure session storage" are mutually exclusive, and automatically handling sessions will always be vulnerable to CSRF problems.
> or using a too small ID or eventually the ID is not really random.
Use a well-tested implementation - as, again, I have stated in my article - and this will not be a problem. Don't roll your own session implementation.
This refers to invalidating individual tokens. I've just updated the title and text in the post to clarify that.
> Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here.
Compared to storing something in a cookie. The article explicitly states that this concerns JWT tokens that are not stored in a cookie. And comparing "JWT vs. Cookies" makes absolutely no sense, they're different kinds of things.
> They take the same amount of storage than signed cookies, wuhu I use JWT so often and I NEVER exceeded the cookie limit, but I wouldn't store them there anyway.
Again - the article explicitly states that this refers to stateless tokens, ie. where the data is contained in the token itself. Did you actually read the full article, or just the headers?
> JWT is as secure as any other solution and this article proves it since he isn't well informed, he just throws a bunch of stuff out and tries to be "an expert". Btw. every other solution is really dangerous as well, especially Cookies could be a total mess of security problems. The same could actually happen with Bearer Tokens.
Personal attack and hand-wavy statements without ever actually addressing any specific security concerns. Take that elsewhere. I'm here for technical discussion, not for throwing shit.
> My toughts are use the thing your most happy with and the thing you understand
No, that is not how security works.
> and the thing you can implement with code that is totally clear and especially code that is really really easy to understand. And actually JWT will mostly win this battle.
No, it won't. The typical framework will only require you to load a single plugin to get sessions working, and literally nothing else. JWT tokens require manual handling.
> I've seen a lot of people just using Session Cookies from their Framework, but eventually have no idea about their risks, they have lots of CSRF all over the place
That is a separate problem, and you don't solve that by storing your session IDs differently and trying to sidestep it. You store it by actually mitigating the problem you are having, which means adding CSRF tokens.
That's the only actually secure solution to this problem - "manually handling sessions" and "secure session storage" are mutually exclusive, and automatically handling sessions will always be vulnerable to CSRF problems.
> or using a too small ID or eventually the ID is not really random.
Use a well-tested implementation - as, again, I have stated in my article - and this will not be a problem. Don't roll your own session implementation.