Cursor / VSCode - Potential Double Authentication on Open (minor annoyance)

[clstopher]

Describe the bug
Whenever I open Cursor, it immediately opens a browser window to authenticate with SF. After filling in my credentials and 2FA code (in case it matters, I use Google Authenticator for my second factor), the tab says "Authentication successful! You may close this browser window and return to your terminal." as expected, but before I have a chance to respond, a second browser tab opens with the same message.

NOTE: I just noticed - If I'm already authenticated before I open Cursor, I immediately get the 1 success tab opened, and no second tab opens. So it seems to be related to the process / timing of entering my credentials.

Environment

• b2c-cli version: 1.21.3 darwin-arm64 node-v26.7.0
• Node.js version: v22.23.1
• OS: Mac OS Tahoe 26.6.2
• Cursor version: 3.16.29
• Salesforce B2C Commerce VSCode Plugin version: v1.1.1

[clavery]

We just shipped PKCE support and this rolled into VSCode. And this functionality has a fallback mechanism if you're using an older AM client using implicit auth (i.e. if you were using implicit auth before this week).

It's possible this fallback mechanism is triggering the double browser open. This didn't seem to be the case on the CLI so I'll look into it.

But there are two workarounds right now:

• Switch to the public client: make a new one in account manager and select the public client option. This uses the modern, non deprecated auth mechanism rather than the super old implicit. And this is what we recommend going foward. Docs here https://salesforcecommercecloud.github.io/b2c-developer-tooling/guide/authentication.html#implicit-flow-deprecation
• As mentioned in the docs above you can force implicit again and get the old behavior back with a config on your environment. Eventually we will deprecate this though for security reasons (or if account manager beats us to it).

This also doesn't affect private client auth (when you have a secret). That is unchanged. This is only when a client ID is used with no secret which triggers "user auth"

[clavery]

FYI I've found a couple improvements to this in the worst case too: for instance we can just persist that your client can't support the newer method and so you'll only see this happen once forever (at most) for a particular client

[clstopher]

Thanks, @clavery - I have just stumbled through some dusty memories to remember my precise current authentication situation, and realizing it is probably unusual...

Long ago I found a SFCC Client ID associated with our "zz" realm, and I have been using that in my dw.json file as a basis for getting sent to the SFCC Account Login environment, where I provide my standard SFCC credentials.

The SFCC Client ID associated with the "zz" realm doesn't have permissions for the client realms that I work on (or at least, I assume it doesn't... But I also haven't ever tried to find or use the secret associated to it) - But my account does, so the combination has been allowing me to do what I needed to do all along.

I've passed along your note on the implicit flow deprecation, and I'll see about how to move forward in a more appropriate manner.

Feel free to close this issue if it doesn't apply to "real" scenarios!

[clavery]

That's a valid scenario and is valid with public clients too. It's effectively what we mean by "user auth" and it doesn't require the client itself to be in the target realms/org (because the client is only providing the auth mechanism and not the authorization anymore).

In any case I have some changes going in shortly that smooths this out a bit.

[clavery]

Related PR #634