Future Architecture of CLI Credentials - Usage Patterns and the Path to Zero-Exposure

[mitchspano]

Overview

We recently announced upcoming CLI credential security changes where we will introduce a set of new, dedicated retrieval commands (sf org auth show-*) designed to serve as an explicit way to fetch credentials when strictly necessary.

However, our long-term goal is to lock down the CLI as tightly as possible. We want to better understand exactly why and how your workflows rely on raw access tokens, passwords, and SFDX Auth URLs today. Our target state is to eliminate raw secret exposure entirely; unless there is an unresolvable architectural dependency that requires a raw secret to be exposed, any command that outputs a plain-text credential is a candidate for deprecation in a future release.

How are you using these credentials today?

We need your feedback to ensure we don't inadvertently break your team’s critical workflows, and to evaluate future security mitigations we are considering. Please reply to this discussion sharing your current implementation details which would be impacted by this. We would like to know:

1. What is the downstream consumer? When you run an explicit command to extract an Access Token, Password, or SFDX Auth URL, where does that secret go next? Are you passing it to a third-party testing tool, custom deployment script, external middleware, etc.? What are you trying to accomplish with this credential?
2. Why isn't standard CLI authentication enough? If you extract an SFDX Auth URL just to pass it to a secondary process to authenticate via sf org login sfdx-url, could that secondary process instead utilize JWT auth directly?
3. What would break if these explicit retrieval commands were deprecated entirely? If an alternative secure integration pattern (like a scoped JWT) was the only mechanism available, what specific use cases would still be impossible?

Proposal: Refresh token forced expiration window

In addition to removing secrets from outputs, we are considering hardening the security of SFDX Auth URLs by enforcing a strict expiration window on the underlying refresh tokens.

Today, users can store and reuse these URLs indefinitely. We are considering introducing a forced refresh token expiration window of 30 days or 45 days.

What would break in your environment if an SFDX Auth URL expired automatically after 30 or 45 days?

Please provide your feedback

Please drop a comment below detailing your workflow. You're free to engage in whatever manner you like, but to make things easer, you may want to consider using this format for your comments:

• Artifact used: (Access Token / Password / SFDX Auth URL)
• Job to be completed with the artifact:
• Downstream tool/system that is using the artifact:
• Impact of explicit command deprecation:
• Impact of a 30/45-day refresh token window:

We value the input of the Salesforce community as we navigate these changes in the CLI. Thank you for helping us make the Salesforce DX ecosystem secure by default.

[manjit5190]

Artifact used: (Access Token / Password / SFDX Auth URL): Sfdx Auth Url
Job to be completed with the artifact: Authenticate with CI/CD process (temporary write to file, read it and then delete it)
Downstream tool/system that is using the artifact: Github actions
Impact of explicit command deprecation: Minimal as long as there is a another command on how we can see the details.
Impact of a 30/45-day refresh token window: We will need to move to maybe correct way of doing thing by generating a certificate and JWT.

The impact is not huge, we just found the process to setup a secret with SFDX Auth URL easier

[junners]

Personal Opinion:

For sfdx-url, I think having a 30-45 day refresh token validity is fine. Sandboxes should be refreshed with the same frequency anyways so it's not really an issue. Productions also ok, just need a rotation strategy for it.

Traditionally, system to system integrations require service accounts which are usually tied with jwt, mtls cets, oauth. If we want a persistent, long lived system connection then we'll just secure then with the same mechanisms.

[LegendaryRob]

Coming at this from a developer/admin angle rather than CI/CD. We use a mix, mostly SFDX Auth URL, through VS Code and the local CLI.

My concern with deprecating the retrieval commands is recovery. When an org has a connected app issue or MFA problem and a fresh login won't work, being able to pull a stored auth has been our way back in. JWT doesn't really help there since it depends on the connected app being healthy in the first place.

On the 30/45 day expiration, would this apply to sandboxes too or just production? We run DevOps with multi-box pipelines, so between orgs and machines we can easily be over 100 to manage and more as we grow. If it's prod-only that's workable, but across all sandboxes too the reauth churn would add up fast. Some visibility into upcoming expirations across everything locally-authed would help a lot either way.

