(Question) CSRF Token

[johaven]

Why does not include CSRF Token in claims of JWT (cookie mode) instead of create another dedicated new cookie ?
On front end we can read the payload and forge the http request with CSRF header

Edit: forget my question, the cookie is httponly ...

[vimalloc]

Since you closed this I'm assuming figured it out. Just in case someone else finds this, here is a great writeup about CSRF, double submit verification, and why we are doing things this way: http://www.redotheweb.com/2015/11/09/api-security.html

If you have any additional questions, don't hesitate to let me know! :)

[johaven]

I was wondering if it was not more elegant to send the csrf token in the answer when the user authenticates rather than generating a cookie just for this purpose.

Otherwise I take the opportunity to say, good library, very good job :)

[vimalloc]

Ah, I see. That would be totally doable. We don't control how a user returns data, but we could make an option to not set the double submit token a secondary cookie, and provide a way to access the token in the main cookie. Your endpoint would probably look something like this:

access_token = create_access_token('bobdobs')
csrf_token = get_csrf_token_from_jwt(access_token)
resp =  jsonify({'csrf_token': csrf_token})
set_access_cookies(resp, access_token)
return resp, 200

I would need to add an option for set_access_cookies(resp, access_token) to not set the CSRF token, and add the set_access_cookies(resp, access_token), but neither of these would be difficult.

I'm pretty busy this weekend, but I could look at writing a patch for this next week.

Thanks for contributing! 👍

[johaven]

Thank you ! 👍

[johaven]

Another question, why the refresh cookie CSRF has the default path: '/' ?
This cookie will be used only with one path (url example: '/auth/refresh').
It would be lighter to not transport this cookie on every path no ?

[vimalloc]

If I recall correctly, I think the reason we did this was because the javascript will only let you access a cookie if it has the same path as the javascript. So if you needed to access the refresh csrf token from a non-refresh csrf path (for example, if you make a call to an endpoint, it returns that your token is expired, and from this endpoint you attempt to grab the csrf value from the cookie and use the refresh token).

That said, this could totally be another configuration option, so that you could tailor it to your needs and how you are using this extension. I'll look into that.

[vimalloc]

Released in 1.4.0