Hey team, I’m getting an

500 internal server error

after login. The trace ID for this is

3f8c931a8911db651f49976e13f2836c

. Everything worked untill today. Can you analyze, what occured in our call? We use third party OAuth provider. API calls work fine. Thanks a lot.

I'm sorry, but I'm not able to directly access GoodData's internal logs or analyze specific trace IDs — that capability is only available to the GoodData support team. However, based on similar cases in the community, here's what's likely happening and what you should do: Likely Causes for a 500 Error After Login with a Third-Party OAuth Provider 1. Misconfigured OAuth2/OIDC client — An incorrect endpoint in your OAuth2 client setup (e.g., using a wrong

orgId

in the PUT call) can cause authentication failures. [OAuth2 setup issue] 2. Broken `authId`/OIDC identity mapping — When user provisioning changes are made, the

authId

or OIDC identity mapping can become broken or mismatched, leading to errors even for admin users. [Unknown Error cases] 3. Temporary platform issue — Some 500 errors are caused by brief, transient service disruptions on GoodData's side that resolve on their own. [Short outage fixed] What You Should Do Next 1. Contact GoodData Support at support.gooddata.com and provide: ◦ Your organization URL ◦ Your login email ◦ The `traceId`:

3f8c931a8911db651f49976e13f2836c

◦ A description of any recent changes made to your OAuth/OIDC configuration ◦ Whether the issue affects all users or just specific ones 1. Check the GoodData status page at support.gooddata.com for any active incidents in your region. 2. Try basic troubleshooting in the meantime: clear browser cache, try a private/incognito window, or a different browser. The

traceId

you've already captured is exactly what GoodData support needs to pinpoint the root cause in their logs. Since this involves a third-party OAuth provider, support may need to inspect your OIDC configuration or user identity mapping on the backend. [OAuth2 setup issue] 👍 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.

Hi Ondrej, I'm looking into this issue.

When I was setting OAuth up in PUT: /api/v1/entities/admin/organizations/ I put here: "oauthIssuerLocation": "https://oas.xxx.cz/f5-oauth2/v1/". In .well-known/openid-configuration there is "issuer":"https://oas.xxx.cz/f5-oauth2/v1/" But in jwt token I see "iss": "https://oas.xxx.cz/" But this setting has not changed. Do you think this could be causing it? Thanks in advance.

Yes, it could be the problem, but I can't pinpoint the root cause. From the logs, we can see the problem with your provider, and it could be related to a mismatch in

iss

in your

idToken

. Could you double-check it? Also, please let us know how critical the question is for you.

It's quite crucial, but we will change iss in jwt at first. I will inform you. Thanks a lot for now! To your question: Nobody can connect to our enviroment.

Hi Ondrej, please keep us informed if these changes on your end have resolved the issue. If not, we will verify everything on our end and get you back and running.

Hey Ondrej, I have asked our technical engineers about the issue and here is there conslusion: Your IdP is issuing JWT tokens where the

iss

claim doesn't match the

issuer

value that comes back from your OIDC discovery endpoint — and that mismatch is exactly what's triggering the "JWT iss claim value rejected" error. Here's a quick way to confirm it on your end: 1. Pull your OIDC discovery document and grab the issuer:

curl https://<your-oauthIssuerLocation>/.well-known/openid-configuration | jq .issuer

2. Decode one of the JWT tokens your IdP issued and check the

iss

claim:

echo "<token_payload_part>" | base64 -d | jq .iss

(The payload is the middle segment of the token — the part between the two dots.) 3. Compare the two values — they need to be identical. The

issuer

from the discovery document (step 1) and the

iss

claim in your token (step 2) have to match exactly. Even a trailing slash difference will cause this to fail. The fix itself needs to happen on the IdP side — whatever is generating those tokens needs to set

iss

to exactly the same string that appears in your

.well-known/openid-configuration

