Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question/Feature Request: Token Storage #161

Open
JamieBradders opened this issue May 7, 2020 · 0 comments
Open

Question/Feature Request: Token Storage #161

JamieBradders opened this issue May 7, 2020 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@JamieBradders
Copy link

I'm submitting a ...


[ ] Regression (behavior that used to work and stopped working in a new release)
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request

Current behavior

Hi there, I wanted to raise a question/possible feature request after playing around with the SDK yesterday. I noticed that the UMS module (for the Browser SDK) is storing the access/refresh token in local storage. I've read on alternative auth platforms, such as Auth0, that these tokens should not be stored in local storage to prevent certain attacks. I was just wondering if there were any potential issues or vulnerabilities with storing the tokens in local storage in this way?

Please note that I'm by all means no expert in this area 😂 but I'm just referring to things I've seen in blog posts and other documentation such as https://auth0.com/docs/tokens/concepts/token-storage#browser-local-storage-scenarios

Expected behavior

I posted this in Discord yesterday and Marlos kindly replied with the following suggestions:

  • Store both access_token and refresh_token in a httpOnly cookie but this would still make it vulnerable to CSRF attacks

  • Store the access_token in memory (in our case inside WebStorageComponent for example) and keep the refresh_token in a httpOnly cookie, which looks like the more secure alternative

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

Based on the above I believe there is a possiblity that malicious third party scripts can acquire the access/refresh tokens for the Jexia API and therefore carry out CSRF attacks.

@JamieBradders JamieBradders changed the title Question/Feature Request: Storage of Tokens Question/Feature Request: Token Storage May 7, 2020
@BaileyJM02 BaileyJM02 added question Further information is requested enhancement New feature or request labels May 7, 2020
@marlosin marlosin self-assigned this May 8, 2020
@marlosin marlosin removed their assignment Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants