I am using Auth0 as SP and Okta as IdP.
I have SAML connection configured with signout enabled.
Login is working fine. When I logout from app, its supposed to logout of Okta and then redirect back to URL as provided in returnTo query param in the logout request. I have also configured returnTo URL in Allowed Logout URLs.
Web app is sending logout request to Auth0 and Auth0 sends SAML logout request to Okta and then Okta responds with POST request to /logout API.
Problem is Auth0 is not redirecting to returnTo URL. Instead it displays OK response.
I even turned on debug Mode on SAML connection. Only success logout entries are logged. No errors are logged. So, I think its not a problem with configuring Allowed Logout URLs.
This is not the first time I am configuring this connection. This logout flow used to work. Today I noticied this issue. What’s strange is that I have similar issue on different Auth0 tenant which was working as well.
Yesterday morning we started seeing this issue in all of our tenants and we are certain that they were working as expected previously. We have not changed any configuration in the tenants or code that integrates with Auth0.
Not sure how to proceed with troubleshooting at this point.
Just found that we can get it to work by specifying allowed logout urls on the tenant level. Still trying to figure out why this is required since we have them on the application level with the client id specified in the logout.
Investigated further and unfortunately using the setting on the tenant level doesn’t solve the problem since redirect is then happening to the first listed url in the setting, not to the url we pass as returnUrl
I have submitted a support ticket and provided har file. This is the reply I got from them.
“Thank you for the har file. I have shared this information with our engineering team and they are looking into a change that was released on January 18th that they believe may have lead to this issue. I will provide another update on their investigation as soon as I hear it, or by Friday at the latest.”
We opened a support ticket earlier this week and after a few days of supplying logs and investigating on our side were told that the engineering team had identified the error in Auth0 and was working on a fix. We haven’t received any info on the timeline for when the issue will be fixed
Our support ticket was closed and the only information we got was that there is no ETA for the fix. The internal ticket number is SES-2453 but we will no longer receive any updates on the progress since our ticket is no longer active.
We have received this reply on support ticket today.
“I just wanted to provide an update that our engineering team has the fix for this issue in review and will hopefully be released before the end of the week. I will provide another update by then if not sooner for when we have it released.”
Couple of days back Auth0 support replied back saying fix is deloyed. But when I checked today, I still see the same behaviour. I replied back to Auth0 support about this.
This is the reply I received
“I apologize for the disruption again. Our engineering team discovered an issue with the fix that was released and they needed to revert the changes made in the fix. They are at work addressing this and now, and I will provide updates on their progress as I hear them.”
I got this update yesterday from Auth0 support
"I just wanted to provide an update that our engineering team is in progress on developing a new fix for this issue, though I do not have an ETA at the moment. I apologize for the delay in getting this issue resolved and will provide another update before the end of the week if not sooner. "
"I have an update from our engineering team regarding this issue that I wanted to share:
First be assured, this is currently our highest priority work item and Sessions team has been working to resolve the issue as quickly as possible. Whilst seemingly simple on the surface, the fix for this issue has proved much more complex than initially understood. Typically in a case such as this we would just revert the original change however in this case the option to revert the change that originally caused the issue has negative security implications.
In terms of ETA, the fix that has been developed is still yet to be merged due to concerns during the review process, though the current estimate is for the rollout of the fix to begin on April 2nd, reaching public cloud environments over the week following.
We sincerely apologize for the disruption this issue has caused and the time it took to work through the issues in getting a fix together. I will provide updates at the end of the week or as I get them going forward. "
@kteja@magnus.bergquist sorry for bothering you again (I believe it should be someone from Auth0 who updates this thread, but well :() but do you have any further updates? It’s been almost a week after 2nd of April, so I’m curious if the fix has been rolled out.
“It looks like the release with this fix is tentatively scheduled for Tuesday of next week for your environment. I’ll provide updates next week again with the status of the release.”
We received the fix in our tenants yesterday and it resolved the issues.
But to receive the fix some internal feature flag had to be enabled on our tenants by Auth0. Communication from Auth0 support says that this flag will be enabled for all tenants later this week.