. This is actually a hard requirement per the OIDC spec (section 3.1.3.7), so there's no workaround on our end. Once you've identified what the two values are, send them over and we can help figure out what needs to change in your config. I hope this will help you. If not, please let us know.

Thanks for your analysis. But can you say why it stops working yesterday? Otherwise, can you please check traceId: afafadfe6e8d7b8feade97ea93d49f31? Because REST API stop working when I tried to change provider to one with correct iss. So I cannot do anything now. Thanks.

Hey Ondrej, I can see this error:

Failed to fetch OIDC configuration from https://...

I will send you the domain via DM, but let's continue the discussion here so my colleagues can follow it too.

All our other applications work. I am confused, than Baerer token doesnt work now. How to set another provider if I cannot push anything? Can you restore version or provider?

I have asked our engineers, and they have temporarily disabled a new OAuth flow. Could you please try to send your API request again?

Thanks a lot! I call {{baseUrl}}/api/v1/actions/organization/switchActiveIdentityProvider again with previous provider not working id { "idpId": "jhqye8tije" } And it works now. Like a magic... fyi: iss from jwt: "https://oas.edogroup.cz/" and issurer from .well-known: "issuer":"https://oas.edogroup.cz/f5-oauth2/v1/" ant it works. I really appreciate your patience with me! Thanks a lot.

Thanks for the update, glad to hear everything is working! Does this mean the login issue is resolved, or do you need further assistance?

Issue is resolved. Users can login. But we didnt do any change in provider credentials...

Good to hear that. Could you please check all the steps from my message above? https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1776771983054849?thread_ts=1776691937.356399&cid=C04S1MSLEAW We will remove the old functionality soon, and it won't work for you anymore. So you need to set up the IDP correctly to fix it for the new functionality.

Hi Shamill, It works, so I'm afraid to mess with it. Because we have only one gooddata environment it has to be connected with maintenance shutdown. And there is probability that I lost API control again, if there will be problem with OAuth provider (as we deal with it on Thuesday). I can't risk it.

Hello Ondreji, I am afraid that it will start eventually failing on you because we cannot keep the exception forever on. But I understand your worry. Can you please check for us the details? it does not require any change right now, we will use the info you gather and help you with planning of the update.

Hi Ondreji, We will have to fix your OIDC configuration. Otherwise, it will break again quite soon. Let me explain why it's needed and why it broke last week. Then we will find a way to fix it safely and painlessly. 1. The OIDC specification explicitly requires "that the Issuer MUST exactly match the

iss

Claim". (See here and here.) It's a hard requirement of the standard. Ignoring this requirement is a security gap (it opens token substitution attacks). 2. We did not previously enforce this requirement. Your config worked perfectly OK without it. However, we are now migrating to a new, more secure Gateway implementation. This new implementation enforces the requirements. When we switched to this new Gateway, your organization came up as problematic. So we configured an exception for it. Your org still uses the old Gateway. However, the old Gateway is going to be switched off in a couple of weeks. 3. In your situation, the Issuer in the OIDC discovery document doesn't match the JWT's iss claim. It is very unlikely this is an intentional configuration. • Can you please verify which of the two different Issuers is the correct one? The one with the suffix or the one without? That should tell us which part needs fixing. • Can you also verify that your IdP configuration in GoodData is pointing to the right discovery document URL? It is possible that it simply points to an incorrect

.well-known

endpoint than where the tokens are actually issued from. If that's the case, the fix should be very simple. • Please talk to whoever configured your IdP. The difference in Issuer IDs is definitely not intentional. (Since you use a proprietary IdP, it is difficult for us to estimate what exactly is wrong in its setup.) Please let me know. (Note: if you want to share any sensitive information, switch to a DM.) Kind regards, DaN Stourac, Sr. Technical Support Engineer, GoodData

Hi Ondreji, This is Moises, I've taken on this case as Daniel is currently on PTO. In case you have shared anything privately with him, please feel free to redirect it to my DM. Otherwise, please feel free to let me know if you have any questions or concerns in the meantime.