Generic OAuth Provider: Silent error after successful callback from provider

Deathwhisp · 2025-12-04T09:04:59.323Z

Hello, We've started to implementing auth based system on zitadel for role/access management on our app however recently we found an issue with custom oauth provider causing "An error occurred while trying to login." We're running self hosted ZITADEL version: v4.2.0 (Helm chart 9.13.0), oauth configured as: - Auth method: client_secret_basic with PKCE enabled - Scopes: openid, email, offline We've tracked that the oauth is able to go to the provider, and get the auth code, but then it fails with error mentioned earlier without any logs even on debug level set. Looks like it might be related to one of: - https://github.com/zitadel/zitadel/issues/11065 - https://github.com/zitadel/zitadel/pull/11070 but our case have very different config so not sure if this is related, as we're not experts in Zitadel tweaks. So the questions are basically: 1. Why would ZITADEL fail before calling the token endpoint? What could cause this silent failure? 2. How can we enable more verbose logging for the Generic OAuth flow to see what's happening internally? 3. Is there a known issue with Generic OAuth providers and the token exchange step? 4. Could this be related to the prompt parameter being rejected by our provider, even though we're now stripping it via a proxy and passing proper auth code back?

A

Ask Inkeep•12/4/25, 9:05 AM

Hi @Deathwhisp, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

A

Ask Inkeep•12/4/25, 9:05 AM

Answer

I wasn't able to find a direct answer, here are some relevant sources:

Generic OAuth IdP registration fails because IdP intent does not contain username (1) : This GitHub issue describes a scenario where Generic OAuth IdP registration fails silently with errors related to missing username mapping, which could be relevant to your token exchange failure.
Add Generic OAuth Identity Provider (2) : This documentation covers the configuration parameters for Generic OAuth providers, including
```
usePkce
```
usePkce
```
usePkce
```
usePkce
,
```
scopes
```
scopes
```
scopes
```
scopes
, and authentication endpoints that might need verification in your setup.

**

A

Ask Inkeep•12/4/25, 9:05 AM

To learn more, see the sources I considered:

[1] [Bug]: Generic OAuth IdP registration fails because IdP intent does not contain username (analysis included)
[2] Add Generic OAuth Identity Provider

A

Ask Inkeep•12/4/25, 9:05 AM

Feel free to tag @Ask Inkeep with additional questions.

D

DeathwhispOP•12/9/25, 1:48 PM

following the docs - from that example it looks like zitadel requires

profile

profile

scope - but is it really mandatory? we were able to get the auth code on scope as

openid

openid

openid

openid,

email

email

,

offline_access

offline_access

offline_access

offline_access

profile is not mentioned anywhere in docs outside the example. Basically we're ending up with last redirect as
```
{{zitadel-instance-url}}/ui/v2/login/idp/oauth/failure?error=http+status+not+ok%3A+401+Unauthorized+%7B%22message%22%3A%22Unauthorized%22%7D%0A&error_description=&id=350294217567778576&postErrorRedirectUrl=%2Floginname&requestId=oidc_V2_350294214094894864
```
{{zitadel-instance-url}}/ui/v2/login/idp/oauth/failure?error=http+status+not+ok%3A+401+Unauthorized+%7B%22message%22%3A%22Unauthorized%22%7D%0A&error_description=&id=350294217567778576&postErrorRedirectUrl=%2Floginname&requestId=oidc_V2_350294214094894864
```
{{zitadel-instance-url}}/ui/v2/login/idp/oauth/failure?error=http+status+not+ok%3A+401+Unauthorized+%7B%22message%22%3A%22Unauthorized%22%7D%0A&error_description=&id=350294217567778576&postErrorRedirectUrl=%2Floginname&requestId=oidc_V2_350294214094894864
```
{{zitadel-instance-url}}/ui/v2/login/idp/oauth/failure?error=http+status+not+ok%3A+401+Unauthorized+%7B%22message%22%3A%22Unauthorized%22%7D%0A&error_description=&id=350294217567778576&postErrorRedirectUrl=%2Floginname&requestId=oidc_V2_350294214094894864
@Ask Inkeep

lso we noticed that if we create separate endpoint under different internal domain for configuration of oauth as:

Authorization Endpoint: domain.dev/v1/oauth/proxy/authorize
Token Endpoint: domain2.dev/oauth2/token
User Endpoint: domain.dev/userinfo
ID Attribute: sub

Authorization Endpoint: domain.dev/v1/oauth/proxy/authorize
Token Endpoint: domain2.dev/oauth2/token
User Endpoint: domain.dev/userinfo
ID Attribute: sub

Authorization Endpoint: domain.dev/v1/oauth/proxy/authorize
Token Endpoint: domain2.dev/oauth2/token
User Endpoint: domain.dev/userinfo
ID Attribute: sub

Authorization Endpoint: domain.dev/v1/oauth/proxy/authorize
Token Endpoint: domain2.dev/oauth2/token
User Endpoint: domain.dev/userinfo
ID Attribute: sub

zitadel just end up with 502 as we need to workaround

prompt

prompt

parameter due to limitation of our internal IDP provider is this some edge case or we're missing something?

There is not much going on on logs from the whole helm application deployed even on debug log level being set - is there any way of tracking what might be an issue here?

A

Ask Inkeep•12/9/25, 1:48 PM

Thanks for the follow-up, @Deathwhisp. I'll get back to you soon.

A

Ask Inkeep•12/9/25, 1:48 PM

Answer

---

Regarding the

profile

profile

scope

The

profile

profile

scope is not mandatory. In the Generic OAuth IdP configuration, the

scopes

scopes

scopes

scopes field accepts an array of scopes you want to request from the identity provider—the example shows

["openid", "profile", "email"]

["openid", "profile", "email"]

["openid", "profile", "email"]

["openid", "profile", "email"] but this is just an example configuration. (1)

Your scope configuration of

openid

openid

openid

openid,

email

email

,

offline_access

offline_access

offline_access

offline_access should work as long as your external IdP supports those scopes.

The 401 Unauthorized Error

The error you're seeing (

http status not ok: 401 Unauthorized

http status not ok: 401 Unauthorized

http status not ok: 401 Unauthorized

http status not ok: 401 Unauthorized) indicates that ZITADEL is receiving a 401 response when attempting to call either the token endpoint or the user endpoint of your external IdP. This typically means:

Client authentication is failing at the token endpoint—verify your
```
client_id
```
```
client_id
```
and
```
client_secret
```
```
client_secret
```
are correct and that
```
client_secret_basic
```
client_secret_basic
```
client_secret_basic
```
client_secret_basic
authentication is properly configured
The access token is being rejected when ZITADEL calls the user endpoint to fetch user information

### Mixed Domain Configuration (502 Error)

Using different domains for authorization, token, and user endpoints can cause issues if:

CORS or network policies block cross-domain requests from ZITADEL's backend
Your proxy configuration isn't correctly forwarding all required headers

### Known Issue with Generic OAuth

There is an open issue where Generic OAuth IdP registration can fail because the IdP intent does not contain a username—the OAuth user mapper returns an empty string for

GetPreferredUsername()

GetPreferredUsername()

GetPreferredUsername()

GetPreferredUsername() . (2) This could cause silent failures during the registration/linking step even after successful authentication.

Debugging Suggestions

Unfortunately, I don't have specific documentation on enabling more ve

A

Ask Inkeep•12/9/25, 1:48 PM

rbose logging for the Generic OAuth flow. Given the complexity of your setup (proxy workaround for

prompt

prompt

parameter, mixed domains) , I'd recommend clicking the "Ask for help" button to get a team member to review your specific configuration.

A

Ask Inkeep•12/9/25, 1:48 PM

To learn more, see the sources I considered:

[1] Add Generic OAuth Identity Provider
[2] [Bug]: Generic OAuth IdP registration fails because IdP intent does not contain username (analysis included)

A

Ask Inkeep•12/9/25, 1:48 PM

Feel free to tag @Ask Inkeep with additional questions.

AAsk Inkeep To learn more, see the sources I considered: [[1] Add Generic OAuth Identity ...

A

Ask InkeepAPP•12/9/25, 2:12 PM

Got it. Tagging @Rajat for additional help.

D

DeathwhispOP•12/9/25, 3:43 PM

does it calls under the hood somehow maybe OIDC autodiscovery with

/.well-known/openid-configuration

/.well-known/openid-configuration

/.well-known/openid-configuration

/.well-known/openid-configuration or something? it's weird that we're not able to see anything important other than just

trigger iteration

trigger iteration

trigger iteration

trigger iteration from debug logs mainly and literally fails without any meaningful and traceable details

D

DeathwhispOP•12/10/25, 9:29 AM

we managed to solve the 5xx codes with ingress overrides on our end, but we're still facing the mentioned issue of having last call ending as

/ui/v2/login/idp/oauth/failure?error=http+status+not+ok%3A+401+Unauthorized+%7B%22message%22%3A%22Unauthorized%22%7D%0A&error_description=&id=350294217567778576&postErrorRedirectUrl=%2Floginname&requestId=oidc_V2_350294214094894864

/ui/v2/login/idp/oauth/failure?error=http+status+not+ok%3A+401+Unauthorized+%7B%22message%22%3A%22Unauthorized%22%7D%0A&error_description=&id=350294217567778576&postErrorRedirectUrl=%2Floginname&requestId=oidc_V2_350294214094894864

/ui/v2/login/idp/oauth/failure?error=http+status+not+ok%3A+401+Unauthorized+%7B%22message%22%3A%22Unauthorized%22%7D%0A&error_description=&id=350294217567778576&postErrorRedirectUrl=%2Floginname&requestId=oidc_V2_350294214094894864

/ui/v2/login/idp/oauth/failure?error=http+status+not+ok%3A+401+Unauthorized+%7B%22message%22%3A%22Unauthorized%22%7D%0A&error_description=&id=350294217567778576&postErrorRedirectUrl=%2Floginname&requestId=oidc_V2_350294214094894864

where the code received on callback call is valid and working - any way to see what actually is being send from zitadel or what's the flow in generic oauth2 provider?

D

DeathwhispOP•12/10/25, 3:26 PM

and after a lot of workaround to proxy also userinfo request which was failing on background above we ended up with:

rawMessage: 'invalid AddHumanUserRequest.Profile: embedded message failed validation | caused by: invalid SetHumanProfile.GivenName: value length must be between 1 and 200 runes, inclusive'

rawMessage: 'invalid AddHumanUserRequest.Profile: embedded message failed validation | caused by: invalid SetHumanProfile.GivenName: value length must be between 1 and 200 runes, inclusive'

rawMessage: 'invalid AddHumanUserRequest.Profile: embedded message failed validation | caused by: invalid SetHumanProfile.GivenName: value length must be between 1 and 200 runes, inclusive'

rawMessage: 'invalid AddHumanUserRequest.Profile: embedded message failed validation | caused by: invalid SetHumanProfile.GivenName: value length must be between 1 and 200 runes, inclusive'

is it related to mentioned github issue with another provider? or there is something that we can see what exactly zitadel requires in oauth2 flow as mapper kind of only relies on ID and https://github.com/zitadel/zitadel/blob/main/internal/idp/providers/oauth/mapper.go but this kind of is only relying on id attribute, and rest defaults to
```
""
```
```
""
```
or i'm seeing it wrong?

D

DeathwhispOP•12/10/25, 3:27 PM

@Ask Inkeep

A

Ask Inkeep•12/10/25, 3:27 PM

Thanks for the follow-up, @Deathwhisp. I'll get back to you soon.

A

Ask Inkeep•12/10/25, 3:27 PM

Answer

---

You've identified the issue correctly. The error:

invalid SetHumanProfile.GivenName: value length must be between 1 and 200 runes, inclusive

invalid SetHumanProfile.GivenName: value length must be between 1 and 200 runes, inclusive

invalid SetHumanProfile.GivenName: value length must be between 1 and 200 runes, inclusive

invalid SetHumanProfile.GivenName: value length must be between 1 and 200 runes, inclusive

A

Ask Inkeep•12/10/25, 3:27 PM

This is a known mapping issue with Generic OAuth providers. questions-help-bugsExternal OAuth2 provider Error:SetHumanProfile.GivenName: value length must be between 1 and 200 run (2) questions-help-bugsMicrosoft IdP Login Fails: Missing given_name Causes Validation Error

What's happening

With Generic OAuth providers, ZITADEL's mapper primarily relies on the

idAttribute

idAttribute

idAttribute

idAttribute you configure (e.g.,

sub

sub

sub

sub) for identification, but for automatic user creation, it also needs profile fields like

given_name

given_name

given_name

given_name,

family_name

family_name

family_name

family_name, and

email

email

. (4)

When your OAuth provider's userinfo response doesn't include these fields in a format ZITADEL expects, or they're empty, user creation fails with this validation error. questions-help-bugsExternal OAuth2 provider Error:SetHumanProfile.GivenName: value length must be between 1 and 200 run (2)

Workaround using Actions v2

You can use Actions v2 to map attributes from your provider's response. The approach is: questions-help-bugsExternal OAuth2 provider Error:SetHumanProfile.GivenName: value length must be between 1 and 200 run

Create a REST Call Target for a webhook
Create a Response Action using the method:
```
/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent
```
/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent
```
/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent
```
/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent

This allows you to intercept and modify the IdP response before user creation. More details on testing response manipulation: Testing Response Manipulation

Your provider's userinfo response

Ensure your OAuth provider returns at minimum:

```
given_name
```
given_name
```
given_name
```
given_name
(or map to it via Actions)
```
family_name
```
family_name
```
family_name
```
family_name
```
email
```
```
email
```

These cannot be empty strings if auto-creation is enabled. (2)

A

Ask Inkeep•12/10/25, 3:28 PM

To learn more, see the sources I considered:

questions-help-bugsExternal OAuth2 provider Error:SetHumanProfile.GivenName: value length must be between 1 and 200 run
[2] [Bug]: Login V2 Microsoft/Entra Identity Provider failed validation
questions-help-bugsMicrosoft IdP Login Fails: Missing given_name Causes Validation Error
[4] Add Generic OAuth Identity Provider

A

Ask Inkeep•12/10/25, 3:28 PM

Feel free to tag @Ask Inkeep with additional questions.

D

DeathwhispOP•12/10/25, 4:27 PM

my provider userinfo response consist data of

}{
            "sub":                sub,
            "email":              email,
            "email_verified":     true,
            "name":               name,
            "given_name":         givenName,
            "family_name":        familyName,
            "preferred_username": email,
            "nickname":           email,
            "picture":            "",
            "locale":             "en",
            "updated_at":         time.Now().Unix(),
        }

}{
            "sub":                sub,
            "email":              email,
            "email_verified":     true,
            "name":               name,
            "given_name":         givenName,
            "family_name":        familyName,
            "preferred_username": email,
            "nickname":           email,
            "picture":            "",
            "locale":             "en",
            "updated_at":         time.Now().Unix(),
        }

}{
            "sub":                sub,
            "email":              email,
            "email_verified":     true,
            "name":               name,
            "given_name":         givenName,
            "family_name":        familyName,
            "preferred_username": email,
            "nickname":           email,
            "picture":            "",
            "locale":             "en",
            "updated_at":         time.Now().Unix(),
        }

}{
            "sub":                sub,
            "email":              email,
            "email_verified":     true,
            "name":               name,
            "given_name":         givenName,
            "family_name":        familyName,
            "preferred_username": email,
            "nickname":           email,
            "picture":            "",
            "locale":             "en",
            "updated_at":         time.Now().Unix(),
        }

which is basically also wrapped with default non empty/non nil so it should work according to suggestion however it fails anyway as above

D

DeathwhispOP•12/10/25, 4:28 PM

@Ask Inkeep how it will differ with using actions v2 for

/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent

/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent

/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent

/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent if the payload covers the same data

A

Ask Inkeep•12/10/25, 4:28 PM

Thanks for the follow-up, @Deathwhisp. I'll get back to you soon.

A

Ask Inkeep•12/10/25, 4:28 PM

Answer

Using Actions v2 on

/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent

/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent

/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent

/zitadel.user.v2.UserService/RetrieveIdentityProviderIntent allows you to intercept and modify the response before ZITADEL processes it for user creation. Even if your provider returns all the required fields, ZITADEL's internal mapping may not be correctly parsing them. (1)

With a Response Action, you can:

Inspect the actual data ZITADEL received from your provider (via
```
rawInformation
```
rawInformation
```
rawInformation
```
rawInformation
) (2)
Explicitly set the profile fields in the
```
addHumanUser
```
addHumanUser
```
addHumanUser
```
addHumanUser
object that ZITADEL will use for user creation

For example, the response manipulation can transform the

addHumanUser.profile

addHumanUser.profile

addHumanUser.profile

addHumanUser.profile to explicitly populate

