Hi if you loooking for good solution for extract data. I can recommend https://parserr.com/
Stop using JWT for sessions (2016)
91–100 of 255 posts
Re: Stop using JWT for sessions (2016)
#92Earlier quoted context omitted.
I would like to know what you mean. “Invalidating the client” seems almost nonsensical since you don’t control the client.
You do control what clients (think client_id/secret) can use your APIs. Don't you? You figure it out from there.
No. The discussion here is about using JWT for sessions with web clients.
If you’re registering a dedicated client id and secret for each web client, they you’re doing something wrong. If you’re doing this and then also using JWT, then you’re doing something really bizarre, and still wrong.
Id/secret pairs can make lots of sense for integrating partner services with your API. They make no sense for web clients, where you should be authing a user and not a client.
Re: Stop using JWT for sessions (2016)
#93From my time browsing HN, the consensus seems to be "don't use JWTs". What is the preferred method of client authentication for simple APIs these days?
HTTP basic authentication (of course over HTTPS)? Very simple to use and all the tools, such as curl, support it.
It is used even by fairly large scale services like Twilio[1].
Re: Stop using JWT for sessions (2016)
#94Earlier quoted context omitted.
I would like to know what you mean. “Invalidating the client” seems almost nonsensical since you don’t control the client.
You do control what clients (think client_id/secret) can use your APIs. Don't you? You figure it out from there.
No, you don't control the client. The attackers do.
Re: Stop using JWT for sessions (2016)
#95I mean look at the web page:
The fon't is so large, how could it be bad advice?
And look at how short that domain name is! AND IT ENDS IN IO WOW, the owner must be really important! And that logo, I mean come on - that was probably designed by 400 italian shoemakers 300 years ago waiting for the right technology to come around to stamp it on.
Sorry I just can't take your well reasoned arguments on a web page that has this large red banner and multiple bullet points. This was probably put up by just some guy right?
Re: Stop using JWT for sessions (2016)
#96Obviously written by a non-expert. Half of the claims here are false and he only references other blogs. OWASP is nowhere to be found.
> OWASP is nowhere to be found.
Is this satire?
Re: Stop using JWT for sessions (2016)
#97Earlier quoted context omitted.
How the heck did JWT get such a following with issues like these?
Because front-end engineers always fall for whatever cult is hyped right now. They usually don’t understand the issues around the things they want to build, they do it because it’s cool and new, and don’t stop to ask or research anything.
And backend engineers not researching how to properly implement them and completely missing the point, yet arguing and blaming front end devs for being "useless". /sarcasm
On a serious note: JWTs have use cases, but your company is probably not the one. Nice thing about JWT is that there is no need to query the DB every time a request hits a service. JWTs for session should be short lived and refreshed often. In case you need to invalidate it, you invalidate refresh token and window for attack becomes short. It's not perfect but it's certainly not useless and just the hype.
Re: Stop using JWT for sessions (2016)
#98Incorrect, these are not comparable things.
JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state.
You can absolutely use JWTs as the payload of your cookie. How you pass the session data back and forth is separate from how you encode the session data. Most web frameworks have their own token formats, but you can easily change them to be JWTs.
Using the Authorization header just means you're using a different header, and since it's not automatically sent then you don't have the CSRF issues with browsers, but now you have to manage it more manually in your client-side code.
Regardless of how you encode your tokens, if you want to do instant expiration or other live data lookup then of course you'll need to manage that on your server, whether it's a database, in-memory cache, or something else. The split between where state is managed is irrelevant to the physical transfer and encoding.
Re: Stop using JWT for sessions (2016)
#99We use JWT for validating simple handoffs from server to server, allowing someone to briefly access a resources such as downloading a file from a server designed to do that. We set the expiration to only an hour, and JWT is excellent for this use case as it means we don't need to implement our entire login and database workflow on a machine that just serves files.
Re: Stop using JWT for sessions (2016)
#100Can someone explain the Cookie vs LocalStorage thing? You can access cookies from Javascript, so how is localstorage worse? Assuming an attacker can execute arbitrary js in the browser (the model provided by the article). edit: Thanks for the answers - httponly, makes sense.
The author glosses over this but what they mean is that you can set the HttpOnly flag on cookies to prevent them from being accessed via JavaScript.
But is it still sent automatically on ajax requests by browsers?