Access Token Issue in Production Environment

[Alfystar]

Description:
Our team encountered a problem accessing the production environment using the access token. This access is required on the release day to perform verifications from the terminal with specific profiles. The procedure we followed worked on the same day and in previous instances in all sandboxes, but not in the production org. We had to revert to using ANT for retrievals, which worked despite being discontinued for almost 2 years.

Steps to obtain access-token from UI:

1. [Optional] Execute 'Login-As' if the token is for a different user.
2. Go to the 'Setup' tab in the desired Org.
3. Open the Developer console of the browser (in Chrome, use 'CTRL+SHIFT+C').
4. Navigate to the 'Application' tab -> 'Cookies' vertical menu -> 'Current Org' item. Filter the table for 'sid'.
5. Test each 'cookie' value until finding the one that works.

We obtained an access token: 00D240000*********oVjV75s3.

Command Executed:

SF_ACCESS_TOKEN=<AccessToken>
$ sf org login access-token --instance-url 'https://enelcrmt.my.salesforce.com' --alias PROD --no-prompt

We also try different instance-url but notting change 😔
Doc info we follow

Error Message:

Error (AuthCodeUsernameRetrievalError):
Could not retrieve the username after successful auth code exchange.
Due to: Bad_OAuth_Token

Additional Information:

• The same token worked when using ANT, which is discontinued.
• The token was passed correctly to sf-cli, as it worked in the sandboxes on the same day.

We request further information and assistance regarding this issue.

System Information

 CLI Version:
        @salesforce/cli/2.82.6 published 12 days ago (Wed Mar 26 2025)

 Architecture:
        darwin-arm64

 Node Version:
        node-v23.10.0

 Plugin Version:
        @oclif/plugin-autocomplete 3.2.26 (core)
        @oclif/plugin-commands 4.1.22 (core)
        @oclif/plugin-help 6.2.27 (core)
        @oclif/plugin-not-found 3.2.48 (core)
        @oclif/plugin-plugins 5.4.36 (core)
        @oclif/plugin-search 1.2.23 (core)
        @oclif/plugin-update 4.6.35 (core)
        @oclif/plugin-version 2.2.27 (core)
        @oclif/plugin-warn-if-update-available 3.1.38 (core)
        @oclif/plugin-which 3.2.34 (core)
        @salesforce/cli 2.82.6 (core)
        apex 3.6.11 (core)
        api 1.3.3 (core)
        auth 3.6.107 (core)
        data 4.0.23 (core)
        deploy-retrieve 3.21.1 (core)
        info 3.4.50 (core)
        limits 3.3.51 (core)
        marketplace 1.3.7 (core)
        org 5.5.5 (core)
        packaging 2.12.3 (core)
        schema 3.3.57 (core)
        settings 2.4.21 (core)
        sobject 1.4.53 (core)
        telemetry 3.6.36 (core)
        templates 56.3.43 (core)
        trust 3.7.75 (core)
        user 3.6.15 (core)
        sfdx-plugin-source-read 1.5.1 (user) published 18 days ago (Wed Mar 19 2025)

 OS and Version:
        Darwin 24.3.0

 Shell:
        zsh

 Root Path:
        /opt/homebrew/lib/node_modules/@salesforce/cli

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[cristiand391]

Assuming you grabbed a valid token, that's likely a restriction on prod orgs, sf tries to get the user info via this endpoint:
https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_using_userinfo_endpoint.htm&type=5

curl  'https://site-velocity-4058-dev-ed.scratch.my.salesforce.com/services/oauth2/userinfo' -H "Authorization: Bearer lala"
Bad_OAuth_Token%

unfortunately no more info is returned.

[Alfystar]

Is there any test I can do?
Because on the ANT side it worked without problems by putting the token in the "SessionId" configuration variable
It seems strange to me that a program that is now discontinued still works for this purpose, while sf-cli crashes.

The org and the moment at the issue time is the same, so I exclude it is a configuration problem of the Org

[cristiand391]

It depends on whether you're in Lightning or not. Lightning sessions do not have API access, as a security measure. If you're in Classic (e.g. Visualforce), that session Id will have valid API access.

https://salesforce.stackexchange.com/a/414444

I was able to confirm this with the curl command shared above, the session id from the classic session worked but the lightning one returns "invalid session id".

Because on the ANT side it worked without problems by putting the token in the "SessionId" configuration variable
It seems strange to me that a program that is now discontinued still works for this purpose, while sf-cli crashes.

it might be that ANT just uses the token for requests, while sf org login access-token first tries to do some oauth calls to get additional user information for proper authentication.

[Alfystar]

Your analysis makes sense to me, but now we have a problem, do you think we can find a workaround? Or maybe create a login with a "weaker" access-token that only allows downloading from the org as if you were a certain user?

We need this function during releases to perform a consistency check, and for some metadata it depends on the user used.

Let me explain better: Personally I did not understand how to use the chrome.identity feature mentioned on stackoverflow, and if I understood correctly it would not be compatible with sf org login access-token, correct?

[cristiand391]

do you think we can find a workaround? Or maybe create a login with a "weaker" access-token that only allows downloading from the org as if you were a certain user?

I don't think so, all of our commands follow the oauth protocol for authentication (sf org login access-token expects the access token to be obtained from an oauth-authorized app).

Let me explain better: Personally I did not understand how to use the chrome.identity feature mentioned on stackoverflow, and if I understood correctly it would not be compatible with sf org login access-token, correct?

I think chrome.identity is a chrome extension API, the OP mentioned they were working on an extension.
It would work if the chrome extension was implemented using oauth (its own connected app, like the CLI does).

Since grabbing a token from cookies look like a manual process (if you automated this then you have resources to automate sf auth commands), why not just do proper auth via sf org login web or jwt auth?

[Alfystar]

The question is legitimate, we proceed like this, in the release phase, because not always on Sundays the people who have that user are engaged in that release.
And by taking advantage of the login as, enabled only for devs, we could do the technical checks on their behalf without problems.

Another (wrong) solution could be ask them username and password, but because we having a 2-factor login in production it is not even possible to have their username and password
Also, as you can image, the security risk associated with this practice is elevate.

For all these reasons, the use of the "sid" seemed to us a good solution

I hope I have been clear about the need for this feature.

[cristiand391]

I hope I have been clear about the need for this feature.

I just remembered this, --target-org supports passing an access token as a value (no need to authenticate previously), try this:

1. set the SF_ORG_INSTANCE_URL env var to the My Domain org URL
2. set SF_AT to the access token
3. pass the SF_AT env var as a value for --target-org, in unix: sf data query -q 'select id,name from ConnectedApplication' -o $SF_AT

See if it works with the commands you need to run for your checks @Alfystar (sorry for the late reply!)

[Alfystar]

Thanks @cristiand391!

I'm on vacation now and I don't have a way to test, but I'll update you as soon as I get back!
Thank you so much!

[github-actions]

This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.