Auth Commands

Commands for authentication and token management.

Stateful vs stateless auth

The CLI supports stateful auth (session stored on disk) in addition to stateless auth (client credentials or one-off browser login):

• Stateful (browser): After you run b2c auth login, your access token and a long-lived refresh token are stored on disk in the CLI data directory. Subsequent commands silently refresh the access token without re-prompting. If both tokens are missing/expired, the CLI falls back to stateless auth.
• Stateful (client credentials): Use b2c auth client to authenticate with client ID and secret (or user/password) for non-interactive/automation use. Only the access token is persisted — the client secret is never stored. When the access token expires, re-run b2c auth client with the same credentials. There is no automatic refresh.
• Stateless: You provide --client-id (and optionally --client-secret) per run or via environment/config; no session is persisted.

After auth login or auth client, you do not need to provide the client ID again. When a later command has no client configured, it automatically reuses the valid saved session.

The CLI falls back to stateless auth when the stored token is expired/invalid, or when --client-secret, --user-auth, or --auth-methods are passed on the command line. In both cases a warning is shown explaining why stateful auth was skipped. Note that --client-id alone does not force stateless; the stored session is used if the configured client ID matches. To opt out of stateful auth entirely, run b2c auth logout to clear the stored session.

Use auth:logout to clear the stored session and return to stateless-only behavior.

b2c auth login

Log in via browser (Authorization Code + PKCE) and save the session for stateful auth. The access token is silently refreshed via the persisted refresh token; you only see a browser prompt when the refresh token also expires (typically after 24 hours of disuse).

Usage

b2c auth login [CLIENTID]

CLIENTID is an optional positional argument. When omitted, the SFCC_CLIENT_ID environment variable is used as a fallback.

# Using a positional argument
b2c auth login your-client-id

# Using environment variable
export SFCC_CLIENT_ID=your-client-id
b2c auth login

After a successful login, subsequent commands reuse and refresh the stored token until the refresh token expires or you run b2c auth logout.

Flags

Flag	Environment Variable	Description
--account-manager-host	SFCC_ACCOUNT_MANAGER_HOST	Account Manager hostname
--auth-scope	SFCC_OAUTH_SCOPES	OAuth scopes to request (can be repeated)
--auth-methods	SFCC_AUTH_METHODS	Browser-based flow to use: user (default — Authorization Code + PKCE) or implicit (deprecated)

Choosing a flow

auth login defaults to Authorization Code + PKCE, which is the recommended browser flow for public clients. The legacy implicit flow is still selectable for clients that haven't been migrated:

# Default: Authorization Code + PKCE
b2c auth login your-client-id

# Legacy implicit flow (emits a deprecation warning)
b2c auth login your-client-id --auth-methods implicit

OAuth 2.1 deprecates the implicit flow for public clients. Configure your Account Manager API client as a public client and use the default PKCE flow when possible.

Account Manager prerequisites

To use the browser-based user flow with your own client, create a public client in Account Manager (not a confidential client — public clients have no secret, and selecting that type configures the Authorization Code + PKCE grant automatically). A client's type can't be changed after creation, so an existing implicit-only client must be replaced by a newly-created public client, not converted. Add the CLI's redirect URI to the client's allowed redirect URIs — by default http://localhost:8080 (override the port with SFCC_OAUTH_LOCAL_PORT or the whole URI with SFCC_REDIRECT_URI).

If a client is still registered as implicit-only, the user flow automatically falls back to the implicit flow and logs a deprecation warning. After a successful fallback, later sign-ins use the compatible flow directly. Create a new public client and use it to silence the warning, or set SFCC_DISABLE_PKCE_FALLBACK=1 to force PKCE and surface the failure directly.

b2c auth logout

Clear the stored OAuth session (stateful auth). After logout, commands use stateless auth when configured.

b2c auth logout

b2c auth client

Authenticate an API client using client credentials or resource owner password credentials and save the access token for stateful auth. The client secret is never persisted: when the access token expires, re-run this command with the same credentials. There is no automatic refresh for client_credentials sessions — for refresh-capable user authentication, use b2c auth login (PKCE) instead.

This is the non-interactive alternative to auth login — ideal for CI/CD pipelines and automation.

Usage

# Client credentials grant (client ID + secret)
b2c auth client --client-id <id> --client-secret <secret>

# Resource owner password credentials grant (+ user credentials)
b2c auth client --client-id <id> --client-secret <secret> --user <email> --user-password <pwd>

# Force a specific grant type
b2c auth client --client-id <id> --client-secret <secret> --grant-type client_credentials

Flags

