RedirectUri has been verified to be correctly added and protected in the Lock context’s state.
But looking at the GET headers from your Lock to your /authorize endpoint, the referer is simply “/” - missing the path. So when you callback, the location header to forward to is similarly root - instead of the controller path encoded initially in the Lock state.
Seems to be good for weeks, then suddenly it starts happening, meaning I simply can’t authenticate. I’m equally unsure as to how it starts working again days later. Cookie state, IISExpress quirk with Lock - any suggestions? When it works, I see the controller path correctly being sent to you, and coming back.
Seems to happen more on localhost deploy, but we’ve suffered this for about a year with no time to investigate deeply. We’ve seen similar on a deployed IISExpress website.
Happens on the two browsers I’ve tried - Chrome and Edge. I’ve stepped through lock.js as much as I can, but I guess the protected state is decoded by the browser code.
Code showing setting of RedirectUri: (.NET Core 1.1)
var properties = new AuthenticationProperties()
{
ExpiresUtc = options.SystemClock.UtcNow.Add(options.RemoteAuthenticationTimeout),
IsPersistent = true,
RedirectUri = returnUrl ?? "/" // E.g. /MainMap
};
lockContext.State = Uri.EscapeDataString(options.StateDataFormat.Protect(properties));
Hey there @Simon! I would be happy to take a look at this with you. When it’s in it’s unworking state, would it be possible to snag a HAR file for us and direct message it over to me? Please be sure to select “Preserve log” to catch redirects and scrub the file of user passwords before passing it over, thanks!
Reviewing the HAR file with one of our Senior team members we are seeing the authorization successfully complete through the captured workflow where Auth0 is involved. Is it possible there is a breakdown after that point within the application code? We don’t see any direct errors on our side of things to feed off of. We are happy to help but we need a bit more to go off of. Thanks.
My mistake in thinking was that the Location header to redirect to was being sent in the callback from Auth0. Which of course it isn’t - it’s how my local IISExpress server responds to your callback.
Knowing that - I indeed found an OpenIdConnect event happening after successfully authorizing from Auth0: “IDX10803: Unable to obtain configuration from: ‘https://my auth0 domain/.well-known/openid-configuration’.”. Which redirects to root.
I then wondered if my firewall was blocking some other process accessing this file. Turned it off and things are working. I couldn’t find what in particular the firewall was blocking.
Based on our experience, these steps can help troubleshooting OpenID login issues.
Are you behind a proxy or firewall? OpenID requires very long URLs and proxies / firewalls with aggressive settings will sometimes block OpenID accidentally. This has been documented a bunch of times, often in corporate settings. If so, try without the proxy/firewall – or convince your network admins that OpenID is in fact safe to allow…
I haven’t a good knowledge of OpenID at all to know if this is related (I’m thinking not), but I’ll just turn off the firewall when developing locally.
I don’t mind at all - things like this are horrible to come across and appreciate your help.
It was simply Windows 10’s built-in Advanced Firewall, which I aggressively block everything in and out, however have it let me know when something is trying to get out so I can make an exception for it.
I have exceptions for everything I know of that is related, but it’s either there’s some firewall issue like noted above or I’ve missed something.
If I come across the particular port or process being blocked, I’ll post.
Thank you so much for the feedback @Simon and I’m glad it all came together in the end! Please let us know in the future if you run into any hurdles or questions that we can assist with!