given_name

given_name

given_name

given_name,

family_name

family_name

family_name

family_name, and

display_name

display_name

display_name

display_name from your provider's data:

"addHumanUser": {
  "profile": {
    "givenName": "Test",
    "familyName": "User",
    "displayName": "Test User",
    "preferredLanguage": "en"
  },
  "email": {
    "email": "test-user@example.com",
    "isVerified": true
  }
}

"addHumanUser": {
  "profile": {
    "givenName": "Test",
    "familyName": "User",
    "displayName": "Test User",
    "preferredLanguage": "en"
  },
  "email": {
    "email": "test-user@example.com",
    "isVerified": true
  }
}

"addHumanUser": {
  "profile": {
    "givenName": "Test",
    "familyName": "User",
    "displayName": "Test User",
    "preferredLanguage": "en"
  },
  "email": {
    "email": "test-user@example.com",
    "isVerified": true
  }
}

"addHumanUser": {
  "profile": {
    "givenName": "Test",
    "familyName": "User",
    "displayName": "Test User",
    "preferredLanguage": "en"
  },
  "email": {
    "email": "test-user@example.com",
    "isVerified": true
  }
}

This bypasses ZITADEL's default OAuth mapper logic entirely—you're directly controlling what values go into the user creation request, regardless of how the mapper interprets your provider's response.

Important note: If you're using Login V1, there's a known compatibility issue where response executions on

RetrieveIdentityProviderIntent

RetrieveIdentityProviderIntent

RetrieveIdentityProviderIntent

RetrieveIdentityProviderIntent may not trigger. This was addressed in v4.7.1 for Login V2, but Login V1 still has issues. questions-help-bugsLogin V1 + Actions V2: alternatives to "(Actions V1) External Authentication / Post Authentication"?

A

Ask Inkeep•12/10/25, 4:28 PM

To learn more, see the sources I considered:

[1] Migrate from Actions v1 to v2
[2] Test Actions Response Manipulation

A

Ask Inkeep•12/10/25, 4:28 PM

Feel free to tag @Ask Inkeep with additional questions.

D

DeathwhispOP•12/11/25, 4:14 PM

i'm marking as resolved as with using action v2 as workaround we kind of make it work

AAsk Inkeep To learn more, see the sources I considered: [[1] Migrate from Actions v1 to ...

A

Ask InkeepAPP•12/11/25, 4:14 PM

Glad I could be helpful. Feel free to create a new thread with any new questions you may have.

Generic OAuth Provider: Silent error after successful callback from provider

Answer

Answer

Regarding the
`profile`
`profile`
scope

The 401 Unauthorized Error

Debugging Suggestions

Answer

What's happening

Workaround using Actions v2

Your provider's userinfo response

Answer

Answer

Answer

Regarding the
`profile`
`profile`
scope

The 401 Unauthorized Error

Debugging Suggestions

Answer

What's happening

Workaround using Actions v2

Your provider's userinfo response

Answer

Generic OAuth Provider: Silent error after successful callback from provider

Answer

Answer

Regarding the profileprofile scope

The 401 Unauthorized Error

Debugging Suggestions

Answer

What's happening

Workaround using Actions v2

Your provider's userinfo response

Answer

Answer

Answer

Regarding the profileprofile scope

The 401 Unauthorized Error

Debugging Suggestions

Answer

What's happening

Workaround using Actions v2

Your provider's userinfo response

Answer

Regarding the
`profile`
`profile`
scope

Regarding the
`profile`
`profile`
scope