Multiple bugs with Microsoft IdP
Hello there, I've tried to set up Microsoft IdP in the default settings on a fresh self-hosted instance of Zitadel version 4.0.2, but i encountered a lot of issues and I'm at a loss. I've followed every step in the documentation and, at first, the first error I get is from Microsoft (first image): the url provided by the registration page (/ui/login/login/externalidp/callback) doesn't match with what is actually requested (/ipds/callback). Adding it to the allowed redirect URIs in Entra let's me move only to get a Login failed error (second image). Following an older threat i've found here i tried to search for "id_token" in the network requests but didn't find anything, searching just for "token" i've found the callback request with the auth code but no cleartext jwt.
Can anyone help me? 🙏
Thanks so much in advance!
L.
4 Replies
Hi @elsitar, 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. SSO Login Error with Entra ID: "Authorization Code Already Redeemed" (1) : This covers the "OAuth2 Authorization code was already redeemed" error that can occur with Entra ID, suggesting updating the App Registration manifest to include
"acceptMappedClaims": true .
2. Incorrect redirect_uri being passed to Microsoft (2) : This GitHub issue describes the exact redirect URI mismatch you're experiencing in version 4.0.0, where ZITADEL shows /ui/login/login/externalidp/callback but actually uses /idps/callback .
(1) , (2)
​
To learn more, see the sources I considered:
[1] SSO Login Error with Entra ID: “Authorization Code Already Redeemed”
[2] [Bug]: Incorrect redirect_uri being passed to Microsoft
​
Feel free to tag @Ask Inkeep with additional questions.
Got it. Tagging @Rajat for additional help.hello @elsitar, sounds like Entra ID is not adding the given_name claim to the ID token returned to Zitadel during authentication. This exchange happens on the backend, therefore you will not see it in the browser network trace.
Check your token configuration in the Azure portal, and double check which claims are added to the token.
Hi @fcoppede, thank you for your reply. As you can see from the attached screenshots the given_name claim is configured in Entra ID, moreover yesterday I tried to run v3.3.6 with the same settings an it's working as expected
hey @elsitar, the exact same settings worked on 3.3.6 but not on v4?