Won't authenticate on Mobile using SPA app React/GatsbyJS configuration

Good morning everyone,

I spent the weekend learning the Auth0 API to setup an authenticated Gatsby blog site to add a customer portal. I watched many YouTube talks talking about adding Auth0 to Gatsby could not find any recipes even though many videos referenced them.

With all that being said I used the the Auth0 Gatsby Starter and added the appropriate logic to the appropriate spots. Did not work on the first try but after moving stuff around and debugging I got it to work really well on desktop browsers.

Towards the end of the weekend I realized that if I tried logging in in on mobile browsers it would let you authenticate via auth0 then just redirect from the dashboard/accounts page after entering user and pass via auht0 back to the callback page. I am assuming there is some kind of issue with the mobile browsers accepting the cookie from auth0. I replicated this on Brave Browsers with shields up and down as well as Safari.

Would love to figure out why logging in via mobile browsers wont work. Perhaps if I ask for cookie permission? How might this work with auth0?

I noticed this is the same issue as reported on this board.

CC: @dan.woda don’t mean to nag just wanted to let you know since you have looked into this before.

This is happening on all mobile it seems can reproduce on a iPhone emulator as well as shown in GIF.

After some further trial and error it seems that logging in on mobile android works so perhaps it is only iOS devices that are effected. I have a hunch it has something to do with cookie permissions.

I’ve had similar issues with Safari – the reason being that Safari has started blocking third-party cookies (which are used to authenticate with Auth0). Chrome will soon follow this trend.

Can you try setting cacheLocation to localStorage in your Auth0Provider component? Like so:

<Auth0Provider
	domain="example.com"
	clientId=""
	redirectUri={redirectUri}
	onRedirectCallback={onRedirectCallback}
	onRedirecting={onRedirecting}
	audience="https://api.example.com/"
	useRefreshTokens
	cacheLocation="localstorage"
>

I am not using auth0-react I am using auth0-js I am assuming there is a similar param in auth0-js? I want to convert it to auth0-react soon just could not find any resources online for that API as I am learning auth0 for the first time.

Oh, alright then.
I’m not very familiar with auth0-js, but I’m sure there’s a parameter somewhere for it.
Here’s a good resource on Auth0-React, if you want to get started: Auth0 React SDK Quickstarts: Login.
Here’s information about using it in a Gatsby app: auth0-react/EXAMPLES.md at master · auth0/auth0-react · GitHub.
And here’s a sample Gatsby app using Auth0-React: auth0-react/examples/gatsby-app at master · auth0/auth0-react · GitHub

1 Like

I found the corresponding documentation but it says using local storage is a security risk so it has me second guessing using this solution at least for the long term.

Right under the section about local storage there is a section talking about Refresh Token Rotation to fix this problem and not pose a security risk there is more info on that here but I implemented that and it is still not working.

Does anyone know if Refresh Token Rotation still is a good work around for this issue?

Feels like the other two options are to go with local storage for now till I upgrade to a paid plan and can do a “custom domain” but I really don’t want to pay for something that is not ready for production yet… but I also need to be able to test on all devices.

At this point I have enabled both cacheLocation of “localstorage” and useRefreshTokens and it seems I am still having this problem -sigh-…

Here is a snip-it of my authenticator

const auth = isBrowser
  ? new auth0.WebAuth({
      domain: process.env.GATSBY_AUTH0_DOMAIN,
      clientID: process.env.GATSBY_AUTH0_CLIENTID,
      redirectUri: process.env.GATSBY_AUTH0_CALLBACK,
      responseType: 'token id_token',
      scope: 'openid profile email',
      useRefreshTokens: true,
      cacheLocation: 'localstorage',
    })
  : {};

So the more I research and look into it this seems like a consistent problem with iOS respectively.

Seems that there are two solutions

  1. Get the paid plan and redirect only to a subdomain
  2. Use a self hosted login page that is native to the application that just dispatches data to the auth0 API.

I would like to go with #2 till I get some paying clients but I am having a hard time finding docs on how to implement it.

Would be fantastic if someone could point me in the right direction!

So I found this article comparing and contrasting login methods and it looks like you also need the paid plan to securely do the embedded login cause it needs a custom domain to free up security concerns for cross origin attacks… honestly pretty sad about this and am going to consider other login services cause I am really sad I cant roll this out effectively to clients with testing before I pay for it per implementation :frowning: