fix(slas): drive PKCE for registered login on private clients (@W-23235332)

`b2c slas token --shopper-login/--shopper-password` failed against a
PRIVATE SLAS client with `HTTP 400 code_verifier is required`. The
registered flow's `/oauth2/login` step always presents a
`code_challenge`, but the private-client token exchange downgraded to
`grant_type=authorization_code` and omitted `code_verifier`, so SLAS
rejected it.

Unify the registered token exchange: always use
`authorization_code_pkce` with the matching `code_verifier` for both
public and private clients; a private client additionally authenticates
with its secret via HTTP Basic. This matches commerce-sdk-isomorphic's
`loginRegisteredUserB2C`. Guest and `client_credentials` flows unchanged.

- Rewrite SDK `getRegisteredToken` token exchange (single PKCE path).
- Fix SDK test that had codified the buggy `authorization_code`
  contract; it now asserts PKCE + `code_verifier` + Basic auth.
- Update slas docs flow table + b2c-slas skill.
- Changeset (patch, @salesforce/b2c-tooling-sdk).

Author: clavery

.changeset/slas-registered-private-pkce.md

@@ -0,0 +1,5 @@
+---
+'@salesforce/b2c-tooling-sdk': patch
+---
+
+Fix `b2c slas token` registered-customer login failing against a private SLAS client with `HTTP 400 code_verifier is required`. The registered login flow is always PKCE-protected, so the token exchange now always sends the `code_verifier` with the `authorization_code_pkce` grant — and, for private clients, additionally authenticates with the client secret via HTTP Basic. Registered login now works on both public and private clients; guest and `client_credentials` flows are unchanged.

docs/cli/slas.md

@@ -76,15 +76,20 @@ b2c slas token --tenant-id <TENANT_ID> --site-id <SITE_ID>
 
 ### Flows
 
-The command automatically selects the appropriate authentication flow:
+The command automatically selects the appropriate authentication flow based on whether `--shopper-login` and `--slas-client-secret` are provided:
 
 | Scenario | Flow |
 |----------|------|
-| No `--slas-client-secret` | Public client PKCE (authorization_code_pkce) |
-| With `--slas-client-secret` | Private client (client_credentials) |
-| With `--shopper-login` | Registered customer login |
+| Guest, no `--slas-client-secret` | Public client guest PKCE (`authorization_code_pkce`) |
+| Guest, with `--slas-client-secret` | Private client `client_credentials` |
+| Registered (`--shopper-login`), no secret | Registered login + PKCE (`authorization_code_pkce`) |
+| Registered (`--shopper-login`), with secret | Registered login + PKCE, plus client-secret Basic auth |
 | No `--slas-client-id` | Auto-discovers first public client via SLAS Admin API |
 
