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

Best practice for authentication #226

Open
bobbyshaw opened this issue May 2, 2024 · 0 comments
Open

Best practice for authentication #226

bobbyshaw opened this issue May 2, 2024 · 0 comments

Comments

@bobbyshaw
Copy link

bobbyshaw commented May 2, 2024

Hey team,

I'm posting this discussion here in lieu of having anywhere better. I hope that's ok!

We have Laravel + React apps that make use of cookies for authentication. As per your recent article, this suffers from being blocked in some browsers. We do our best to detect cookies being blocked and request that people open in a new tab to force a first-party context.

We have an unreleased improvement which adds partitioned cookie support so that we remain compatible in Chrome. It already works fine in Firefox as third-party cookies are automatically partitioned per requesting domain. Unfortunately, providing compatibility with Safari is still very difficult as it requires a separate method requestStorageAccess which requires the user to have visited the domain in a first-party context and interacted with the page within the last 30 days. I'm loathed to invest the resources to create this sub-par experience.

This has led me to reconsider the cookieless approach, but I cannot currently see a way forward that isn't susceptible to a security flaw and so I wanted to look to you for guidance.

My understanding is that when using the JWT approach, whether it's stored on a URL as per this repo, or stored in local storage/session storage, the credentials are visible to any JS and so I believe it's susceptible to being stolen through XSS.

(Again, from my research, JWT best practice is to deliver as an HTTP only, secure cookie (preferably also with SameSite strict to mitigate CSRf) but this route is not available to us for obvious reasons).

From my research outside of BigCommerce, some people suggest issuing JWTs with a short life and then providing a long-life refresh token but we have no way to deliver a refresh token in a manner that doesn't have the same security weakness.

Are you aware of another option to protect against XSS when using the JWT approach recommended in this app?

Many thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant