Feature request : Cookie storage option for auth data

[chatnuere]

Hello, and thanks for this awesome plugin that saved me a lot of time !

I'm submitting a...

• Regression (a behavior that used to work and stopped working in a new release)
• Bug report
• Performance issue
• Feature request
• Documentation issue or request
• Other... Please describe:

Current behavior

Local storage is the only way to store auth data

Expected behavior

Have an option to store auth data in cookies

What is the motivation / use case for changing the behavior?

Local Storage is accessible to any running javascript on the current page.

A lot of developers are warning about security issues :

• https://www.rdegges.com/2018/please-stop-using-local-storage/

I've never seen a big company using angular storing user authentication in local storage :

• https://customers.microsoft.com
• https://www.paypal-community.com
• https://source.cloud.google.com
• https://pay.google.com

(https://www.madewithangular.com/)

I'm possibly wrong because i'm not a security expert, but if it is possible to have the choice in the options, that would be great.

Thank you and have a nice day :)

Environment

Angular-Token version: latest
Angular version: latest

Bundler

• Angular CLI (Webpack)
• Webpack
• SystemJS

Browser:

• all

Others:

[neroniaky]

Thanks for your feedback. I gonna take a look at it.

[hossameldeen]

First, I second @chatnuere's thanks :-)

Second, my take on cookies vs localstorage:

• The linked article has a mirror on dev.to with comments offering a counter view. Didn't read them all, but my conclusions from these:

  • Local storage is protected by same-domain policy. No code from other websites can access it.

  • Since localstorage isn't attached automatically to requests, I guess this means we also don't have the whole issues of CSRF we'd have if were using cookies?

  • The main security complain I found of local storage is in case of XSS: if someone is able to inject code into your website that reads the tokens and sends them to the attacker's server to use later.

  • Comparing the XSS in cookies: only if you use HttpOnly flag, an attacker can't steal the tokens because they can't access it, but they can still make requests on your behalf with the injected code.

• So, do we want to use cookies just as storage alternative or do we want to move to a solution that utilizes what cookies provide?

• If we use cookies just as storage alternative, thus not using HttpOnly, seems like we'd get the worst of both worlds: we'd be facing the same problems of localstorage in case of XSS, and we'd be open to CSRF.

• If we use cookies with HttpOnly, then why did we use devise-token-auth in the first place? ... I really am not 100% sure of the reason :-) Probably because devise doesn't play well with single-page apps or something -- haven't given it much thought.

• There could be other complains to localstorage, but these are my thoughts about the complains I've read.

So, if we'll go for cookies as just alternative storage, my opinion would be to not provide that option. I see cookies as adding extra risks for an unprepared user. And if an expert user knows why cookies are better, they should tell us & we'd use it then, not as an option but as the only way.

If we'll use them in an entirely new way, however, that's another story.

Needless to say, I'm not a security expert in any way.