How token based auth actually works under the cover?


I’ve been using token based auth in my Weweb project and I noticed that access and refresh tokens are stored in cookies. I have not deployed my project yet, this is how I see it in the editor.

Is this how the token based auth actually works? Cookies are not httpOnly of course, since they are manipulated by Javascript so this opens a way to vulnerabilities.

Thank you.

You’re correct, it’s how it works for now. I think we may update this behavior in the near futur by sending the tokens to our back end and let it set them back as cookies, so we could make them httpOnly.
It would be more secure indeed, but it would also mean we wouldn’t be able to set the session again automatically after a refresh, or we would have to store it inside localstorage that would probably defeat the purpose to have a cookie with httponly.

Because when we load your app we check if the cookie exist, if so we take the token inside and make a request to your user endpoint and so we can keep your session open as long as the token is valid.

If instead we choose to ask our backend to do it instead of the front end (as it will receive the secure cookie he will be able to do this call to the user endpoint and return the user info) it would mean the plugin couldn’t work on self hosting, without our auth microservice.

So yeah, its a complex topic.

1 Like