[codefriar]

@mitchspano

It might be beneficial to document alternative means of authenticating to dev hubs and scratch orgs in greater detail. Yes the SF url format is easy, and quick, but the JWT shared auth is almost as quick and easy, basically un-documented and exposes nothing.

[Damecek]

thanks to ai agents we switched easily from sfdx-url to jwt based auth

[codefriar]

@Damecek - agreed, it was easy to switch... once we realized it was an option

[JosephAllen]

What will the sf org auth show-user-password command reveal?

[mitchspano]

This shows the password after you have set it explicitly by calling sf org generate password.
This is used in scratch org setup, where the auto-generated "user user" does not have a password after the org is spun up.

I want to be clear that this will only show a password if you explicitly set it yourself using that command and only on that machine.

[codefriar]

@mitchspano btw, forgot to mention - thanks for this work.

[dunks184]

Artifact used: SFDX Auth URL
Job to be completed with the artifact: repeatedly login to scratch org during pipeline execution (different jobs in same pipeline using different containers).
Downstream tool/system that is using the artifact: GitLab pipeline jobs and also local dev fetching a scratch org from a pool using flxbl.io
Impact of explicit command deprecation: Pipeline would break and need to be redesigned.
Impact of a 30/45-day refresh token window: none

If there were a command to login to a scratch org given a logged in DevHub, this would be a non-issue. Although, we do also heavily use flxbl.io which would break and need to be rewritten quite a bit.

In our GitLab pipeline, we have several jobs (each running in separate containers) which need to login to the same scratch org.
We have a pre job which logs into the devhub, retrieves the sfdxAuthUrl of the scratch org (stored by flxbl.io), and then stores that in a cached file which is available to the other pipeline jobs (only exists for the life of the pipeline). Each other job in the pipeline is then able to log into the scratch org. It also means that there is no need for any of the pipeline jobs to log into the devhub (other than the initial auth store job). Since they only need to log into the scratch org, the risk of accidentally deploying to the devhub instead of the scratch org is almost illiminated.

[akruvi]

I'm glad that you're planning on tightening security, but these recommendations appear to look at the CLI as purely a CI/CD tool, neglecting the requirements from developers and consultants who use it daily.

Before I start, let me frame exactly what the issue with the CLI is:
The Salesforce CLI is a honeypot - a treasure trove for attackers - because a single developer or consultant would likely be connected to several (sometimes dozens) of orgs by different customers. A single successful attack could result in data leaking from many Salesforce customers.

Salesforce understands this risk. It's why last year you announced the restrictions concerning Connected Apps and how you would shut down vendors who you felt were breached. The issue is the same here.

We have to assume that any computer can and will be breached given enough effort. Whether it's a CI/CD server or app, or a person's home computer. Security is just as much about damage mitigation and "preparing for the worst" as it is "hoping for the best" and assuming nobody will ever gain access to a real user's physical machine.

Before we articulate a solution we need to consider the primary use cases of the CLI. Yes, CI/CD is an important one, one that has certain requirements:

1. Long-lived org connectivity
2. No active user participation to push authentication through
3. Orgs are usually a set of prod/dev/sandbox orgs belonging to the same entity
4. Used by a single server/device

But the developer/consultant requirements are vastly different:

1. Short-lived per-org sessions
2. Users actively around to authenticate further
3. Focus on 1-5 orgs at a time belonging to different customers
4. Orgs can lay dormant for months without use
5. User may log in from several devices onto the same user

From a security standpoint, these two scenarios could not be further apart.

Why Enforced Refresh Token Expiration Won't Work:
You're a developer. A customer you haven't worked with for 8 weeks calls you and asks for a change. You open VS Code and BAM: token expired. Re-authenticate. You have about 400 sandboxes overall, you barely remember the username for each one let alone the password. Reset password. 10 minutes and immense frustration later, you logged in. Not going to work for most of us.

My Approach:

1. Separate the CI/CD authentication from the Developer authentication path.
2. CI/CD path allows long-lived connections, but highly discouraged. Stricter scoping by default: Cannot generate login URLs, cannot use the UI (unless user explicitly requires different scoping). Refresh tokens expire after 30-45 days of non-use.
3. Developer path allows short-lived sessions, based on profile configuration in the org. Each session must go through MFA upon initial authentication. This becomes the standard authentication for most users. Refresh token does not expire to allow operation from multiple devices.

