Hi all! If we are using auth0 as our OIDC provider for GoodData.UI, then should we use the JWT auth provider for the

AnalyticalBackend

to authenticate users instead of the redirect context?

Hi Kyle, This kind of depends on how you are implementing your provisioning and access. Are you working with an embedded environment? Essentially, what is best for your solution?

I think I finally figured it out. Setup: 1. A single Auth0 application that we use for OIDC with GoodData and for our NextJS application 2. Whitelabeled domain with GD so https://dashboard.example.com 3. App is deployed to https://app.example.com Initial problem: 1. Login via auth0 into the app 2. Display an InsightView or similar 3. If we are logged-out of GD, then we are automatically redirected to login via tiger factory with

redirectToTigerAuthentication

setup 4. This double-auth0 challenge is not ideal from a UX perspective Solution: 1. When a user logs into our app, we send them to the GoodData login instead of Auth0. e.g https://dashboard.example.com/appLogin?redirectTo=https://app.example.com 2. This generates a oauth state and code with GD which then redirects to Auth0 3. On successful login via Auth0, it redirects first to GD to log us in (https://dashboard.example.com/login/oauth2/code/dashboard.example.com?code=X&state=Y) 4. Then it redirects to https://app.example.com 5. Since the auth0 login drops the auth0 cookies/session on the same domain (example.com) our NextJS application can pick those up and logs us in

Hi Kyle, you should be able to use

backend.deauthenticate("<https://example.com>");

, but you must be using SDK v10.6 (or higher)

@Joseph Heun thanks! do you have any documentation or a link to the source?

the documentation we have on this is located here: https://sdk.gooddata.com/gooddata-ui-apidocs/vNext/docs/sdk-backend-spi.ianalyticalbackend.deauthenticate.html

my feeling is that it has something to do with OIDC with Auth0. Because I see it trying to redirect to

<https://auth.example.com/oidc/logout>

which includes a

post_logout_redirect_uri

that is pointed at

<http://dashboard.example.com|dashboard.example.com>

instead of the

returnTo

specified

Heya Kyle, Radek here! 🙂 You're right that the returnTo in the URL isn't being considered here - the URL needs to be set specifically with the deauthenticate method (as in the example Joe mentioned before), and it also needs to be set as allowed in Auth0 for the redirect to work properly.

@Radek Novacek i did try both and still seeing the same issue. i'll try again though with a different strategy

Fingers crossed, we added this in 10.6 specifically due to a different customer having issues with the Auth0 returnTo parameter (and well, the fact that I think by default we go back to the root path of the URL), so if it doesn't work out, please do send a code snippet my way and I'll consult with the devs 🙂

@Radek Novacek sorry for the delay here, i updated to 10.6 and I am still getting the same issue. I am using

backend.deauthenticate(currentUrl)

and I can see a call to

<https://dashboard.outburstdata.com/logout?returnTo=https://applocal.outburstdata.com/>

but the Location header returned from that call has the following URL param

post_logout_redirect_uri=<https://dashboard.outburstdata.com>

when i would expect it to be

post_logout_redirect_uri=<https://applocal.outburstdata.com>

Heyo Kyle, likewise, apologies for the delay - do you think you could add a HAR file to this (ideally over DM) so that I can see into it a little more and be able to share with the devs that implemented the returnTo if needed?