I’m trying to implement logout with the returnTo parameter, but the behavior around the validation of the returnTo parameter doesn’t seem to match the documentation: Redirect Users After Logout
I’m specifying a returnTo parameter, without a client_id, so I would expect the validation to occur based upon the tenant settings. The returnTo parameter I’m providing is something like “https://subdomain.website.com?loggedOut=true”, and the allowed logout url at the tenant level is “https://*.website.com”. When I actually try to log out, I get an error saying the logout url isn’t listed for the application settings. That doesn’t match the documentation, which states it validates against the tenant settings.
After I updated the application settings to match the tenant settings (allowed logout url is “https://*.website.com”), it still gives me the same error. The only way I’m able to get past this error is to actually specify the exact URL at the application and tenant level, i.e. “https://subdomain.website.com?loggedOut=true”. This is contrary to the documentation which says wildcard is allowed, and query parameters and fragement are ignored, and that it only validates at the tenant setting if the client_id is not provided.
Can someone please clarify/confirm the exact behavior of the allowed logout urls, or if there’s something in my configuration I’m missing?
Hey there @amisson, I would be happy to help on this front.
When you get a chance I would like to follow your suggested workflow via a HAR file capture. Please record a har file of the logi flow and redirection, be sure to select “Preserve log” to catch redirects and scrub the file of user passwords before sending it in a direct message, thanks!
I replied to your message, but I’ll paraphrase here as well. The issue is not with the login flow, but the logout flow. The error is coming from the allowed logout url validation after redirecting from the identity provider after the user has been logged out there. The url validation in auth0 doesn’t seem to follow the documentation, where wildcards are respected, and the query parameters are ignored. The configured logout url in the application in auth0 is “https://*.example.com/path/”, and the redirect uri coming back from the identity provider after logout is “https://subdomain.example.com/path/?param=true”. This should match and be allowed, but the 400 error indicated in the .har file shows it is not.
After talking with another Engineer concerning this topic, it was determined that this should be added to your Allowed Logout URLS, please add this when you get a chance.
Can we get a code snippet of your login/logout code?
In event this does not resolve the challenge, we could benefit from having a fresh full authentication flow HAR file capture along with verification on the exact application name so we can better target our efforts effectively. Thanks in advance!
Since this is still an ongoing issue @amisson, can we please reach via direct message a new HAR file to continue the investigation on the breakdown? Thanks in advance!
I wanted to follow up after talking with a senior engineer on this HAR file that was sent over. I was able to confirm that this is not standard procedure when handling a logout session as described by our documentation below.
However because this is a long running challenge you are facing, I would be happy to open a support ticket for you in regards to this front if you would prefer to move towards this route. Please let me know if you have any questions. Thank you.