isAuthenticated is false after successful login

[Kaschman]

After following the SPA setup guide I have similar problems to #49 #60 and #63.

The fix of cycling Application type is not working for me. I have also tried to enable refresh tokens as mentioned in #60 but see the same results.

I see 'Success Login' events in my User History and see populated code fields in my callback urls. But isAuthenticated remains false.

I have tried to get the CRA example app found in this repo running with my app credentials but am struggling to get the npm dependencies installed correctly to the point where the example app will start.

Any further troubleshooting ideas? Should I try the older client JS library?

[chefinDan]

Check that you aren't preventing sameSite cookies in your browser. Anything based on Chromium will automatically block sameSIte cookies, which prevents the user session cookie from being saved.

[anthonycole]

Hi; I'm doing similar and also getting isAuthenticated consistently false (even after loading is finished). Refreshing the page fixes the issue. I'm using a standard Auth0 SPA that I created from scratch with LinkedIn/User auth and it happens no matter what social provider I use.

[jimmyzhen]

I am also experiencing the similar problem in which the isAuthenticated state remains false and the user state is undefined even after a Response Payload being returned including the access_token and id_token. Refreshing the SPA app in the browser couldn't address the problem at all. I've been debugging this issue in both Chrome and Firefox in case the sameSite cookies issue made a difference (which it didn't). Toggling the Single Page Application option in the admin console didn't resolve anything either.

[adamjmcgrath]

Hi @Kaschman - could you check if your clientId and domain work in the playground https://github.com/auth0/auth0-react/blob/master/static/index.html#L85-L86 - you can run it with npm start

If it doesn't work, please share your clientId and domain and I'll take a look

[Dummote]

Hi all!

I dont know if this is related, but I found a bug when you are logged and the isLoading variable is set as false but isAuthenticated variable is false too for 2 or 3 seconds so when you check if isAuthenticated it always gets false the first time.

I think the problem is that the isAuthenticated default value is set as FALSE, so the first time we ask for it, it returns that value. I made some changes to my local files and set the initial value as null, so if I get a null I know the reducer still didn't update the value and that I have to wait until the value change to false or true to let (or not) the user enter to a specific page.

[adamjmcgrath]

Hi @Dummote - thanks for your input

isAuthenticated and isLoading should only both be false when you are logged out, either because you have logged out or login has failed.

Would you mind sharing a minimal test case code example of what you're describing?

[Dummote]

Yes! If you try to do something like this:

const {
    isLoading,
    isAuthenticated,
    loginWithRedirect,
    user,
  } = useAuth0();
  
  
  
useEffect(() => {
	if(!isLoading && !isAuthenticated) loginWithRedirect()
}, [isLoading, isAuthenticated]);

When you enter that page, you are going to have the isLoading in TRUE and the isAuthenticated in FALSE (but the isAuthenticated is not really false because you have not check it yet), the problem is in one point you are going to have the isLoading and the isAuthenticated in FALSE so if going to redirect you to the login again and again. This happends when you are logout and use that code.

If you remove the loginWithRedirect and put two console log in there your are going to have a result like this

isLoading TRUE isAuthenticated FALSE
isLoading FALSE isAuthenticated FALSE
isLoading FALSE isAuthenticated TRUE

I also try avoid listening the isLoading in the useEffect, and have the same result

useEffect(() => {
	if(!isLoading && !isAuthenticated) loginWithRedirect()
}, [isAuthenticated]);

[anthonycole]

@adamjmcgrath -isAuthenticated still seems to only return true for me on a refresh. I just tried running the playground with my clientId and domain and they work fine... I've followed the tutorial for working with react router so I'm a bit confused as to what's going on because the playground works seamlessly.

[anthonycole]

@adamjmcgrath on further investigation - I'm using react router 4, and adding the callback as instructed (around Auth0ProviderWithHistory) in the tutorial appears to break isAuthenticated...

https://auth0.com/blog/complete-guide-to-react-user-authentication/

const onRedirectCallback = (appState) => {
    // Use the router's history module to replace the url
    history.replace(appState?.returnTo || window.location.pathname);
  };

[anthonycole]

@adamjmcgrath I've managed to get it to work on CRA when I redirect them back to http://localhost:3000 like the playground. But adding a different route (so pushing the user to /login, where it seemingly returns with a code parameter) or adding the onRedirectCallback seems to break the flow and the user is not authenticated until they refresh.

[jimmyzhen]

@anthonycole Thanks for sharing your investigation.

I pretty much followed the tutorial in the https://auth0.com/blog/complete-guide-to-react-user-authentication blog article as well, except that I set the Auth0Provider's redirectUri prop to a different route (e.g. a protected route) rather than window.location.origin described in the tutorial.

Here is the reference to the redirectUri prop:
https://auth0.github.io/auth0-react/interfaces/auth0provideroptions.html#redirecturi

Actually it didn't occur to me that redirecting the authenticated user back to the / route might have worked, since I didn't think my use case to be unique.

[adamjmcgrath]

This thread is taking a few tangents, and I haven't heard from @Kaschman for a while, so I'm going to close it (@Kaschman feel free to reopen if you want to share some more details)

@Dummote - I'm not able to reproduce what you're seeing, if you want me to investigate, please could you open a separate issue with a running example, or a link to some code that I can run.

@anthonycole and @jimmyzhen - it sounds like your issues are resolved - please open a new issue with some reproducible steps if this is not the case.

[jimmyzhen]

@adamjmcgrath I don't think our issues have been resolved...

[nickgieschen]

One thing which I discovered causes this:

In order for isAuthenticated to get set to true, the function in onRedirectCallback has to get called. I had my redirectUri set to "http://localhost:3000". However, I was redirecting on "/" to "/some-other-page". In other words, the redirectUri was being navigated away from. Apparently, if the redirectUri doesn't get a complete load, the onRedirectCallback fn doesn't get called. I solved in by creating a dedicated /auth-callback page and set this to the redirectUri.

[AashiqDurga]

I am still having this issue even after I changed my callback url to http://localhost:3000/dashboard and set it like so

<Auth0Provider
            domain=""
            clientId=""
            redirectUri="http://localhost:3000/dashboard"
            onRedirectCallback={onRedirectCallback}
        >

[teenkevo]

One thing which I discovered causes this:

In order for isAuthenticated to get set to true, the function in onRedirectCallback has to get called. I had my redirectUri set to "http://localhost:3000". However, I was redirecting on "/" to "/some-other-page". In other words, the redirectUri was being navigated away from. Apparently, if the redirectUri doesn't get a complete load, the onRedirectCallback fn doesn't get called. I solved in by creating a dedicated /auth-callback page and set this to the redirectUri.

Hi, thanks for your explanation. I'm curious to see how you did this, probably with some example code. I'm stuck on peoboem in this issue but i have no clue on how to solve it using your method. Please advise, thanks

[hudson155]

If anyone else is having this issue - my problem was caused by the Auth0 Provider being outside of my BrowserRouter. This caused weird things to happen with calling history.push/history.replace. I solved it by moving my BrowserRouter inside my Auth0 Provider.

[potouridisio]

One thing which I discovered causes this:

In order for isAuthenticated to get set to true, the function in onRedirectCallback has to get called. I had my redirectUri set to "http://localhost:3000". However, I was redirecting on "/" to "/some-other-page". In other words, the redirectUri was being navigated away from. Apparently, if the redirectUri doesn't get a complete load, the onRedirectCallback fn doesn't get called. I solved in by creating a dedicated /auth-callback page and set this to the redirectUri.

Can you provide an example? I'm also struggling to get the onRedirectCallback to get called. None of the examples worked for me and I've followed everything line by line.

[JenniferTactill]

If anyone else is having this issue - my problem was caused by the Auth0 Provider being outside of my BrowserRouter. This caused weird things to happen with calling history.push/history.replace. I solved it by moving my BrowserRouter inside my Auth0 Provider.

Auth0 Provider outside of BrowserRouter solved with Auth0 Provider outside of BrowserRouter ?

[bino98]

I have the same problem.

It is implemented in Nextjs

 <Auth0Provider
  redirectUri="http://localhost:3000/"
  onRedirectCallback={(appState) => {
    Router.replace('/')
  }}>...

If you define a custom onRedirectCallback,
isAuthenticated will be moment set to false even though the login is successful.

In the following cases, it will not occur.

 <Auth0Provider
  redirectUri="http://localhost:3000/"
  >...

[bino98]

Sorry. Now, it is working as intended.

If I define the function used in onRedirectCallback outside of FC, it works.

const onRedirectCallback = (appState?: AppState) => {
  Router.replace(appState?.returnTo || '/')
}

const App: FC<AppProps> = (props) => {
  return (
      <Auth0Provider
        onRedirectCallback={onRedirectCallback}>...

[jozzhart]

One thing which I discovered causes this:

In order for isAuthenticated to get set to true, the function in onRedirectCallback has to get called. I had my redirectUri set to "http://localhost:3000". However, I was redirecting on "/" to "/some-other-page". In other words, the redirectUri was being navigated away from. Apparently, if the redirectUri doesn't get a complete load, the onRedirectCallback fn doesn't get called. I solved in by creating a dedicated /auth-callback page and set this to the redirectUri.

Further to this, I was hosting my statically generated site on S3, using trailingSlash: true so that routing would work. To get onRedirectCallback to fire, I had to explicitly redirect to the index.html.

/auth-callback/index.html

[nickgieschen]

I found another thing which will cause this is if there is an error thrown in your onRedirectCallback function. It is difficult to detect since the error gets swallowed.

[iaminamcom]

In react router v6 you should use navigate and do like:

const onRedirectCallback = (appState) => navigate(appState?.returnTo || window.location.pathname);

It made things working on my side.

[robert-king]

this seems like a bug in the underlying auth0-spa-js since i'm getting the same problem in Angular with LoginWithPopup:

here's a simple repo

login(): void {
this.activatedRoute.params
.pipe(
switchMap(() => this.auth.loginWithPopup()),
first(),
delay(0), <-- with delay(0), isAuth is True, otherwise, isAuth is false.
switchMap(() => this.auth.isAuthenticated$),
switchMap(isAuth => {
debugger;

This shows that isAuthenticated$ gets its True value during the same Tick, but alas, our callback has already run in the same Tick also, unless we add delay(0)

[cnatale]

I was having this problem with Auth0-React in Chrome Incognito/Safari. What fixed it for me was explicitly setting the scope property for the Auth0Provider Component to "read:current_user update:current_user_metadata", and making sure refresh tokens were enabled both at the component level with useRefreshTokens prop and in the Auth0 tenant config. It was a lot of trial and error on my part, and not well documented. Hopefully this will save someone else some time.

[chinthakag]

Sorry. Now, it is working as intended.

If I define the function used in onRedirectCallback outside of FC, it works.

const onRedirectCallback = (appState?: AppState) => {
  Router.replace(appState?.returnTo || '/')
}

const App: FC<AppProps> = (props) => {
  return (
      <Auth0Provider
        onRedirectCallback={onRedirectCallback}>...

I had a similar implementation of the callback function, but still face the same problem. Making the callback function async resolved the problem in my application.

const onRedirectCallback = async appState => { //code };

[hecool108]

Hey guys, I found there is a tip here that said

"When using the Default App with a Native or Single Page Application, ensure to update the Token Endpoint Authentication Method to None and set the Application Type to either SPA or Native."

I am developing a React App with vite. After these steps, it works for me:
1 Add local URL to "Allowed Callback URLs"
2 On "Credentials" section, change Authentication Methods to "None"

[noramichalski]

@hecool108 - Thank you so much for this, I've been trying to resolve this for 2 days now and I've tried EVERYTHING on the internet. 😄 This solved it for me for my React/Vite app. Even though in the "Credentials" section the Authentication Methods SEEMED to be set to "None", it was not until I clicked on the already set "None" word and saved it (there was in fact no change, but the save button got enabled), and this fixed it. This seems like a bug on the Auth0 platform.
@adamjmcgrath if you could look into it. Thank you! ^^

[ghost]

I have fixed this issue on "@auth0/auth0-react": "^2.1.1", with redirectUri. I'm trying to login from /login route on react. So, I added http://localhost:3000/login in Allowed Callback Urls. After this, I fixed my redirectUri with http://localhost:3000/login.

<Auth0Provider domain={auth0Domain} clientId={auth0ClientID} authorizationParams={{ redirect_uri: window.location.origin + "/login" }} >

[josephencila]

Hey guys, I found there is a tip here that said

"When using the Default App with a Native or Single Page Application, ensure to update the Token Endpoint Authentication Method to None and set the Application Type to either SPA or Native."

I am developing a React App with vite. After these steps, it works for me: 1 Add local URL to "Allowed Callback URLs" 2 On "Credentials" section, change Authentication Methods to "None"
Thanks finally working now. was able to fetch the data by choosing CREDENTIAL as NONE.

[Chochek]

One thing which I discovered causes this:

In order for isAuthenticated to get set to true, the function in onRedirectCallback has to get called. I had my redirectUri set to "http://localhost:3000". However, I was redirecting on "/" to "/some-other-page". In other words, the redirectUri was being navigated away from. Apparently, if the redirectUri doesn't get a complete load, the onRedirectCallback fn doesn't get called. I solved in by creating a dedicated /auth-callback page and set this to the redirectUri.

This was my issue as well. Auth0 redirected to '/' and in my app I have logic in the router that redirects to a specific page on load. I added a root path and only redirect when the user is authenticated.