Logout with date query params

[DawnMD]

Checklist

• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

This is particularly for NextJS SDK. Other SDK may also have this but cannot confirm.

It’s frustrating when we need to add exact pathname and query params when logging out of any application specially web application. We have a booking commerce website where the user can login after they do search. On searching, query params like start_date, end_date is added to the query params as we are maintaining the states in the URL itself. But Auth0 doesn’t allow dynamic pathname, nor dynamic params.

We also have more than 500 product page considering the locales as well and putting every url to the allowed logout urls is a mess. Also it’s a mess when we consider that we cannot pre determine the query params the users can have.

Describe the ideal solution

It would be really good if we don’t have any restriction on the redirect url after logging out so that the sdk will redirect from the page the user applied logout from.

Even if that’s not possible, atleast not restrict them on query params because it’s quite tedious and makes no sense validating the state params to auth0

Alternatives and current workarounds

As of now the current alternative is to create a page which return null but redirect the users based on the url stored in local storage which imo is a flaw in the UX and flow.

Additional context

No response

[druwadi]

We too are running into this, wondering if there is a better solution since you can't wildcard query params for logout urls

[seanparmelee]

Perhaps a config option to control whether the logout route uses the OIDC or Auth0 (/v2/logout) endpoint?

[fezheng397]

@seanparmelee That would work, but I was curious if that's already controlled by the logic in lines 373->390 here? I'm unsure if there's anywhere we can print the authorizationSeverMetadata object in our app to check for end_session_endpoint but our tenant looks like it has the RP-Initiated Logout End Session Endpoint Discovery setting off, which i had thought would control this value.

This issue started ~2 days ago for us without any code change ("@auth0/nextjs-auth0": "^4.0.2") so we weren't sure if logic under the hood has changed.

[seanparmelee]

This issue started ~2 days ago for us without any code change ("@auth0/nextjs-auth0": "^4.0.2") so we weren't sure if logic under the hood has changed.

Same exact thing happened to us!

I had used the management API to double check our tenant settings (https://auth0.com/docs/api/management/v2/tenants/tenant-settings-route) and didn't see an oidc_logout entry so I:

1. Toggled "RP-Initiated Logout End Session Endpoint Discovery" on via the dashboard
2. Clicked Save
3. Toggles "RP-Initiated Logout End Session Endpoint Discovery" off
4. Clicked Save

Then when I re-queried the tenant settings, the response included

  "oidc_logout": {
    "rp_logout_end_session_endpoint_discovery": false
  }

and nextjs-auth0 started falling into the !authorizationServerMetadata.end_session_endpoint block again.

The "The Auth0 client does not have RP-initiated logout enabled" warning is a bit annoying though because we purposely want to use the /v2/logout endpoint since we need to pass some dynamic query params in the returnTo URL when logging out.

[fezheng397]

That was extremely helpful, thank you so much!

This worked on our staging tenant but isn't fully doing the trick on production, so there must be something else too. We're at a point now where querying both gets us

"oidc_logout": {
"rp_logout_end_session_endpoint_discovery": false
}

In production for some reason, it still ends up hitting /oidc/logout regardless - I'll update if we figure out why.

[seanparmelee]

@fezheng397 good to know; I'm curious to hear what you find out as we're not quite in prod yet with v4.

[fezheng397]

@seanparmelee Ended up being some sort of caching issue as after a fresh deploy, it's now working and hitting /v2/logout! For what it's worth, our app sits behind Fastly but we generally send no-cache equivalent headers.

[fezheng397]

@seanparmelee We had contacted Auth0 dev support as well and they got back to us today there was a code change on their end that had caused this. They mentioned that the issue isn't related to your individual Auth0 tenant's configuration, but I'm still glad you had figured out this solution line for the scenario.

They confirmed they're in the process of rolling it back so wanted to give you an update!

[DawnMD]

This issue started ~2 days ago for us without any code change ("@auth0/nextjs-auth0": "^4.0.2") so we weren't sure if logic under the hood has changed.

Same exact thing happened to us!

I had used the management API to double check our tenant settings (https://auth0.com/docs/api/management/v2/tenants/tenant-settings-route) and didn't see an oidc_logout entry so I:

1. Toggled "RP-Initiated Logout End Session Endpoint Discovery" on via the dashboard
2. Clicked Save
3. Toggles "RP-Initiated Logout End Session Endpoint Discovery" off
4. Clicked Save

Then when I re-queried the tenant settings, the response included

  "oidc_logout": {
    "rp_logout_end_session_endpoint_discovery": false
  }

and nextjs-auth0 started falling into the !authorizationServerMetadata.end_session_endpoint block again.

The "The Auth0 client does not have RP-initiated logout enabled" warning is a bit annoying though because we purposely want to use the /v2/logout endpoint since we need to pass some dynamic query params in the returnTo URL when logging out.

This was extremely helpful, did the exact thing mentioned and it worked like before 🥳

Thank you 🙏🏼

[seanparmelee]

@fezheng397 Thanks for the update! Glad they were able to identify the root cause.

As a side note for anyone else that might be using Terraform to manage their auth0 configuration, auth0/terraform-provider-auth0#1192 was recently merged so we'll soon be able to explicitly disable this option via Terraform.