I have nothing to add to the existing conversation; other than to say this was a very thought-provoking post and follow-up set of comments. If nothing else, it has given me pause to stop and think about something that I may have just used blindly in the past. That said, I'm all-for session cookies. I always felt like JWT was solving a problem that I didn't have (I currently use session cookies to reference a server-side cache).
I'm with you Ben. But I do have a thought that I may have missed in all the conversation. To me this is partly about some simple CYA. If a breach occurs in a an app I worked on I want to be able to say I followed best practice where I could and within reason. Following OWASP advice would be wise, would it not?
Like Ben, I'm all for using sessions and have no need to use anything else. JWT doesn't solve a problem for me. (Until now, I may need to use some sort of token the client side framework needs to use). I appreciate all the different points of view though. In particular one person wrote about the need to balance security and usability, something we all have to do at times. But for me, unless I'm forced to, I see no need to change from old school sessions cookies, they're easy for me.
What's hard for me in all this debate is the completely different needs of some devs. seems like on one hand some of us work in much larger projects with multiple backends and teams. And on the other hand, there's people like me, where we have zero need for multiple backends, don't work with multiple teams, on small apps, have no apps/services that would ever need that, and no desire for it either. For me, I don't even get what people mean by stateless? (Isn't HTTP stateless by design?) My apps only talk to a single server and database. And the sessions stored on the backend lookup and validate every request, and its not slow (servers are pretty fast anymore, memory and storage is cheap). But I get it. If I were in the other situation with large scale deployments and backends I don't control, API's that have only one way to auth, I'd probably see it differently.
About SPA's, I've got an EmberJS SPA, that can run as a PWA, using standard form-based login and using sessions cookies. All while sharing the session with the older PHP server rendered pages so the user moves between old and new parts of the apps for certain legacy functions. (The older pages aren't tested with PWA integration though, yet). This is on a single server, however.
I suppose we all have to use the tools we've been given. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have nothing to add to the existing conversation; other than to say this was a very thought-provoking post and follow-up set of comments. If nothing else, it has given me pause to stop and think about something that I may have just used blindly in the past. That said, I'm all-for session cookies. I always felt like JWT was solving a problem that I didn't have (I currently use session cookies to reference a server-side cache).
I'm with you Ben. But I do have a thought that I may have missed in all the conversation. To me this is partly about some simple CYA. If a breach occurs in a an app I worked on I want to be able to say I followed best practice where I could and within reason. Following OWASP advice would be wise, would it not?
Like Ben, I'm all for using sessions and have no need to use anything else. JWT doesn't solve a problem for me. (Until now, I may need to use some sort of token the client side framework needs to use). I appreciate all the different points of view though. In particular one person wrote about the need to balance security and usability, something we all have to do at times. But for me, unless I'm forced to, I see no need to change from old school sessions cookies, they're easy for me.
What's hard for me in all this debate is the completely different needs of some devs. seems like on one hand some of us work in much larger projects with multiple backends and teams. And on the other hand, there's people like me, where we have zero need for multiple backends, don't work with multiple teams, on small apps, have no apps/services that would ever need that, and no desire for it either. For me, I don't even get what people mean by stateless? (Isn't HTTP stateless by design?) My apps only talk to a single server and database. And the sessions stored on the backend lookup and validate every request, and its not slow (servers are pretty fast anymore, memory and storage is cheap). But I get it. If I were in the other situation with large scale deployments and backends I don't control, API's that have only one way to auth, I'd probably see it differently.
About SPA's, I've got an EmberJS SPA, that can run as a PWA, using standard form-based login and using sessions cookies. All while sharing the session with the older PHP server rendered pages so the user moves between old and new parts of the apps for certain legacy functions. (The older pages aren't tested with PWA integration though, yet). This is on a single server, however.
I suppose we all have to use the tools we've been given. :)