The issue happens with any kind of login being used in Auth0 whether Google or Linkedin to sign in it works fine in a normal Browser but not in incognito
Video showing how it behaves in incognito is as below
This works fine in a normal browser
Pl use the link to try it by using LinkedIn login
https://linkedin-app-dev.azurewebsites.net/
Regards
Vinita
The video shows an authorization code (a different one) being returned to what’s likely the application configured callback URL. Given that after you authenticate there’s a session established in the Auth0 tenant/domain which may be reused for subsequent login requests the most likely reason for this situation is the client application logic having an issue that prevents it from completing the login flow and because of that redirecting again to login.
The loop is triggered because the application continuously redirects to login while the Auth0 tenant domain continuously responds with a success response as the user already authenticated and a session exists.
Given this is triggered by something the application logic does in order to troubleshoot this you will need to review the application logic itself. A good starting point would be to capture an HTTP trace of a working login and also of a failed one (the loop thing); once you have that you would do a comparison check to see if there’s anything different at the network level (for example, are there cookies present in the requests associated with the client application in the working one, but not in the failed one).
@jmangelo Our implementation is with Angular and auth0. We followed the same steps given https://auth0.com/docs/quickstart/spa/angular2/01-login and used the same code template handleAuthCallback for handling callback, nothing extra is added there. During debugging this, I found that, the redirect callback handler handleRedirectCallback of SDK doesn’t complete the the redirect flow and redirects to login again which cause the loop cycle.
Thanks,
Arun
Also note that this same code works in normal browser but not in incognito
Can you pl check and advise again?
The best way to review this would be with live debugging like it has been mentioned. In particular, trying to understand why the redirect callback handler does not complete as expected in incognito. There isn’t any messages printed to the console?
Also does this only happen with the LinkedIn connection or it’s the same if you try username/password login? If it happens with username/password would it be possible for you to share test credentials?
Hey,
We have the same issue.
We use @auth0/auth0-react 1.4.0 to protect our SPA with login.
All works in Firefox(regular and private window) and chrome(regular window). only the chrome incognito is failing inside the auth0-provider.
This failure happened the first and the second time. Now there is only infinite redirecting.
Is there any development, maybe in another issue?
Best, am
Actually just discovered this thread after creating my own. I’m experiencing the exact same issue.
React + auth0-react v1.4.0
Works fine in Firefox (regular/private), chrome (regular), but broken in incognito!
Update: I’ve managed to isolate the infinite loop in a separate react-app. Hopefully the auth0 guys can spot the issue and it’ll provide a solution to the people in this thread too.
Also having the same issue in a react app but using v1.15.0 of @auth0/auth0-spa-js
Same issue here, happens on chrome incognito but oddly enough not in edge incognito.
We are having the same issue with @auth0/auth0-angular 1.5.0 and @auth0/auth0-spa-js 1.5.0. Everything works fine in edge and firefox but fails in chrome incognito. It would be nice to get some attention on this.
EDIT: In my case it was beceause I was calling getAccessTokenSilently() before handleRedirectCallback() finished.
Circling back, can’t remember where I saw it suggested but I changed my cookie settings and it works no problem
Thanks for sharing that with the rest of community!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
