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.