The Result:
In the inevitable event of a breach, the CI/CD path still exposes an org. Maybe not through the UI, but the API is enough. HOWEVER, rather than exposing 40 Salesforce customers, only one company suffers a breach.
The consultant path has much better gains, where even gaining physical access to a device does not compromise any Salesforce customers. Even if their entire set of credentials leaks it's unusable.

Additionally:
Slightly off-topic, but it would be fantastic if we could create our own MFA services (even if they have to run on top of existing MFA). For The Architech Club we've had an authenticator that allowed management to control exactly who can log in to what orgs, and when. The upcoming update breaks it and forces us to take a far less secure approach that cannot include management approval. Because having the authenticator sit on the browser (i.e. Bitwarden) is NOT actually secure. Food for thought.

Lastly:
It is incredibly important to note that teams have been dealing with a barrage of changes in recent months, many of which were imposed within very short time frames. Teams have to deliver more than just internal security updates - we need to deliver products and services to customers who have become much more demanding in the age of AI. You did right by giving a temporary flag to maintain backwards compatibility with existing behaviour, but super-short-term updates erode confidence in the platform. Use your power wisely.

[j-schreiber]

Summary

Artifact used: Access Token
Job to be completed with the artifact: Scratch Org API testing during package built pipelines
Downstream tool/system that is using the artifact: Jest/Mocha test runner
Impact of explicit command deprecation: Unable to run API tests in CI/CD context
Impact of a 30/45-day refresh token window: N/A

More Details

