Shuffle
Shuffle & Zitadel SSO Integration Issue Userinfo endpoint
The SSO configuration in Shuffle using OpenID doesn't seem to have an option to specify a discovery endpoint and it seems to be using either a hardcoded value which I can't seem to find, or a dynamically generated value for the "userinfo" endpoint which ends up being incorrect.
I have a self-hosted setup (latest git branch and tried the nightly) and can get shuffle to trigger the authentication to Zitadel using client_id, authorization_url, and token_endpoint only, (no secret using PKCE).
After I successfully authenticate (I can validate the logs on the SSO side), I get an error "{"success": false} on the shuffle side.
After troubleshooting through the log files on Shuffle dockers, I found where it was making the userinfo api call, which is incorrect and was not specified anywhere I can see.
I was able to validate this is an issue by configuring a URL rewrite rule in my DNS/WAF provider to the correct endpoint which got me pass this error and displayed a new error {"success": false, "reason": "Username is empty"}. I tried turning off the proxy feature on the DNS resolver and that didn't change the results.
Not sure how else to proceed. I may be missing something obvious unfortunately. There doesn't seem to be an option to add/map userinfo fields in case that's the issue. I also configured additional custom fields on my SSO to return both username and Username in the userinfo token but I didn't fix the issue. Also tried returning both Bearer tokens and JWT, no impact on results.
Appreciate any help or suggestions.
Hi @diaa-abushaqra ,
Thank you for raising this issue!
Your username corresponds to the email ID you've added in the SSO provider for the authenticated user. If you're seeing an error indicating that your username is empty, it likely means that an email ID hasn't been added in the SSO provider for that user.
Adding the email ID and trying again should resolve the problem. Please let me know if this helps!
Thank you @LalitDeore. I appreciate it. The SSO provider most certainly has the email address and it is a key attribute to getting SSO to work anywhere. I have it working with 7 other systems without an issue, including proper field mappings.
Is there any way we can define the correct userinfo endpoint instead of the one that Shuffle seems to think/generate is the correct one?
The main reason I got this far is that I'm doing a URL rewrite on my DNS provider from /oauth/v2/userinfo to the correct endpoint => /oidc/v1/userinfo
Thank you @LalitDeore. I appreciate it. The SSO provider most certainly has the email address and it is a key attribute to getting SSO to work anywhere. I have it working with 7 other systems without an issue, including proper field mappings.
Is there any way we can define the correct userinfo endpoint instead of the one that Shuffle seems to think/generate is the correct one?
The main reason I got this far is that I'm doing a URL rewrite on my DNS provider from /oauth/v2/userinfo to the correct endpoint => /oidc/v1/userinfo
The issue {"success": false, "reason": "Username is empty"} is likely due to the email ID being missing from the response that Shuffle receives from Zitadel.
I checked Zitadel's configuration to understand how it works, and by default, Zitadel does not send the user's email ID in the response. You need to manually enable this option in Zitadel. Go to Projects → Token Settings → User Info inside ID Token, and after enabling this option, the response will include the email ID. You can also refer to this Zitadel documentation for more details.
If you still encounter the "Username is empty" error, try sending a request using cURL and check whether the email is included in the response after decoding the JWT. If the email is present but you're still getting the error, then the issue is on our side, and I will investigate further.
Additionally, I noticed you're using the /userinfo endpoint. Is there a specific reason for this? Typically, authentication requires setting the authorization URL and token URL.
Thank you for checking the documentation. Yes the option to include user info has been enabled and I tried both types of returns Bearer and JWT, none of them work.
Reminder, the only reason I got this far is that I created a URLRewrite rule to translate the incorrect user info endpoint that I saw in the logs Shuffle is using. The error before and after that change is noted in the issue I created. This indicates there's an issue with Shuffle reaching out to an endpoint that the user did not specify.
Is there a reason why Shuffle is using this endpoint? ==> "/oauth/v2/userinfo " I did not configure this anywhere and I can't find the logic where it's creating it.
Is there a way Shuffle can be configured to point to a proper discovery endpoint to figure out all the URLs so that it uses the correct ones?
Hey @diaa-abushaqra and @LalitDeore
I'm a maintainer of ZITADEL. As you already noted, the id_token will not contain the values for the profile, email, phone and address scope based on the OIDC specification: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
A quick check in the Shuffle code showed that the userinfo endpoint is automatically built from the authorization endpoint: https://github.com/Shuffle/shuffle-shared/blob/f0f853287a66a4bedfab0a3a8679ece355360e6b/shared.go#L19090-L19094
If I understood it correct, Shuffle also allows to use SAML, e.g. for Google (where you'd have the same issue of the authorization and userinfo endpoint not having the same base path): https://shuffler.io/docs/extensions#google-saml-sso
We do not have a generic SAML guide, but maybe it helps following this one: https://zitadel.com/docs/guides/integrate/services/gitlab-saml
Thank you @livio-a for your input, much appreciated. I see no logical reason for Shuffle to be "guessing" what the userinfo endpoint is instead of either explicitly asking or using a discovery endpoint. I was hoping to use OIDC for my SSO as I have 9 other apps now using it without any issues.
Thank you @livio-a for your input, much appreciated. I see no logical reason for Shuffle to be "guessing" what the userinfo endpoint is instead of either explicitly asking or using a discovery endpoint. I was hoping to use OIDC for my SSO as I have 9 other apps now using it without any issues.
To make it clear (I'm the lead dev on Shuffle): The logical reason is that someone has to spend time and write the actual code for it. It's simply a time problem.
I do agree that using discovery endpoints and both having mapping overrides or discovery mapping would in an ideal world be better, but we don't focus on random issues that aren't:
- On our immediate roadmap
- Aren't blockers for customers
We got hundreds of thousands of users of Shuffle at this point, meaning a lot of random issues show up from networking & scale problems to weird frontend mechanics in different browsers.
I'll ask my colleague however how the implementation here went; we are obviously looking to make the OpenID system universal, but there are bound to be some random issues along the way :)
I appreciate you stepping in @frikky, thank you for your input and attention to the matter. I totally understand where you're coming from and appreciate your support! Looking forward to see how this evolves.
@frikky Not yet. I’ll need to specifically test it with the userInfo endpoint to understand the issue and then work on a fix.
I get the same issue when i use SSO using authentik.
@LalitDeore did you get a chance to test this out?
Authentik Zitadel
Hi @Karthikraja-a93,
Could you please share the Authentik configuration you are using? When I last tested it with Authentik, everything worked as expected.
Also, which version of Shuffle are you currently running? If you are not on the latest version, please update to the latest tag and pull the new changes. I have fixed several SSO related issues over the past few months.
Once you’ve pulled the latest changes, kindly test again and let me know the outcome. If you still encounter the same error, I will spend more time testing it with Authentik or Zitadel.