Safari localStorage forgetting state value used for CSRF protection

Hi,

We’re using the OpenID state parameter to protect against CSRF attacks, as documented here: https://auth0.com/docs/protocols/oauth2/mitigate-csrf-attacks

We’ve got an SPA, and are using localStorage to store the generates state value before authentication, against which we can validate the state value provided by Auth0 when we receive the authentication result via a redirect back to our SPA.

In most browsers this works fine. (We had to switch from sessionStorage to localStorage because Microsoft Edge wasn’t persisting sessionStorage across the redirect in some cases.) However in some cases Safari isn’t persisting the data we store in localStorage across the redirect to Auth0. For some reason this seems to mostly affect users outside the UK (most of our users are in the UK), or users accessing our site via a non-UK VPN.

Are there any best practices for how an SPA can store the state value in order to maximum cross-browser (and cross-device, and cross-geography) compatibility? Or a reference implementation that we can compare against to ensure we are doing it in a standard way?

Here’s a bit more background for our set-up in case it is relevant: We’re using a modified Auth0-hosted login page. On loading our SPA we’re immediately redirecting to that login page, using a “WebAuth” client from the “auth0-js” npm library configured with responseType: 'token id_token' and scope: 'openid'. We pass a “state” property to the authorize() call but when the user returns to our app after login it doesn’t match the value we stored in localStorage.

Thanks in advance for any help

Hey there!

Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.

Wanted to reach out to know if you still require further assistance?

Opening topic as per requested by @martin.pain, since his account was locked out.

Hi @konrad.sopala.

I believe this is still affecting some of our users who are having to work around it. Is there any information or best practices that Auth0 can provide to help with this issue?

Thanks,
Martin Pain

Hi @konrad.sopala and @James.Morrison, is there any chance of getting a response to this question?

Hey there @martin.pain!

I will look into this and get back to you soon!