treechicken@lemmy.world to Programmer Humor@lemmy.ml · 11 months agoSPAs were a mistakelemmy.worldimagemessage-square19fedilinkarrow-up1256arrow-down111
arrow-up1245arrow-down1imageSPAs were a mistakelemmy.worldtreechicken@lemmy.world to Programmer Humor@lemmy.ml · 11 months agomessage-square19fedilink
minus-squareimmortaly007@feddit.nllinkfedilinkarrow-up1·11 months agoIt’s a security thing. The HttpOnly cookie can’t be stolen using XSS or something like that, while a bearer token must be stored somewhere where javascript can see it.
minus-squarelemmyvore@feddit.nllinkfedilinkEnglisharrow-up1·11 months agoThat’s assuming the client wants to make a web app. They may need to connect something else to that API. It’s perfectly normal to be able to cater to more authentication scenarios than “web app logging in directly to the target API and using its cookies”. If they want to make a web app they should use the cookie mechanism but ultimately each client app is responsible for how it secures its access.
minus-squaregornius@lemmy.worldlinkfedilinkarrow-up1·11 months agoThen again, cookie auth is vulnerable to CSRF. Pick your poison. Although CSRF protection just adds a minor inconvenience, while there is never a guarantee your code is XSS vulnerability free.
It’s a security thing. The HttpOnly cookie can’t be stolen using XSS or something like that, while a bearer token must be stored somewhere where javascript can see it.
That’s assuming the client wants to make a web app. They may need to connect something else to that API.
It’s perfectly normal to be able to cater to more authentication scenarios than “web app logging in directly to the target API and using its cookies”.
If they want to make a web app they should use the cookie mechanism but ultimately each client app is responsible for how it secures its access.
Then again, cookie auth is vulnerable to CSRF. Pick your poison.
Although CSRF protection just adds a minor inconvenience, while there is never a guarantee your code is XSS vulnerability free.