4 ms·

I know this is a replacement for cookie, but some web apps use JS and sessionStorage on browser to store session token instead of using cookie. This protocol s

I know this is a replacement for cookie, but some web apps use JS and sessionStorage on browser to store session token instead of using cookie. This protocol seems to also depend on JS to do client side cryto logic and adding HTTP headers. Unless by browser/client it means the actual browser, which would take ages to get implemented across all user agents. In which case, it would likely be polyfilled by JS first as the de facto standard of doing things. I wonder how this compares to using sessionStorage.

nneonneo 3y ago
The protocol does provide for fallback: if the client doesn’t understand the WWW-Authenticate: WebSession header, it can just choose to ignore it and send a request without Authorization, at which point the server can fall back to a traditional session mechanism.
- paradite 3y ago
  It's just an HTTP header, I'm sure frontend devs will be polyfilling the implementation before the browsers, if this were to be the standard.
zmxz 3y ago
> This protocol seems to also depend on JS It doesn't mention any dependency on JS, there's pseudocode in Python to demonstrate generating/using the token. > but some web apps use JS and sessionStorage on browser to store session token instead of using cookie This is particularly strange, I've seen that frontend apps do this but I can't understand why because it's error prone and excellent attack vector. It boils down to emulating cookies, having to have some sort of request interceptor that includes the token on every XHR/fetch to serverside and another interceptor that saves updated token on every valid response from serverside. It seems like a misguided attempt to rectify problems that stem from CORS handling or shortsighted design where auth was bolted on as an afterthought.
- paradite 3y ago
  There are valid use cases and complex interactions between multiple systems where the only solution is client handling of user token. Also, sessionStorage is a web standard and it is designed to store data to be used in the session. If you think frontend devs shouldn't use it because they are incompetent at handling XSS, then maybe backend devs should also not use databases because they might leave the port open to public internet.

nneonneo 3y ago

The protocol does provide for fallback: if the client doesn’t understand the WWW-Authenticate: WebSession header, it can just choose to ignore it and send a request without Authorization, at which point the server can fall back to a traditional session mechanism.

paradite 3y ago
It's just an HTTP header, I'm sure frontend devs will be polyfilling the implementation before the browsers, if this were to be the standard.

zmxz 3y ago

> This protocol seems to also depend on JS It doesn't mention any dependency on JS, there's pseudocode in Python to demonstrate generating/using the token. > but some web apps use JS and sessionStorage on browser to store session token instead of using cookie This is particularly strange, I've seen that frontend apps do this but I can't understand why because it's error prone and excellent attack vector. It boils down to emulating cookies, having to have some sort of request interceptor that includes the token on every XHR/fetch to serverside and another interceptor that saves updated token on every valid response from serverside. It seems like a misguided attempt to rectify problems that stem from CORS handling or shortsighted design where auth was bolted on as an afterthought.

paradite 3y ago
There are valid use cases and complex interactions between multiple systems where the only solution is client handling of user token. Also, sessionStorage is a web standard and it is designed to store data to be used in the session. If you think frontend devs shouldn't use it because they are incompetent at handling XSS, then maybe backend devs should also not use databases because they might leave the port open to public internet.