AddIDPLink Failing with COMMAND-39nf2
Env: Self-hosted
Version: Latest
Stack: Docker here (using k8s in prod)
I'm trying to link a user to an IDP account, but I'm getting some trouble.
My flow is like this:
1. User enters loginName
2. Create session, get userId, OrgId (and from that, login policy)
3. Get IDP id from login policy
4. Begin IDP intent
5. When that comes back, since
userId
is not given as a param, try to register user to idp:
6. Fetch the IDP intent response (to get idpUserId, idpUsername etc.)
7. Try to add link using the above.
8. Use in session flow
Everything up to 7 seems to be working as expected.
The login policy pulled for my user looks like:
But when I go to link, I get the following error:
With Zitadel logging:
The orgId here is correct, the id in the path is correct (the user=<id> is my login client service user) - so I'm not really sure what the issue is?
Am i doing something fundamentally wrong here? Or is this a bug?2 Replies
Hi @Oscar, 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.
Answer
I wasn't able to find a direct answer, here are some relevant sources:
1. [Get Login Policy] (1) :
Describes how to retrieve the login policy, which includes the list of configured identity providers for an organization. This may help verify if the IDP is properly configured and visible to the user.
2. [Let Users Login with Preferred Identity Provider] (2) :
Covers the integration of external identity providers with ZITADEL and how ZITADEL acts as an identity broker, which might provide insights into the linking flow and configuration requirements.
To learn more, see the sources I considered:
[1] Get Login Policy
[2] Let Users Login with Preferred Identity Provider
Feel free to tag @Ask Inkeep with additional questions.
Got it. Tagging @Rajat for additional help.
Now, I'm not familiar with Go, so I can't say with much certainty, but I think the function called is identical to that of the one in the GetLoginPolicy? I will include the log here to show the logged context is the same.