OIDC Regression in v4.5.7 – Worked in v4.5.6

[ofirmachluf]

Describe the bug

Hi team,

After upgrading to version v4.5.7, our OIDC login stopped working with the same configuration that worked in v4.5.6.

No changes were made to the OIDC provider or config. This looks like a backward compatibility issue.

Can you confirm if there were any breaking changes in v4.5.7 related to OIDC? If so, please update the to major version.

Thanks!

Current behavior

After upgrading to v4.5.7, the OIDC authentication fails during login.
This same configuration worked without issues in v4.5.6.

Reproduction steps

No response

Expected behavior

No response

Setup JFrog CLI version

jfrog/setup-jfrog-cli@v4

JFrog CLI version

jfrog/setup-jfrog-cli@v4

Workflow operating system type and version

jfrog/setup-jfrog-cli@v4

JFrog Artifactory version (if relevant)

No response

JFrog Xray version (if relevant)

No response

[EyalDelarea]

Hey @ofirmachluf,
Sorry for the inconvenience!

There shouldn’t be any breaking changes, but to help us investigate, could you please share a bit more detail?
Are you using a custom version of the CLI or any non-default configuration? Also, what’s the exact error message you're seeing?

We will fix it ASAP.

Thanks!

[ofirmachluf]

Hi @EyalDelarea
i will share part of our CI

- name: Install JFrog
  uses: jfrog/setup-jfrog-cli@v4
  id: setup-jfrog-cli
  env:
      JF_URL: https://${{ env.JF_REGISTRY }}
  with:
    oidc-provider-name: ovp-github-oidc
- name: run script
  env:
    JF_REGISTRY: <out registry>
    JFROG_URL: https://${{ env.JF_REGISTRY }}
    JFROG_USER: ${{ steps.setup-jfrog-cli.outputs.oidc-user }}
    JFROG_PASSWORD: ${{ steps.setup-jfrog-cli.outputs.oidc-token }}

and you can see the outpus stop work

env:
    JFROG_USER: 
    JFROG_PASSWORD: 

[EyalDelarea]

Hey @ofirmachluf,

Thanks again for raising this!

First off, I want to let you know that I’m about to release a patch that will downgrade the default version of the JFrog CLI used in this action. This should restore the previous behavior and fix the issue you’re seeing — without requiring you to update the CLI version manually across all your repositories.

Apologies for the inconvenience this caused. The break happened because, in the latest version of the CLI, the OIDC token exchange logic was moved inside the CLI itself. While this improves security and simplifies the flow, it also means the access token is no longer exposed as a step output — which impacted workflows relying on those outputs.

The motivation for this change was to eliminate the need to pass JFROG_USER and JFROG_PASSWORD (or even the access token) between jobs when using OIDC. With the new setup, you can configure OIDC in a much cleaner way, like this:

- name: Install JFrog CLI
  uses: jfrog/setup-jfrog-cli@v4
  env:
    JF_URL: https://${{ env.JF_REGISTRY }}
  with:
    oidc-provider-name: ovp-github-oidc

This automatically sets up the CLI with an access token, without needing to expose any secrets.

Also, if you do want to explicitly extract the token in future versions of the CLI, you’ll be able to use the new jf exchange-oidc-token (or jf eot) command to manually perform the token exchange.

That said, I’d love to learn more about your use case — specifically:

• Why you need to rely on the exported token?
• Whether switching to this newer OIDC flow could work for you?

Your feedback will really help us improve both the action and how we handle these kinds of changes going forward.

Thanks again — and sorry for the unexpected break!

[ofirmachluf]

Thanks for the quick change!

This is how it worked for us previously when using this option.
We’ll try adopting the new behavior in the future.

Appreciate your support!

[NetanelK]

• Why you need to rely on the exported token?
• Whether switching to this newer OIDC flow could work for you?

We use the OIDC token for clients to log in to jFrog Artifactory, like with helm repo add, helm registry login, and docker login. We prefer not to change workflows, since that would require adding the jf eot command wherever we use jFrog CLI.

Here’s a possible solution:
Could you keep exposing the OIDC token on your side by using jf eot when opting in?