Flag	Environment Variable	Description
--client-id	SFCC_CLIENT_ID	Client ID (required)
--client-secret	SFCC_CLIENT_SECRET	Client secret (required)
--grant-type / -t		Force grant type: client_credentials or password
--user	SFCC_OAUTH_USER_NAME	Username for password grant
--user-password	SFCC_OAUTH_USER_PASSWORD	Password for password grant
--auth-scope	SFCC_OAUTH_SCOPES	OAuth scopes to request
--account-manager-host	SFCC_ACCOUNT_MANAGER_HOST	Account Manager hostname

Grant type auto-detection

If --grant-type is not specified:

• client_credentials is used when only --client-id and --client-secret are provided
• password is used when --user and --user-password are also provided

Examples

# Authenticate for automation (CI/CD)
export SFCC_CLIENT_ID=my-client
export SFCC_CLIENT_SECRET=my-secret
b2c auth client

# Authenticate with user credentials
b2c auth client --client-id <id> --client-secret <secret> \
  --user admin@example.com --user-password secret123

b2c auth client token

Return the current stored authentication token. Compatible with the sfcc-ci client:auth:token workflow.

Usage

# Raw token to stdout (pipe-friendly)
b2c auth client token

# Full metadata as JSON
b2c auth client token --json

Output

Raw token output (default):

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

JSON output (--json):

{
  "accessToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "clientId": "my-client-id",
  "expires": "2025-01-27T12:00:00.000Z",
  "scopes": ["mail", "roles"],
  "user": "admin@example.com",
  "renewable": true
}

b2c auth token

Get an OAuth access token for use in scripts or other tools.

Usage

b2c auth token

Flags

Flag	Environment Variable	Description
--client-id	SFCC_CLIENT_ID	Client ID for OAuth
--client-secret	SFCC_CLIENT_SECRET	Client Secret for OAuth
--auth-scope	SFCC_OAUTH_SCOPES	OAuth scopes to request (can be repeated)
--client-auth-method	SFCC_CLIENT_AUTH_METHOD	How client credentials are sent: basic (default), basic-unencoded, or body. See client authentication method
--account-manager-host	SFCC_ACCOUNT_MANAGER_HOST	Account Manager hostname (default: account.demandware.com)
--short-code	SFCC_SHORTCODE	SCAPI short code
--tenant-id	SFCC_TENANT_ID	Organization/tenant ID
--auth-methods	SFCC_AUTH_METHODS	Allowed auth methods in priority order (comma-separated): client-credentials, jwt, user, implicit, basic, api-key
--user-auth		Use browser-based user authentication (Authorization Code + PKCE flow)
--jwt-cert	SFCC_JWT_CERT	Path to JWT certificate file (cert.pem) for JWT Bearer authentication
--jwt-key	SFCC_JWT_KEY	Path to JWT private key file (key.pem) for JWT Bearer authentication
--jwt-passphrase	SFCC_JWT_PASSPHRASE	Passphrase for encrypted JWT private key

Examples

# Get a token with default scopes
b2c auth token --client-id xxx --client-secret yyy

# Get a token with specific scopes
b2c auth token --auth-scope sfcc.orders --auth-scope sfcc.products

# Output as JSON (useful for parsing)
b2c auth token --json

# Using environment variables
export SFCC_CLIENT_ID=my-client
export SFCC_CLIENT_SECRET=my-secret
b2c auth token

Output

The command outputs the access token:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

With --json:

{"token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...", "expires_in": 1799}

Use Cases

Scripting

Use the token in shell scripts:

TOKEN=$(b2c auth token)
curl -H "Authorization: Bearer $TOKEN" https://my-instance.demandware.net/s/-/dw/data/v24_3/sites

CI/CD Pipelines

Get a token for use with other tools:

export SFCC_TOKEN=$(b2c auth token --json | jq -r '.token')

Testing API Calls

Quickly get a token for testing OCAPI or SCAPI:

b2c auth token | pbcopy  # macOS: copy to clipboard

---

Authentication Overview

For complete authentication setup instructions, see the Authentication Setup Guide.

Quick Reference

Operation	Auth Required
Code deploy/watch	WebDAV credentials
Code list/activate/delete, Jobs, BM users/roles	OAuth + SCAPI scopes (OCAPI fallback; OCAPI is deprecated)
Sites list/cartridge reads	OAuth + SCAPI scopes (sfcc.sites; OCAPI fallback)
Sites cartridge-path writes	OAuth + sfcc.sites.rw (OCAPI / site-archive fallback)
SCAPI commands (eCDN, schemas, custom-apis)	System OAuth (client credentials/JWT) + SCAPI scopes; browser PKCE/implicit is rejected
Sandbox, SLAS	OAuth + appropriate roles
MRT	API Key

See Configuration for setting up credentials via environment variables or config files.

TIP

Each command page below documents its specific authentication requirements including required scopes.