Vulnerable to XSRF if cookie use enabled

[LittleColin]

Hey, helpful library but thought I should point out the following (apologies if I've missed some mitigation you've added).

By allowing a cookie to be used as the authentication mechanism, you are opening up implementations to XSRF attacks.

https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/#token-storage

As discussed in the above post, storing a JWT in a cookie is fine as long as it can't be used for authentication. Whilst there may be an unusual use case for this, it is more likely that without an additional XSRF token, this particular feature is just opening up a security hole.

Hope this helps.

[osudude]

Another thing you have to worry about with Cookie based authentication is cookie replay after signout. Does the code have any way to invalidate a cookie session so that it can't be reused after signout?
In MS WIF world, we use a custom SessionSecurityTokenCache to deal with this.

[jamiekurtz]

@LittleColin Thanks for the info, and I agree on the CSRF issues with cookies. At this point my library doesn't handle it. I'm actually not sure how it would, as it would to enforce the Synchronizer Token Pattern on the site itself. If building my own site with ASP.NET (either MVC Framework or SPA/WebAPI), I might just leverage the built-in anti-forgery token feature: http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks.

@osudude Definitely a concern when using cookies with tokens in them. I think it would be up to the application to know whether or not a user is signed out, though. In other words, nothing in the token itself indicates the user's signed-in state. So once a token is parsed/accepted by the API, the API should verify that the user hasn't signed out (i.e. based on the username or id provided by the token). One could also put the entire token (or a hash of it) in the "users" table - much like an OAuth access token. Then on every request, you would check the table for that token - and consider it invalid if not found (assuming a sign-out would clear the token from the user's record).

[bcardi]

This article from the Stormpath developers provides some great insight on why cookies are the best option for JWT and how to mitigate the issues described here. https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/