argo-cd: SSO for Existing OIDC Provider returning 401 because of missing client secret

Maybe this will save someone some time. In my case the problem was with Azure AD. Starting from v.1.3.x argocd-cli will perform authorization_code flow if provider supports it. In case of Azure AD (the same is true for Google), there are two kinds of platforms supported: web applications and mobile and desktop applications (so called public in terms of Google). In authorization_code flow you need to specify client_secret when requesting the token (second phase), but argocd-cli aren’t doing that (because they don’t want to show that in console) for web application platform. So for Azure AD, you just need to add mobile and desktop applications platform with Redirect URI: http://localhost:8085/auth/callback, or create separate one and use cliClientID with it’s id in argocd configmap.

I had this issue and it drove me nuts. What I discovered was that I had to restart the argo-server pod after creating a new key-value pair in the secret configuration:

I started the pod with a reference to the non-existed $oidc.keycloak.clientSecret:

oidc.config: |
    name: Keycloak
    issuer: https://example.com/auth/realms/cluster-admins
    clientID: argo-cd
    clientSecret: $oidc.keycloak.clientSecret
    requestedScopes: ["openid", "profile", "email", "groups"]
    logoutURL: https://example.com/auth/realms/cluster-admins/protocol/openid-connect/logout?redirect_uri=https://example.com

I then followed the instructions here to set up keycloak, adding the new key-value pair to the secret config file. However, the logs of the argo server showed it was not finding the key at all.

I deleted the pod, triggering a restart, and everything worked.

I’m also facing this issue. See my post in the slack channel https://argoproj.slack.com/archives/CASHNF6MS/p1577923783162400

@jl431 Thanks for making an issue!

I had this issue and it drove me nuts. What I discovered was that I had to restart the argo-server pod after creating a new key-value pair in the secret configuration:

I started the pod with a reference to the non-existed $oidc.keycloak.clientSecret:

oidc.config: |
    name: Keycloak
    issuer: https://example.com/auth/realms/cluster-admins
    clientID: argo-cd
    clientSecret: $oidc.keycloak.clientSecret
    requestedScopes: ["openid", "profile", "email", "groups"]
    logoutURL: https://example.com/auth/realms/cluster-admins/protocol/openid-connect/logout?redirect_uri=https://example.com

I then followed the instructions here to set up keycloak, adding the new key-value pair to the secret config file. However, the logs of the argo server showed it was not finding the key at all.

I deleted the pod, triggering a restart, and everything worked.

solved it for me.

kubectl get po -n <argocd-ns> |grep Running | grep -v redis | awk '{print $1}' |xargs -I {} kubectl delete po -n <argocd-ns> {}

so, as far as I can tell… if you want the CLI to work… access_type == public in the keycloak client.

You may consider that dangerous but keycloak argues

https://www.keycloak.org/docs/latest/server_admin/#_oidc-auth-flows

Another important aspect of this flow is the concept of a public vs. a confidential client. Confidential clients are required to provide a client secret when they exchange the temporary codes for tokens. Public clients are not required to provide this client secret. Public clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the client. HTML5/JavaScript clients always have to be public clients because there is no way to transmit the client secret to them in a secure manner. Again, this is ok so long as you use HTTPS and strictly enforce redirect URI registration

See follow-up comment below

Similarly when trying to do this via Okta, I followed @Subreptivus 's advice for making a public client. ~In Okta speak its an SPA app.~ Its a native app. Only issue I’m encountering is Okta requires PKCE for public clients to do the auth code flow, but it seems the CLI does not support it:

$ argocd login --insecure --grpc-web --sso argocd.example.com
Opening browser for authentication
INFO[0002] RequestedClaims: map[groups:essential:true ] 
Performing authorization_code flow login: https://dev-*****.okta.com/oauth2/******/v1/authorize?access_type=offline&claims=%7B%22id_token%22%3A%7B%22groups%22%3A%7B%22essential%22%3Atrue%7D%7D%7D&client_id=0oaaqeuntucmCcCJ94x6&redirect_uri=http%3A%2F%2Flocalhost%3A8085%2Fauth%2Fcallback&response_type=code&scope=openid+profile+email+groups+offline_access&state=lLkFhKoUqV
FATA[0004] invalid_request: PKCE code challenge is required when the token endpoint authentication method is 'NONE'. 

I’m trying to figure out to disable PKCE for public clients in Okta, but is this on the roadmap for the CLI? Should I open a separate issue for PKCE support?

@zeph If you don’t mind, may I know how you have this fix(or workaround) for Keycloak.

Do you mean we need to create a “public” client-scope for the realm? and add this client-scope to client(which I did, but still not working)

I also have added “http://localhost:8085/auth/callback” to the “Valid Redirect URIs”. Give the user “offline_access” realm role.

but seems it didn’t generate the offline token

login via UI is fine but always failed from CLI