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

General
, , , ,
#1

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?

mobile-auth0-2
mobile-auth0-2320Ă—646 6.35 MB

#2

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.

#3

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.

#4

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"
>
#5

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.

#6

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
#7

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.

#8

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',
    })
  : {};
#9

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!

#10

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: