Hitting an error when logging in. We have a dev store setup with new customer accounts and auth0.
We have been able to login successfully with some email. But one in particular isn’t working. I suspect it may be related to the fact that this email signed up both using a password and passwordless on the auth0 side.
Is there anywhere we can find any logging of the error details?
Request ID: 9d3a1519-5b2e-439a-991f-1a63788cceaa-1746621778
Hey @kalen 
- I think you’re correct here and thanks for sharing the request ID there.
The internal error I’m seeing on our end is referring to a “conflicting user” - so I suspect if the the email is connected to logins on both services it might cause that error to pop up.
Would you be able to see if you can replicate this again with a similar email set up (on both Auth0 and password logins)? If you are and can share another request ID, I can take a closer look and look into this with the team.
Hope to speak soon!
Thanks yes I was able to reproduce it with my email kalenj@gmail.com:
Request ID:
11e55d09-8107-43c3-8791-4cf2df5e0f2c-1746712027
Thanks @kalen - I appreciate you replicating again - we’ll get this looked into. I’ll loop back with you here when I have some next steps 
Hey @kalen - are you still seeing this only on one specific store?
Hey @kalen - we were able to do some digging into this and it looks like the two errors there happened for different but similar reasons.
The older example was the “conflicting user” error message I mentioned - that usually happens when a different identifier for the same email address being used in the request is returned by the third party authenticator. Auth0 might be sending a different identifier for the two different login methods using the same email address, so that aligns with what you mentioned in your initial post. That said, we have also seen this error pop up when merchants are testing out a provider and use the same application credentials on multiple provider records. Currently, this set up is shop-specific on our end, but we are hoping to make it provider-specific (which should resolve the error - can’t guarantee a timeline on this though)
The new example is actually a different error message - this one dealing with auth state. That most commonly happens when an authorization sessions has timed out (over 25 minutes) or when you/the client try to authenticate with the same state param (if a specific state token is used up, any subsequent calls using it will fail).
Hope this makes sense - let me know if I can clarify anything on our end here as always!
Thanks it looks like we need to implement auth0 account linking for these two accounts.
Hi everyone,
I’m seeing a similar issue on our end and wanted to check if anyone has more insight. When we click the login button, Shopify briefly shows the “Something went wrong” page. After a refresh, it works, but the error keeps appearing intermittently.
Here’s the screenshot from our test store, along with the application ID Shopify shows:
Application ID : cdf46d94-491d-435c-b12d-704a9667c520-1764935684
Different User,
Application ID: d3a6cb07-848b-44f5-97fc-65f4cb2e01bd-1764931359
At first we thought it might be coming from our identity provider, but our IdP team confirmed there are no error logs and nothing is failing on their side. They also tested the flow and reached the same conclusion. We checked the network call and it looks like the failing redirect is going from our Shopify domain to http://shopify.com/, which points to something internal to Shopify.
Can someone from Shopify confirm why this happens or guide us on what we should adjust?
Here is the IDP Settings in Shopify
After a refresh, we see our desired screen
Happy to share any extra details if needed.
Thanks.
Hey @Alan_G do we have any update on this post? Have you seen my reply post? Let me know otherwise I will create a fresh new post!! Thanks
Hey @Anish_Dalvi - thanks for flagging and for your patience here (I was out of office). I was able to grab some logs on our end and will keep looking into this for you. I’ll loop back once I have a bit more to share 
Hey @Alan_G thanks for replying. Hope you had amazing holidays. Thanks for checking logs and just for your info I have already started a new topic with this post here as I didn’t get response here I thought maybe starting new topic might help but in the end it didn’t. But yes, you can share your findings there once you get them. Thanks and Take Care!
Hey @Anish_Dalvi 
- no worries at all, I was able to do a bit more digging into this, just sharing a bit of what I found.
So from what I can see, when you click login, we may be attempting what’s called a “silent authentication” using the OAuth flow. This is basically checking if the customer already has a valid session with your IdP without showing any UI. The problem is that when there’s no existing session (which is expected for first-time visitors or people who haven’t logged in recently), your IdP correctly returns a 401, but it looks like our fallback handling is causing that brief “Something went wrong” flash before things recover on refresh.
I also noticed the external HTTP call to your IdP took about 1.1 seconds, which is pretty close to our timeout threshold and might be contributing to the intermittent nature of this.
I’ve got a few questions that would help us understand this better. When this error pops up, is it typically happening for customers logging in for the first time that day or starting a fresh session, or does it also affect people who were previously logged in and are returning? Also, where is your Identity Provider hosted geographically? Knowing if it’s in EU, US, or elsewhere would help us understand if latency might be a factor here.
Can you reliably reproduce this by clearing all your cookies or opening the store in an incognito window and then clicking login? That would help confirm what we’re seeing in the logs. And one more thing - has this been happening since you first set up the custom IdP, or did it start more recently? Any changes on the IdP side around when this began would be useful to know. Hope to hear from you soon!
Hey @Alan_G ,
Thanks again for the detailed analysis, and sorry for the slightly delayed response as I was on leave.
Below are our answers, aligned with your questions and in the same sequence:
1. When does the error typically occur?
The behaviour is genuinely intermittent and not limited to a specific scenario. It can occur for:
Users logging in after being idle for a few hours and reopening the store in a new tab
Users logging in again on a different day, even if they logged in successfully before
Both fresh users and returning users
It is not strictly tied to first-time logins or brand-new sessions. When the error does appear, refreshing the page immediately resolves it and the login proceeds as expected.
2. Where is the Identity Provider hosted geographically?
As far as we are currently aware, the Identity Provider is most likely hosted in the EU and is built on Drupal by a separate team. I’m not 100% certain about the hosting details yet and will confirm this with the IdP team once they’re back from the holidays.
3. Can this be reliably reproduced by clearing cookies or using incognito mode?
No, this is not a reliable reproduction path.
I tested multiple times in incognito mode and was not able to reproduce the error there. In incognito:
After logout, clicking login always redirects to the Lannoo Passport login page
Credentials must be entered again every time
The intermittent error appears mostly in non-incognito sessions, where users are often logged in directly without seeing the login page.
4. Since when has this issue been happening?
It has most likely been present since the initial setup of the custom IdP. However, we only actively detected and started investigating it in the past month. Because the issue is random and doesn’t occur consistently, it’s difficult to pinpoint an exact start date.
5. Were there any changes on the IdP side around the time this began?
As far as we know, there were no changes on the IdP side around that time.
Regarding the ~1.1s response time you mentioned: that could indeed be relevant if it’s close to a timeout threshold. We’ve checked with the IdP team and they don’t see any unexpected error logs on their side beyond expected responses, which is why we currently suspect the issue may be related to Shopify’s redirect or fallback handling.
Due to the holiday period, IdP team members are currently unavailable, so I can’t fully confirm all details right now. I’ll validate anything that’s still uncertain once they’re back and follow up if needed. In the meantime, please feel free to continue investigating on your side.
This login flow is quite critical for us, so we’d really like to get this fully resolved before delivery. Thanks again for the support and investigation. Let me know what do you think?
Update:
Today morning when I tried to login in Incognito mode (first session of today). I got that error, as you can see screenshot it’s incognito tab and occurred when I clicked on Login button on frontend.
Hey @Anish_Dalvi - thanks so much for the follow-up and that screenshot, super helpful! Apologies for the delayed response on my end, I’ve been in and out still due to the holidays.
I did some digging in our logs with that request ID you shared, and I found some info that might help. The error message “Discovery document request error” seems to point back at your IdP’s configuration from what I can tell. Essentially, when the user clicks “login”, we need to fetch your IdP’s OpenID Connect discovery document (the /.well-known/openid-configuration endpoint) before we can proceed with the auth flow. In this case, that fetch is failing.
Looking at the logs, I can see the external HTTP call to your IdP took about 1.1 seconds, which lines up with what I mentioned before about being close to our timeout threshold. This would explain why it’s intermittent - sometimes your IdP responds fast enough and login works, other times it’s just slow enough to cause this error.
To help confirm this, could you or your IdP team run this quick test from a terminal if possible?
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nHTTP Code: %{http_code}\n" -o /dev/null -s "https://<your-idp-domain>/.well-known/openid-configuration"
Just replace <your-idp-domain> with your actual IdP URL. If you could run that a few times and let me know what you’re seeing for the Total time and HTTP Code. Ideally we’d want that total time consistently under 500ms.
Also worth double-checking with the IdP team:
Is the discovery endpoint (/.well-known/openid-configuration) publicly accessible without any authentication?
Are there any caching headers set on that endpoint to help with response times?
Let me know what you find and hope to hear from you soon.
Hey @Alan_G! No problem.
Thanks for digging into this. This is very helpful.
I ran the curl test you shared multiple times from my side against the discovery endpoint. The results were inconsistent (see screenshot for more details):
The first request took around 5.7s total (TTFB ~5.7s, HTTP 200)
Subsequent requests were faster but still around 520–580ms total
So the discovery endpoint is publicly accessible and consistently returns HTTP 200, but the response time is not stable, and the first request in particular is significantly slower.
To answer your questions:
Is the discovery endpoint publicly accessible without authentication?
Yes.
Are there any caching headers set on that endpoint?
This needs confirmation from the IdP team. I’ve shared these findings with them so they can review the response time and caching behavior on the /.well-known/openid-configuration endpoint.
I’ll follow up once I have more details from their side. Thanks again, this aligns very well with the intermittent behavior we’re seeing.
Hey @Anish_Dalvi , thanks for running those tests
That 5.7s first request seems like it could potentially be a “cold start” situation. I can’t say for sure, but just basing this on previous personal experience where an idle cloud deployed system has gone into “waiting mode” and its initial API responses are slower as it comes back “online”.
When you chat with your IdP team there, I think I’d mention a potential cold start latency (common fixes include keep-alive pings to the discovery endpoint, or provisioned concurrency if they’re using serverless infrastructure), and making sure they have aggressive caching headers on the discovery document if possible.
Ideally you want that discovery endpoint responding consistently around 500ms or so to give comfortable headroom, even after sitting idle for a while.
Let me know how it goes with the IdP team or if I can help out further as always.
Hey @Alan_G ,
Thanks a lot for digging into this and sharing your insights, this was very helpful.
I wanted to update you after checking with our IdP team. They’ve confirmed that this behavior does indeed occur during a cold cache scenario, especially on the current shared hosting setup when it’s under higher load. This aligns well with your cold-start theory and explains the slow first request we observed around ~5.7s.
They also confirmed that this should not be an issue in production, as it will run on a dedicated instance with more capacity. In addition, they’re reviewing and tightening the caching headers on the /.well-known/openid-configuration endpoint to help stabilize response times.
Thanks again for the detailed analysis and suggestions, it really helped us pinpoint the root cause. I’ll keep you posted if anything changes.
Take Care Man!