+::: tip Registered login uses PKCE on both public and private clients
+The registered-customer flow is always PKCE-protected: the `/oauth2/login` step presents a `code_challenge`, so the token exchange always sends the matching `code_verifier`. A private SLAS client additionally authenticates with its secret (HTTP Basic). This is why the registered flow works against both public and private clients.
+:::
+
 ### Examples
 
 ```bash

packages/b2c-tooling-sdk/src/slas/token.ts

@@ -213,8 +213,15 @@ async function getPrivateClientGuestToken(config: SlasTokenConfig): Promise<Slas
  * Uses the `/oauth2/login` endpoint with shopper credentials, then exchanges
  * the authorization code for an access token.
  *
- * - **Public client**: Uses PKCE for code exchange.
- * - **Private client**: Uses client credentials (Basic auth) for code exchange.
+ * The registered-customer flow is PKCE-protected for **both** public and
+ * private clients: a `code_challenge` is always presented at the
+ * `/oauth2/login` step, so the matching `code_verifier` must always be sent at
+ * the token exchange with the `authorization_code_pkce` grant.
+ *
+ * - **Public client**: PKCE token exchange (no client secret).
+ * - **Private client**: PKCE token exchange, plus HTTP Basic authentication
+ *   using the client secret. The client must NOT drop PKCE, or SLAS rejects the
+ *   exchange with `400 code_verifier is required`.
  *
  * @param config - SLAS token configuration including shopper credentials
  * @returns The token response including access_token and refresh_token
@@ -265,37 +272,16 @@ export async function getRegisteredToken(config: SlasRegisteredLoginConfig): Pro
   const {code, usid} = parseRedirectCode(location);
   logger.debug({usid}, '[SLAS] Got authorization code from login');
 
-  // Step 2: Exchange code for token
+  // Step 2: Exchange code for token.
+  //
+  // The login step always presents a `code_challenge`, so the token exchange
+  // must always send the matching `code_verifier` with the
+  // `authorization_code_pkce` grant — for both public and private clients.
+  // A private client additionally authenticates with HTTP Basic using its
+  // secret; it must NOT downgrade to the plain `authorization_code` grant or
+  // SLAS rejects the exchange with `400 code_verifier is required`.
   const tokenUrl = `${baseUrl}/oauth2/token`;
 
-  if (isPrivate) {
-    const basicAuth = Buffer.from(`${config.slasClientId}:${config.slasClientSecret}`).toString('base64');
-    const tokenBody = new URLSearchParams({
-      grant_type: 'authorization_code',
-      code,
-      redirect_uri: config.redirectUri,
-      channel_id: config.siteId,
-      usid,
-    });
-
-    const {response: tokenResponse} = await loggedFetch(tokenUrl, {
-      method: 'POST',
-      headers: {
-        'Content-Type': 'application/x-www-form-urlencoded',
-        Authorization: `Basic ${basicAuth}`,
-      },
-      body: tokenBody,
-    });
-
-    await checkResponse(tokenResponse, 'token exchange (authorization_code)');
-    const data = (await tokenResponse.json()) as SlasTokenResponse;
-    const respHeaders = serializeHeaders(tokenResponse);
-    logger.trace({headers: respHeaders, body: data}, `[SLAS RESP BODY] POST ${tokenUrl}`);
-
-    return data;
-  }
-
-  // Public client — use PKCE
   const tokenBody = new URLSearchParams({
     grant_type: 'authorization_code_pkce',
     client_id: config.slasClientId,
@@ -306,9 +292,15 @@ export async function getRegisteredToken(config: SlasRegisteredLoginConfig): Pro
     usid,
   });
 
+  const tokenHeaders: Record<string, string> = {'Content-Type': 'application/x-www-form-urlencoded'};
+  if (isPrivate) {
+    const basicAuth = Buffer.from(`${config.slasClientId}:${config.slasClientSecret}`).toString('base64');
+    tokenHeaders.Authorization = `Basic ${basicAuth}`;
+  }
+
   const {response: tokenResponse} = await loggedFetch(tokenUrl, {
     method: 'POST',
-    headers: {'Content-Type': 'application/x-www-form-urlencoded'},
+    headers: tokenHeaders,
     body: tokenBody,
   });
 

packages/b2c-tooling-sdk/test/slas/token.test.ts

@@ -193,9 +193,19 @@ describe('slas/token', () => {
   });
 
   describe('getRegisteredToken - private client', () => {
-    it('logs in with shopper credentials and exchanges code with Basic auth', async () => {
+    it('exchanges code via PKCE with Basic auth (sends code_verifier)', async () => {
+      // Regression test for W-23235332: the login step always presents a
+      // code_challenge, so the private-client token exchange must send the
+      // matching code_verifier with the authorization_code_pkce grant. The
+      // previous behavior used grant_type=authorization_code WITHOUT a
+      // code_verifier, which SLAS rejects with "400 code_verifier is required".
+      let loginChallenge: string | null = null;
       server.use(
-        http.post(`${BASE_URL}/oauth2/login`, () => {
+        http.post(`${BASE_URL}/oauth2/login`, async ({request}) => {
+          const params = new URLSearchParams(await request.text());
+          loginChallenge = params.get('code_challenge');
+          expect(loginChallenge).to.be.a('string');
+
           return new HttpResponse(null, {
             status: 303,
             headers: {
@@ -210,8 +220,13 @@ describe('slas/token', () => {
 
           const body = await request.text();
           const params = new URLSearchParams(body);
-          expect(params.get('grant_type')).to.equal('authorization_code');
+          expect(params.get('grant_type')).to.equal('authorization_code_pkce');
+          expect(params.get('client_id')).to.equal('test-client-id');
           expect(params.get('code')).to.equal('priv-code');
+          // The verifier must be present so SLAS can validate the challenge.
+          expect(params.get('code_verifier')).to.be.a('string').and.not.empty;
+          expect(params.get('channel_id')).to.equal('RefArch');
+          expect(params.get('usid')).to.equal('usid-priv');
 
           return HttpResponse.json(MOCK_TOKEN_RESPONSE);
         }),

skills/b2c-cli/skills/b2c-slas/SKILL.md

@@ -116,6 +116,11 @@ curl -H "Authorization: Bearer $TOKEN" "https://$SHORTCODE.api.commercecloud.sal
 
 # Override the SLAS client explicitly (e.g., targeting a private client for client_credentials flow)
 b2c slas token --site-id RefArch --slas-client-id my-client --slas-client-secret sk_xxx
+
+# Registered customer token against a private client (registered login is always PKCE-protected;
+# the client secret is sent as Basic auth in addition to the PKCE code_verifier)
+b2c slas token --site-id RefArch --slas-client-id my-client --slas-client-secret sk_xxx \
+  --shopper-login user@example.com --shopper-password secret
 ```
 
 ### Update SLAS Client