fix: respect promptType=none with offline_access scope

[automaticgiant]

Overview

This PR fixes an issue with the OIDC connector where setting promptType: "none" is not respected when requesting the offline_access scope. The fix ensures that when promptType is set to "none", no prompt parameter is sent to the identity provider during authentication flows that request refresh tokens.

What this PR does / why we need it

When using the OIDC connector with promptType: "none" configured and requesting refresh tokens via the offline_access scope, Dex incorrectly adds a prompt=none parameter to the authorization request. This causes issues with identity providers like OneLogin that don't properly handle the prompt=none parameter when requesting offline access.

The problem occurs in the LoginURL method of the OIDC connector. When offline_access scope is requested, Dex forcibly adds prompt=consent (or whatever the configured promptType is, including "none") to the authorization request parameters:

if s.OfflineAccess {
    opts = append(opts, oauth2.AccessTypeOffline, oauth2.SetAuthURLParam("prompt", c.promptType))
}

This behavior causes authentication failures with error messages like: consent_required: prompt consent was not resolved

This PR modifies the OIDC connector to respect the promptType: none configuration by conditionally adding the prompt parameter only when it's not set to "none".

Related issues

Issue #1172: "Disable 'grant access' page" (Dex)
Link: #1172

This issue from 2018 is highly relevant to our fix. The user reported:

"Is there a way to automatically grant access? (skip the page). I tried with the query param prompt=none but I still have to grant access."

This is exactly our issue - the user tried setting prompt=none but it was ineffective when handling consent screens.

In ArgoCD:
Issue #9639: "Unable to login via cli sso" (ArgoCD)
Link: argoproj/argo-cd#9639

This issue involves CLI authentication problems when using external OIDC providers without Dex. While not an exact match, it shows the kind of authentication problems that can occur in the ecosystem.

Issue #2932: "SSO for Existing OIDC Provider returning 401" (ArgoCD)
Link: argoproj/argo-cd#2932

This deals with authentication problems via CLI using SSO, which is related to our issue since CLI authentication often uses PKCE flows that can be affected by prompt parameter issues.

I also found this related comment in the official Dex OIDC connector documentation:

For offline_access, the prompt parameter is set by default to "prompt=consent". However this is not supported by all OIDC providers, some of them support different value for prompt, like "prompt=login" or "prompt=none"

This documentation directly acknowledges the issue we're fixing: that the hardcoded behavior of always adding prompt=consent for offline access doesn't work with all providers.

Based on these findings, the most directly relevant issue is #1172, as it specifically mentions trying prompt=none and finding it ineffective - exactly what our fix addresses.

Special notes for your reviewer

This change has been tested with OneLogin as an identity provider, which previously failed with "consent_required" errors. After implementing this fix, the OIDC flow completes successfully when using promptType: none.

I'm hoping there is CI upstream to run the tests as I'm not setup to run the tooling in the repo.

[automaticgiant]

i've now validated i can use argocd, kargo, argocd-cli, and kargo-cli with dex using this patch.

  clients = [
    {
      id = "argocd"
      redirectURIs = [
        "https://argocd.redacted/auth/callback",
      ]
      secret = var.argocd_oidc_client_secret
    },
    {
      id = "argocd-cli"
      redirectURIs = [
        "http://localhost:8085/auth/callback",
      ]
      public = true
    },
    {
      id = "kargo"
      redirectURIs = [
        "https://kargo.redacted/login",
      ]
      public = true
    },
    {
      id = "kargo-cli"
      redirectURIs = [
        "http://localhost:63500/auth/callback",
      ]
      public = true
    }

[automaticgiant]

@sagikazarmark, would you be so kind as to help me get the ci testing workflow to run against this pr? tysm

[nabokihms]

I didn't get one thing. If none is not respected by provider, why is none specified in the configuration? Should it be consent then?

[automaticgiant]

I couldn't get 'consent' to work either 🤷
I'll see if I can get someone closer to OneLogin to comment.

[automaticgiant]

onelogin says:

This issue has been acknowledged as a defect under tracking# ST-1133

according to https://developers.onelogin.com/openid-connect/scopes and support:

My suspicion is that hat we don't support offline access for the authorization code flow because we never implemented consent for that flow. But this is just an assumption that needs to be confirmed by my product team..

At the moment we only support the offline_access scope for the password grant flow. So it won't work in the authorization code flow, irrespective of whether it's PKCE or client id and secret

does this seem like a reasonable workaround PR until such time as the defect is resolved? @nabokihms