Dex maintainer here

[sagikazarmark]

Hey there,

As the title says, I'm a Dex maintainer and I thought I'd reach out to you to talk about how you use Dex in ArgoCD, what are the challenges that you see and how we could help you with those challenges.

We (the Dex team) would like to drive our roadmap based on user feedback and ArgoCD is a significant user in the Cloud Native ecosystem.

Let me know if you have any feedback, need anything from the Dex team or just want to have a chat about ArgoCD and Dex.

Thank,
Mark

PS: We would love to see ArgoCD on the list of adopters. If you could send a PR adding ArgoCD the list that would be awesome! Thanks!

[alexmt]

Hello @sagikazarmark,

Thank you for reaching out! First just want to say that Dex is a great project - it saved us a ton of work. Thanks a lot for building and maintaining it!

Argo CD is used by multiple organizations and it is hard to make any assumptions about which SSO provides have to be supported using Argo CD. We help of Dex we could implement only OIDC support and using Dex and as OIDC -> anything proxy. So Argo CD users can use Github, Gitlab, Google etc as an identity provider. Argo CD has "first-class" dex support. First-class means that we bundle Dex K8S deployment into Argo CD manifests, periodically upgrade bundled Dex version, and test compatibility with ArgoCD etc.

We are pretty happy with Dex functionality already and only had several requests. Here are a few that are on top of my head now:

• Ability to invalidate token programmatically. We would like to invalidate the token generated by Dex when the user clicks the logout button. I could not find an API to do it. (at least I could not find it ~6 months ago)
• We did not want to redirect users between Argo CD and Dex login pages. So instead we've implemented a reverse proxy that forward requests to Dex to initialize that login flow and intercept error response to extract login error message. It would be nice to have first-class support of that use case to make such integration more robust.
• Pretty open-ended idea: each IDP provider configuration is slightly different. To help users we have to maintain documentation for various providers: https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/ . It would be nice to have a CLI that help users to generate provider-specific config. E.g. dex generate-config --provider gitlab --clientSecret $CLIENT_SECRET ...

If I think longer I can get more :) Does it make sense if I create github issues for such requests?

Sending PR to adopters list shortly! Thanks again for the awesome project.

[sagikazarmark]

Thanks for the quick response @alexmt !

I'm glad that you are happy with Dex.

Thanks for the feedback as well, it's really great input.

Let me quickly respond to your points, but opening issues/discussions in the Dex repo would be the best way to track these items:

1. Token invalidation is not available in the API at the moment. Adding it to the API would be one option, but I think I've seen some OIDC drafts about logout. Implementing a standard solution would be better IMHO, but we can implement token invalidation if it's quicker.
2. Sounds interesting. I'm not sure about the security implications of such thing, so we would have to look into the details. Would be nice to hear more about how you imagine it to work.
3. We are trying to cleanup the configuration mess that we have today. Unfortunately, it's really hard because we have to keep backwards compatibility. So far we've tried to improve the situation by writing better documentation, but admittedly we need to do more on that front as well. TBH I don't see yet how a CLI tool would improve the situation. What problem would it solve exactly? How would users use it? How would ArgoCD add it to its documentation? Building a CLI tool is trivial, building the right tool is (unfortunately) not.

I really appreciate your input. Please, feel free to open issues/discussions where we can go into more details. Thanks!