EppO
commented
1 year ago Agree, SSO login through CLI should be out-of-band, without any browser requirement on the machine where the cli is run. URL for authentication should be displayed and the means how the user is logging in should not matter. I'm wondering about the return URL though from the OIDC issuer.
Summary
Currently argocd login --sso works by spinning up a local server and launching a browser pointing back at the local server for its redirect. This has multiple drawbacks, such as not being able to use a confidential OIDC client (one containing a client secret), needing to configure localhost as a valid redirect url and allowing redirect uri to be http for localhost.
Motivation
Login via sso should be rather straightforward and shouldn't require the spin up of a local browser or a client specifically configured for it. These are potential security risks that we don't need to accept in the case that we already serve the webinterface for argocd. In case the webinterface is not served we don't have that many alternative options unfortunately.
Proposal
Assuming the webinterface is available for argocd an argocd login --sso request should ask the webinterface to authenticate the user using SSO and return a token to the CLI on a backchannel. This is similar to what rancher does when using SSO on its CLI.
The SSO is secure between the SSO server and argocd and the token passed to the cli is specific to argocd. This would require argocd itself to keep a token store or at least have the capability to sign tokens. However it already does similar things for standard login without SSO as far as I can tell.
However in general storing SSO tokens on the argocd server (including OIDC refresh tokens) should be much more secure than keeping them on the machines running argocd cli instances.