My use case is simple, but business critical. It requires accessing an (scratch org's) access token to run integration API tests during package build pipelines. Lots of our modules implement custom Apex REST endpoints, and these cannot be tested otherwise. As these tests do not have setup/teardown (like apex tests), we can only run them reliably during scratch org validation.

The code to retrieve the access token looks something like this

const targetOrgAuthInfo = () => {
  let targetOrg;
  process.argv.forEach((processArg) => {
    if (processArg.startsWith("target-org=")) {
      targetOrg = processArg.split("=")[1];
    }
  });
  return shell.exec(
    targetOrg
      ? `sf org display --target-org ${targetOrg} --json`
      : "sf org display --json",
    {
      silent: true,
      fatal: true
    }
  ).stdout;
};

And the actual test case (executed with jest or mocha looks like this

const result = await axios({
  method: "POST",
  url: `${authInfo.instanceUrl}/services/apexrest/v1/event/${testData.eventUri}`,
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${authInfo.accessToken}`
  },
  data: testData.request.body,
  validateStatus: () => true
});

This works perfectly, especially for data-driven tests that execute 100s of test cases, based on test-case files in a specific directory.

[sanderott]

We use a mixture of passwords & SFDX Auth URL

Job to be completed with the artifact:

1. SFDX Auth URL is used for our CICD to access our DevHub org.
2. SFDX Auth URL is used for logging into scratch orgs for our CICD & development processes.
3. Additionally passwords are generated for scratch orgs.

Downstream tool/system that is using the artifact:

1. Our CICD tooling makes use of the Auth URLs. CICD performs siloed interactions with the SF CLI, so once any CICD process finishes no trace remains of what orgs were logged into, no aliases remain stored, etc. It needs to log in to the DevHub with every new interaction.

The processes need to be siloed as they are, due to having various clients which run through the same CICD tooling.

2. Likewise, scratch orgs are created overnight. Because of the siloed approach, any CICD processes that need access to those scratch orgs won't have pre-existing connections to those scratch orgs stored. We securely store the SFDX Auth URLs of those scratch orgs when they are created so that we can establish a connection and interact with them in later processes.

Additionally, those Auth URLs also allow our devs to connect to scratch orgs created this way by the centralized DevHub account to perform actual work on, push & pull changes from, etc. on our local IDEs and machines.

3. Lastly we also generate passwords for scratch orgs for our admins who are not allowed access to the SF CLI in general for security reasons, who need a more web-based login approach.

Why isn't standard CLI authentication enough?
We initially used JWT authentication to connect CICD to our DevHub org and use it to make scratch orgs, but there are certain features that are not supported when a Hyperforce DevHub is connected via JWT which we require for our scratch orgs. The official recommendation was to switch to logging in using the SFDX Auth URL. If logging in to our DevHub via a JWT auth gave us all the functionalities that are supposed to be available for creating, configuring and populating (scratch) orgs, we'd happily switch back. If this info is no longer accurate by all means let us know.

Impact of explicit command deprecation:
As mentioned above, switching to JWT is not a workable solution for us currently. For our CICD processes to remain isolated there does need to be a way to somehow access and store SFDX Auth URLs.

The alternative for our CICD to hold on to the SF CLI's cache for log-in information, aliases, etc. would obviously open up a myriad of new potential security nightmares.

For passwords generated it would be less of an issue at this moment since the command to generate a password also immedaitely outputs the generated password, which can be safely stored from there. But then, if the goal is zero-exposure of credentials, a case could be made whether that command should even output the generated password to begin with.

Impact of a 30/45-day refresh token window:
A refresh token window sounds mostly fine and acceptable. For any scratch org that would just be its entire lifetime, and for more permanent orgs this would definitely lower potential risks of people who should no longer have access from accessing sensitive data.
That said, the SFDX Auth URL has also already proven itself to us as an effective emergency tool to access our org when there have been problems with MFA login.

Additional thoughts & concerns:
The distillation of extracting sensitive authentication information into dedicated auth commands is a good step in the right direction. And if those auth commands were reworked at some point to no longer show encrypted credentials rather than plain-text, that could also be workable.
However, when it comes to scrapping those commands completely; there does come a point where developers simply need to have access to information like this to be able to do their jobs. The same way that someone who works with Salesforce at some point needs to be trusted with access to the data in Salesforce in general, developers too at some point need to be trusted to handle sensitive information like this with care.
Taking steps to prevent misuse, leaks, etc. is important, but the focus on preventing authentication concerns shouldn't overshadow the ability of people to do their job.

I'd also like to second the thoughts of @akruvi here regarding this current change. The recent flurry of security-related changes that has been pushed across the broader line of Salesforce products with short time frames is a lot to keep up with, the timing of this change alongside only a 7-day implementation window (lest your entire integration with Salesforce breaks) on top of all those other security changes that are already keeping teams scrambling. Why the need to have a run-through time between announcement and enforcement of this breaking change of only a week for something that has existed as it has for years?

[CAfromCA]

Can I ask why a breaking change was announced with a week of warning? Lots of your customers will discover tools and pipelines broke out of the blue some random day after next Wednesday (the next time they update the CLI). It appears this is going to happen between 2.135.7 and 2.136.8, which from the version number change looks like a minor (i.e. not breaking) release.

And why is this being rolled out in a single release with no overlap? There will apparently be no CLI version where sf org display --json and sf org auth show-access-token --json both work out of the box (without also deploying the "temporary workaround" environment variable).

This doesn't feel like how feature deprecation is supposed to go.

[petter-eikeland]

Artifact used: SFDX Auth URL
Job to be completed with the artifact: Automatic provisioning of scratch orgs by a DevHub authenticated CI user, to be consumed by developers and other CI jobs. The artifact is stored on the ScratchOrgInfo record in Production. Production access is thus required to consume the artifact.
Downstream tool/system that is using the artifact: Developers and CI jobs
Impact of explicit command deprecation: Mayhem
Impact of a 30/45-day refresh token window: Scratch org provisioning --> unaffected

My 2 cents:
At the very least, keep the SFDX Auth URL option for Scratch orgs only given they're ephemeral. Our developers and CI user can authenticate to the DevHub via JWT auth as you suggest.

However

A JWT authenticated CI user is not able to generate SFDX Auth URLs for scratch orgs. This is because the DevHub's auth flow is propagated into each scratch org it provisions. A JWT-authed DevHub yields JWT-authed scratch-org AuthInfo with no refresh token, thus making it impossible to generate SFDX Auth URLs for them. A permanent solution would be needed for this first.