Following workarounds in this Auth0 reference: Troubleshoot Renew Tokens When Using Safari
We are unable to get logins to work using Safari cross site tracking enabled (ITP). Event after setting up a custom domain for auth Safari still doesn’t work. PLEASE HELP.
React 18.2 SPA website
using Auth0 react 2.2.0
What further information can we supply which will assist?
Hey thre @brett2 !
Are you able to elaborate on what you mean by logins not working? Where exactly is the login flow breaking down? Are there any errors or additional context you can share? The more detailed information you can provide the better!
Thanks!
Ty
I’d be super-happy to. Here is the success code. When using Safari the user variable doesn’t get a value from useAuth0(). When other browsers are used all works as expected. GET_USER is a GraphQL query statement.
const LoginSuccess = () => {
const { user } = useAuth0();
const { data, loading, error } = useQuery(GET_USER);
let redirect = false;
if (user?.email_verified === false) {
redirect = <Navigate to="/verify-email" />;
}
if (!loading) {
if (data?.users?.me) {
redirect = <Navigate to="/dashboard" />;
} else {
redirect = <Navigate to="/create-profile" />;
}
}
...
Below is the root index.js where Auth0 is initialized
root.render(
<Auth0Provider
domain="auth.mydomain.com"
clientId="<scrubbed>"
authorizationParams={{
redirect_uri: `${window.location.origin}/login-success`,
audience: 'https://anotherdomain.app',
scopes: 'openid profile email offline_access',
}}
cacheLocation="localstorage"
useRefreshTokens
useFormData={false}
>
<ApolloAuthProvider>
<BrowserRouter>
<App />
</BrowserRouter>
</ApolloAuthProvider>
</Auth0Provider>,
);
Hey @brett2 thanks for sharing!
I have been attempting to reproduce on my end using our React sample app and have up to this point not been able to reproduce what you are seeing in Safari.
In particular, using default settings in Safari (prevent cross-site tracking on) I am logging a user in and getting a valid user from useAuth0() here:
Auth0Provider is initialized here and App component and subsequently Router can be found here.
Would you be willing to configure the sample app to your environment and test that way? I’m just curious if you experience the same issue with the stripped down sample app.
Please keep us posted!
Hi @tyf,
I am on vacation next week so trying this out will be delayed. I honestly didn’t think it would a few days to get a response (this is my second post on this issue trying to get a response).
Does the onRedirectCallback need to defined? We are not using this property at all. It doesn’t seem like something that would affect the login as well.
The other part which is confusing me about the simple example app is that refresh tokens are not enabled. I also don’t see a scope being defined in the client. So a few differences noted right off the bat.
If we have useRefreshTokens={false} and no localstorage (which is how the example is set), the login works, but only with ITP disabled (or shields down).
How will some of these initially pointed out discrepancies affect things?
Hey @brettski thanks for getting back to me! I apologize for the delayed response. We try our best to get to everyone and everything here but even then we aren’t able to 
onRedirectCallback is not required.
My bad! You will need to set both in order to test properly.
I’ve tested with both useRefreshTokens set to false and true - I am able to log in using both Brave and Safari successfully. When my access token is expired and the SDK goes to perform silent auth without a refresh token it fails in both browsers and user interaction is required. However, with a refresh token there is a successful refresh token exchange in my tenant logs which is the expected behavior.
{
"date": "2023-08-14T22:12:13.082Z",
"type": "sertft",
"description": "Successful Refresh Token exchange",
"connection": "Username-Password-Authentication",
"connection_id": "xxx",
"client_id": "xxx",
"client_name": "spa-test",
"ip": "72.220.48.156",
"user_agent": "Chrome 115.0.0 / Mac OS X 10.15.7",
"details": {
"tokenCounter": 2,
"familyId": "xxx"
},
"user_id": "auth0|xxx",
"user_name": "test@gmail.com",
"audience": "https://test-api-endpoint",
"scope": "openid profile offline_access",
"auth0_client": {
"name": "auth0-react",
"version": "2.2.0"
},
"log_id": "90020230814221000000000001223372048904718193",
"_id": "9002023081422121581340700000000001223372048904718193",
"isMobile": false,
"id": "900202308142212158130000000001223372048904718193"
}
Please let us know when you are able to test this in the sample app specifically 
@tyf While I was on vacation a person on my team determined there was delay in getting things back initially. The code below shows the addition of a custom component <AuthWrapper>, which is detailed below. This hack has corrected the login issue while refresh tokens are enabled. Which as I mentioned was causing me issues when testing things out.
root.render(
<Auth0Provider
domain="auth.example.com"
clientId="<scrubbed>"
authorizationParams={{
redirect_uri: `${window.location.origin}/login-success`,
audience: 'https://example.app',
scopes: 'openid profile email offline_access',
}}
useRefreshTokens
cacheLocation="localstorage"
useFormData={false}
>
<ApolloAuthProvider>
<BrowserRouter>
<AuthWrapper> // <--
<App />
</AuthWrapper>
</BrowserRouter>
</ApolloAuthProvider>
</Auth0Provider>,
);
As you see the “wrapper” component is pretty basic:
import React from 'react';
import { useAuth0 } from '@auth0/auth0-react';
function Wrapper({ children }) {
const { isLoading } = useAuth0();
if (isLoading) {
return <div />;
}
return <>{children}</>;
}
export default Wrapper;
Now we’re wondering if there is a better way to handle this as this doesn’t “feel right”.