Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
OIDC groups scope not standard, causes oidc authentication to fail with some providers #1195
When using Google as an OIDC provider, authentication fails due to an invalid scope,
It appears that
To Duplicate (assuming a gcloud account already exists):
I'm not sure what the equivalent would be in Google. Their concept of
Here is their implementation of scope
They have a way to grant access to other APIs via scopes, but I'm not sure this would help.
And they have a LOT of scopes you could potentially access. None of them seem to be group oriented.
As for GitLab, I couldn't find much in the documentation on what they supported.
Just FYI, the code in question is in
For GitLab, you would want to go the route of using the bundled dex server, with the gitlab connector:
Also for Google, I think this should be possible by also using bundled dex with it's generic oidc.connector:
Would those solve your issue?
Sadly, no. Our kubernetes cluster is completely locked down, we use kubectl port forwarding to access the system. That system will likely be replaced by a tunneling system in the future.
I tried using dex and ran into this:
There might be a way to hack that around using your original suggestion. Perhaps using the internal cluster service hostname, and adding an /etc/hosts entry to the local device specifying that hostname as localhost(?) I may be able to try that tomorrow.
I see. If there was a solution #1062 would this solve your issue?
I agree hardwiring groups is not ideal, but my hope was that Dex would solve most of the fragmentation issues for us by normalizing the OIDC providers into a set of expected scopes we can trust to be available. During testing, I tested with auth0, okta, onelogin which all seem to support
Otherwise we would have to provide more and more oidc config options, which we will never be able to provide the same amount of functionality as Dex does, since this is not our focus.
Yes, solving #1062 would work for our needs.
I think Dex probably is the best long term solution for SSO, for exactly the reason you said. It allows you to focus on the tool you are try to develop.
For now, I am going to actually stick with user/pass authentication, since I only have 2 others who will need access to ArgoCD. I can be patient for a fix.