Here is an example workflow for helm charts:

  - name: Install JFrog
    id: setup-jfrog-cli
    uses: jfrog/setup-jfrog-cli@f748a0599171a192a2668afee8d0497f7c1069df # v4.5.6
    env: 
      JF_URL: ${{ env.JF_REGISTRY }}
    with:
      oidc-provider-name: setup-jfrog-cli

  - name: Add dependency chart repos
    run: |
      helm repo add bitnami-archive https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami
      helm repo add ${{ env.JF_REPOSITORY }}/${{ env.JF_REGISTRY }} --username ${{ steps.setup-jfrog-cli.outputs.oidc-user }} --password ${{ steps.setup-jfrog-cli.outputs.oidc-token }}

  - name: Run chart-releaser
    uses: helm/chart-releaser-action@cae68fefc6b5f367a0275617c9f83181ba54714f # v1.7.0
    with:
      config: "./.github/configs/cr.yaml"
      skip_upload: true
    env:
      CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

  - name: Login to Artifactory
    uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3.4.0
    with:
      registry: ${{ env.JF_REGISTRY }}
      username: ${{ steps.setup-jfrog-cli.outputs.oidc-user }}
      password: ${{ steps.setup-jfrog-cli.outputs.oidc-token }}

[EyalDelarea]

Hey @NetanelK,

Thanks again — your feedback and the detailed example really help.

You're absolutely right that using the access token to authenticate external tools like helm, docker, and others is a valid and important use case.

Just to understand a bit more — before the OIDC integration was introduced, how were you handling authentication for these tools? Were you relying on a static access token stored as a GitHub secret, or using a different approach?

We want to make sure we continue to support these kinds of use cases in a way that’s both secure and practical, and your input plays a big role in shaping that.

Thanks again!

[NetanelK]

Just to understand a bit more — before the OIDC integration was introduced, how were you handling authentication for these > tools? Were you relying on a static access token stored as a GitHub secret, or using a different approach?

Yes, we were using a static GitHub secret, which was mapped to JF_ACCESS_TOKEN, combined with JF_USER.
We switched to OIDC as it is more secured and allows us to scope permissions per repository/workflow, I don't see us switching back to static secrets.

  - name: Install JFrog
    uses: jfrog/setup-jfrog-cli@96153976e4e81b3701e9cc0a5b9597e80614af81 # v4.5.1
    env: 
      JF_URL: ${{ env.JF_REGISTRY }}
      JF_ACCESS_TOKEN: ${{ secrets.JF_ACCESS_TOKEN }}

  - name: Add dependency chart repos
    run: |
      helm repo add bitnami-archive https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami
      helm repo add devops-helm ${{ env.JF_REGISTRY }} --username ${{ secrets.JF_USER }} --password ${{ secrets.JF_ACCESS_TOKEN }}

  - name: Login to Artifactory
    uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3.3.0
    with:
      registry: ${{ env.JF_REGISTRY }}
      username: ${{ secrets.JF_USER }}
      password: ${{ secrets.JF_ACCESS_TOKEN }}

[AndreasAlbertQC]

Hi @EyalDelarea, I am in a similar situation as @NetanelK, except I have been using the token from the action outputs. I use them to authorize clients like pixi, which is a conda client:

- name: Log in to Artifactory
  uses: jfrog/setup-jfrog-cli@v4
  id: artifactory
  env:
    JF_URL: https://something.jfrog.io
  with:
    oidc-provider-name: ${{ vars.ARTIFACTORY_OIDC_PROVIDER }}
    oidc-audience: ${{ vars.ARTIFACTORY_OIDC_AUDIENCE }}
- name: Set up pixi
  uses: prefix-dev/setup-pixi
  with:
    auth-host: https://something.jfrog.io
    auth-token: ${{ steps.artifactory.outputs.oidc-token }}

I think @NetanelK makes a good point: While using jf eot to extract the token would be possible, it would be annoying to have to do this every time we do the artifactory login + client login combination, which we do a lot.

[EyalDelarea]

Hey @AndreasAlbertQC,
Thanks so much for the feedback!

We’re planning to keep the step outputs available to ensure a smooth experience while we transition internally to the new jf eot command wherever possible.

This PR should ensure that the OIDC-related step outputs remain accessible:
👉 #265

Really appreciate you taking the time to share your thoughts!

[tim-goto]

Hey, we have a similar workflow and when trying to update the action from v4.5.8 to v4.5.9 I see the following error in our integration tests:

  Error: OIDC credentials are not supported for CLI remote downloads, please use an access token instead.

this is how we wrap the setup-jfrog-cli action in our composite workflow:

    - name: Setup JFrog CLI
      id: setup-jfrog
      uses: jfrog/setup-jfrog-cli@v4.5.8 # <- updating this breaks the composite action
      with:
        oidc-provider-name: github
        oidc-audience: github
        download-repository: jfrog-cli
        version: ${{ inputs.JFROG_CLI_VERSION }} # <- this is set to 2.74.1 by default
        custom-server-id: setup-jfrog-cli-server-id

can you please advise, thanks!