Hi Team, I am testing using Auth0 as the custom OIDC IdP for Gooddata in a trial account before implementing in our production tenant. Everything seems to be configured correctly but I am getting a 404 when receiving the authorisation code back from Gooddata. Is there any restriction on using a custom identity provider login in a trial environment?

Thinking completed In GoodData trial environments, switching to a custom OIDC identity provider typically requires enablement from GoodData (often requested via your Account Manager) [Community Slack]. By default, trial environments use GoodData’s managed Auth0 provider, and configuring a custom IdP without the proper organizational entitlement or configuration can lead to authentication failures [Known limitations; Community Slack]. When you receive a 404 during or immediately after the callback/authorization exchange, it is commonly caused by one of the following: 1. Missing or Mismatched `authenticationId`: After authentication with the IdP, GoodData looks up the user based on the subject claim (the

sub

value in the ID token) [Use Amazon Cognito as Identity Provider; Community Slack]. If the user is not provisioned in the GoodData organization or the

authenticationId

attribute does not match the exact Auth0 user ID (

sub

claim), GoodData returns a 404 ("User is not registered" / endpoint does not exist) [Community Slack; Community Slack]. 2. Missing Trailing Slash in `oauthIssuerLocation`: For Auth0 specifically, the

oauthIssuerLocation

URL must include a trailing slash (e.g.,

https://mycompany.eu.auth0.com/

), otherwise the OIDC discovery/token exchange fails [Known limitations]. 3. Callback / Redirect URL Configuration: Verify your Auth0 Allowed Callback URLs. If an

oauthIssuerId

was specified when creating the IdP entity, the callback format should behttps//your-gooddata-domain/login/oauth2/code/oauthIssuerIdIf no

oauthIssuerId

is defined, it defaults tohttps//your-gooddata-domain/login/oauth2/code/organization-hostname[Create, Read, and Delete the Identity Provider Object] Getting Further Assistance If your configuration appears correct and the issue persists, resolving the specifics requires a GoodData Support team member to review the backend logs and your trial organization setup. To help the Support team investigate, please add the following details to this thread: • The affected organization URL / hostname • The email address of the user attempting to log in • The exact

traceId

from the 404 response payload or headers • Whether your custom IdP was switched via the

switchActiveIdentityProvider

endpoint or configured through Multiple OIDC (MOIDC) Support Options: • Community support (Startup & Professional): You are already in the right place. The GoodData Support team monitors this Slack community and a team member will step into the thread as needed, so please keep the discussion and post the requested details directly here. You may also consult the Community Forums. • 24/7 Support (Enterprise plans): If your account tier includes 24/7 Support or this is a Severity 1 (L1) critical issue, direct support options are available in addition to this thread by submitting a ticket, emailing support@gooddata.com, or calling +1 (415) 200-0194. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

- Organization URL/hostname: petty-robin.trial.cloud.gooddata.com - traceId: 799790e7fa8a921aecb1bfb7883f3b76 - Switched via switchActiveIdentityProvider? Yes — confirmed, our script calls POST /api/v1/actions/organization/switchActiveIdentityProvider {"idpId": "auth0-shared"} and it succeeded. - Email address of the user attempting to log in: ga-kjenneke@cypheragency.com.au

Hi Kieth, related to this Trace ID:

799790e7fa8a921aecb1bfb7883f3b76

). the problem is on the token itself: the ID token Auth0 returns is missing the

email

claim, even though GoodData explicitly requests it (scopes:

openid profile email ...

). GoodData treats

email

as a mandatory claim and rejects the login right at that step — which is what’s showing up as a 404 on your end. This is a config issue in your Auth0 tenant rather than ours — A couple of things worth checking on the Auth0 application: 1. Is the

email

scope still granted/enabled on this application? 2. Do you have any Post-Login Actions or Rules that might be modifying or stripping claims from the ID token before it’s returned? 3. What connection type is

<mailto:ga-kjenneke@cypheragency.com.au|ga-kjenneke@cypheragency.com.au>

logging in through, and does that user have a verified email on file? Some connection types (passwordless, certain enterprise/SSO connections) don’t populate an email attribute by default. Once

email

is reliably present on the ID token, this should resolve.

Hi @Michael Ullock, thank you. I have made sure that the email is enabled is being sent and now I am getting { "detail": "An unexpected error occurred. Use traceId for diagnostics.", "status": 500, "title": "Internal Server Error", "traceId": "0104e255cba745759eaeead9071d9ad8" }

Hi Keith, thanks for the update. TraceId 0104e255cba745759eaeead9071d9ad8 shows login is failing because GoodData is trying to assign you to a user group with id “All Users” — that looks like a group display name, not a group id. GoodData requires the actual id here, which can only contain letters, numbers, periods, underscores and hyphens (no spaces), so it’s rejecting the login. That value could be coming from either of two places on your side: 1. The urn.gooddata.user_groups claim your Auth0 Action/Rule adds to the ID token, or 2. Your org’s JIT provisioning userGroupsDefaults setting (used as a fallback if that claim isn’t actually present in the token). Could you check both and confirm which one has “All Users” in it? Either way, the fix is to replace it with the group’s actual id (look it up via GET /api/v1/entities/userGroups), not its display name. Please retry after that, and send us a new traceId if it still fails.

Thanks @Michael Ullock. I am not able to log in thank you. One final, question what it the best way to handle redirecting users to a specific workspace when they have multiple workspaces

i Keith, glad that’s resolved! On redirecting users to a specific workspace: GoodData doesn’t let you force a workspace server-side, but you can control it from the entry point. Have users log in via a link with a

redirectTo

parameter pointing at the workspace you want them to land in, for example:

https://<your-org>.<http://cloud.gooddata.com/login?redirectTo=/workspace/<workspaceId>/dashboards|cloud.gooddata.com/login?redirectTo=/workspace/<workspaceId>/dashboards>

This ensures they land in that specific workspace/app path after authentication, regardless of where they started. More detail here: OIDC Authorization Code Flow – Redirect URLs