## 一、核心定义

SAP Commerce Cloud Composable Storefront 里的 **client token**，是一个代表“前端应用程序身份”的 OAuth access token。

这里的 `client` 不是正在购物的 customer，而是 Composable Storefront 这个客户端应用。例如：

```text
Composable Storefront 应用
        ↓
使用自己的 OAuth client_id
        ↓
取得 client access token
        ↓
调用需要应用级认证的 OCC API
```

SAP Commerce Cloud 官方文档将 OAuth token 区分为两类：

* **Client OAuth token**：认证调用 API 的客户端应用。
* **User OAuth token**：认证已经登录的用户。([SAP Help Portal][1])

因此，可以用一句话概括：

> client token 证明“这是一个被 SAP Commerce Cloud 认可的 storefront 应用发出的请求”，但它不能证明“某个具体用户已经登录”。

---

## 二、不要混淆三个相似概念

在 Composable Storefront 的代码和配置中，容易同时看到以下三个东西。

### 1. OAuth client

这是 SAP Commerce Cloud 后台配置的 OAuth 客户端，例如：

```text
client_id = mobile_android
```

或者项目中自定义的：

```text
client_id = my_composable_storefront
```

它代表一个应用程序，而不是某个顾客。

---

### 2. Client token

这是 OAuth authorization server 签发给这个 OAuth client 的 access token，实际请求中通常表现为：

```http
Authorization: Bearer eyJ...
```

后端收到它以后，可以识别：

```text
调用者是 my_composable_storefront 这个 OAuth client
```

但它不包含当前登录顾客的业务身份，例如：

```text
customerId
email
uid
```

至少不能把它等同于某位顾客的登录 token。

---

### 3. `USE_CLIENT_TOKEN`

`USE_CLIENT_TOKEN` 不是 client token 本身。

在公开的 Spartacus 源码实现中，它只是一个供 Angular HTTP interceptor 使用的内部请求标记：

```typescript
export const USE_CLIENT_TOKEN = 'cx-use-client-token';
```

某个 OCC adapter 通过该标记告诉认证拦截器：

> 这个请求需要使用 client token。

`ClientTokenInterceptor` 读取这个标记后，会把它从请求中删除，然后取得真正的 client token，并设置标准的 `Authorization` header。也就是说，`cx-use-client-token` 原则上不会作为业务 header 被发送给 SAP Commerce Cloud。([sap.github.io][2])

所以：

```text
USE_CLIENT_TOKEN
```

是“使用 client token 的内部指令”，而：

```http
Authorization: Bearer <access_token>
```

才是真正发送到后端的 OAuth 凭证。

---

## 三、完整工作流程

假设 Composable Storefront 要调用一个匿名购物车相关的 OCC API。

### 第一步：OCC adapter 标记请求

旧版公开源码中可以看到类似代码：

```typescript
let headers = new HttpHeaders();

headers = InterceptorUtil.createHeader(
  USE_CLIENT_TOKEN,
  true,
  headers
);
```

生成的 Angular 请求在前端拦截器链内部暂时带有：

```http
cx-use-client-token: true
```

这只是内部信号。

---

### 第二步：`ClientTokenInterceptor` 识别标记

拦截器检查请求：

```typescript
const isClientTokenRequest =
  this.isClientTokenRequest(request);
```

如果发现 `USE_CLIENT_TOKEN`，就先删除这个内部 header：

```typescript
request =
  InterceptorUtil.removeHeader(
    USE_CLIENT_TOKEN,
    request
  );
```

因此，浏览器真正向 OCC 发请求时，通常不应该看到：

```http
cx-use-client-token: true
```

---

### 第三步：取得真正的 client token

认证服务负责取得 client access token。传统实现通常通过 OAuth Client Credentials Flow 向 authorization server 请求 token，例如：

```http
POST /authorizationserver/oauth/token
Content-Type: application/x-www-form-urlencoded
```

传统参数形式大致是：

```text
grant_type=client_credentials
client_id=<storefront-client-id>
client_secret=<client-secret>
```

SAP 的安装文档也展示了通过 `client_id`、`client_secret` 和 `client_credentials` grant 获取 access token 的传统配置方式。([SAP Help Portal][3])

不过，较新的 JDK 21 和 OAuth 2.1 配置已经更多地采用 public client、Authorization Code Flow 和 PKCE。具体使用哪种方式，必须根据你的 SAP Commerce Cloud、authorization server 和 Composable Storefront 版本判断，不能把旧版 `mobile_android / secret` 示例直接照搬到生产环境。

---

### 第四步：加入真正的 Authorization header

拦截器取得 token 后，会把请求改写为：

```http
Authorization: Bearer <client-access-token>
```

公开源码中的核心逻辑类似：

```typescript
request = request.clone({
  setHeaders: {
    Authorization:
      `${token.token_type || 'Bearer'} ${token.access_token}`,
  },
});
```

而且旧版实现只会向配置的 OCC base URL 添加该 token，避免把 Commerce token 意外发送到无关第三方域名。([sap.github.io][2])

---

### 第五步：OCC 验证应用身份

SAP Commerce Cloud 收到请求后验证：

```text
token 是否有效
token 是否过期
token 对应哪个 OAuth client
该 client 是否拥有相应 scope 或 authority
目标 endpoint 是否允许该 client 调用
```

验证通过后，OCC 才继续处理请求。

---

## 四、为什么匿名用户还需要 client token

很多人会产生这个疑问：

> 用户没有登录，为什么还需要 token？

因为“没有用户登录”和“任何未知程序都能调用”是两回事。

一个 OCC endpoint 可能不要求 customer 身份，但仍要求调用者是一个被认可的应用，例如：

```text
允许官方 storefront 调用
不希望未知脚本随意调用
```

这类 API 可以理解为：

```text
不需要 user authentication
但需要 client authentication
```

SAP 官方对 `AuthConfig.authentication.useClientTokens` 的描述也是：控制是否向“原本属于 public 的 API”发送 client token。换句话说，这里的 public 主要表示不要求已登录用户身份，不一定表示完全没有 OAuth 层面的应用认证。([SAP Help Portal][4])

典型场景可能包括：

* 匿名或 guest checkout 的部分操作；
* 用户注册；
* 密码重置相关操作；
* 匿名 consent；
* 地址校验；
* 某些匿名购物车操作；
* session management 相关 endpoint。

具体哪些 API 要求 client token，取决于 SAP Commerce Cloud 版本、extension、security 配置和 OCC endpoint 定义，不能仅凭 URL 中是否出现 `anonymous` 判断。

---

## 五、源码中的实际例子

公开的 Spartacus 源码文档里可以看到几个典型用法。

### 1. 给 guest cart 添加邮箱

`OccCartAdapter.addEmail()` 会显式添加 `USE_CLIENT_TOKEN`：

```typescript
headers = InterceptorUtil.createHeader(
  USE_CLIENT_TOKEN,
  true,
  headers
);
```

随后调用类似：

```http
PUT /users/anonymous/carts/{cartId}/email
```

这表示请求没有普通 customer 的 user token，但需要 storefront 应用身份。([sap.github.io][5])

---

### 2. 删除 anonymous cart

旧版实现中，当 `userId` 是 `anonymous` 时，会标记使用 client token：

```typescript
if (userId === OCC_USER_ID_ANONYMOUS) {
  headers = InterceptorUtil.createHeader(
    USE_CLIENT_TOKEN,
    true,
    headers
  );
}
```

这并不是说 client token 拥有所有购物车，而是该 endpoint 在匿名购物车场景下采用应用级 token，再结合 cart GUID 等参数完成访问控制。([sap.github.io][5])

---

### 3. Guest checkout 下单

旧版 `OccCheckoutAdapter.placeOrder()` 中，如果 `userId` 是 `anonymous`，也会添加 `USE_CLIENT_TOKEN` 标记：

```typescript
if (userId === OCC_USER_ID_ANONYMOUS) {
  headers = InterceptorUtil.createHeader(
    USE_CLIENT_TOKEN,
    true,
    headers
  );
}
```

之后由 interceptor 换成真正的 client token。([sap.github.io][6])

这些属于公开 Spartacus 旧版源码中的例子。Composable Storefront 2211 的包结构和具体 adapter 实现可能已经变化，但它们很好地说明了 `USE_CLIENT_TOKEN` 的设计意图。

---

## 六、Client token 和 user token 的区别

| 对比项        | Client token                              | User token                                 |
| ---------- | ----------------------------------------- | ------------------------------------------ |
| 代表谁        | Storefront 应用                             | 已登录顾客                                      |
| 身份层级       | 应用级身份                                     | 用户级身份                                      |
| 是否说明用户已登录  | 否                                         | 是                                          |
| 是否能读取用户资料  | 通常不能                                      | 取决于用户权限和 endpoint                          |
| 是否能访问任意购物车 | 不能                                        | 也只能访问当前用户被授权的购物车                           |
| 常见用途       | 匿名 API、注册、guest checkout、session endpoint | 用户资料、地址、订单、当前用户购物车                         |
| HTTP 表现    | `Authorization: Bearer <client-token>`    | `Authorization: Bearer <user-token>`       |
| 生命周期       | 通常短期有效                                    | access token 短期有效，并可能配合 refresh/session 机制 |

最重要的区别是：

```text
Client token = 应用是谁
User token   = 用户是谁
```

---

## 七、`useClientTokens` 配置是什么

除了请求级别的 `USE_CLIENT_TOKEN`，Composable Storefront 还有一个全局配置：

```typescript
provideConfig(<AuthConfig>{
  authentication: {
    useClientTokens: false,
  },
});
```

官方文档将其描述为：启用或禁用向原本属于 public 的 API 发送 client token。([SAP Help Portal][4])

它与 `USE_CLIENT_TOKEN` 的关系可以理解为：

```text
USE_CLIENT_TOKEN
    请求级别：
    这个具体请求希望使用 client token

useClientTokens
    全局级别：
    整个应用是否允许这种 client token 机制生效
```

当 `useClientTokens` 被设为 `false` 时，即使 adapter 添加了 `USE_CLIENT_TOKEN` 内部标记，认证层也不会把真正的 client token 发送出去。官方还特别说明，内部的 `USE_CLIENT_TOKEN` header 仍然会被移除，不会因为关闭功能就泄漏到后端。([SAP Help Portal][4])

关闭后，如果后端 endpoint 实际仍然要求 client token，通常会出现：

```text
401 Unauthorized
```

或者类似：

```text
Access is denied
InvalidTokenError
InsufficientAuthenticationException
```

因此，不能仅因为某些商品、CMS 或搜索 API 不需要 client token，就贸然全局关闭它。

---

## 八、它与 guest customer 的关系

这里需要特别澄清一个常见误区：

> Guest customer 不是 client，guest token 也不是 client token。

在 guest checkout 中通常同时存在几种身份信息：

```text
OAuth client identity
    由 client token 表示

anonymous 或 guest OCC user context
    由 URL 中的 userId 表示

cart identity
    由 cart GUID 或 cartId 表示

guest email
    绑定到 guest customer/cart
```

例如：

```http
PUT /occ/v2/electronics-spa/users/anonymous/carts/{cartGuid}/email
Authorization: Bearer <client-token>
```

这里 client token 只证明调用者是合法 storefront。

真正定位和约束购物车的仍然可能包括：

```text
anonymous user
cart GUID
guest customer
cart ownership
endpoint 本身的访问规则
```

因此，获得一个 client token 并不意味着可以枚举或读取所有 guest cart。

同理，一个 real customer 登录后取得 user token，也不能仅凭知道另一个 guest cart 的数据库 `PK`、普通 cart code 或 customer UUID，就读取那个 guest cart。是否允许访问，仍由 OCC endpoint、cart GUID、ownership 和转换或认领流程共同决定。

---

## 九、现代安全模型需要注意什么

传统 Spartacus 示例经常把以下内容配置在前端：

```typescript
clientId: 'mobile_android',
clientSecret: 'secret',
```

这在浏览器 SPA 中并不是真正的秘密，因为打包后的 JavaScript、浏览器 Network 面板和 source map 都可能暴露这些值。

对于较新的 SAP Commerce Cloud JDK 21 和 Composable Storefront OAuth 配置，SAP 要求或推荐使用 public OAuth client，不包含 client secret，并采用 Authorization Code Flow with PKCE 等更适合浏览器应用的方案。SAP 的 221121 更新文档明确提到，新 OAuth client 应将 `public` 属性设为 `true`，并且不能包含 client secret。([SAP Help Portal][7])

但需要区分两件事：

```text
用户登录：
Authorization Code Flow + PKCE

某些应用级或 session endpoint：
可能仍涉及 client token 或 Client Credentials Flow
```

具体组合依赖版本和 authorization server 实现。SAP 官方的 session management 文档仍然提到，一些 endpoint 需要通过 Client Credentials Flow 获得的 access token，并要求 Composable Storefront 使用 public client credentials。([SAP Help Portal][8])

所以，在你的项目里看到 `useClientTokens` 时，不应简单理解为“旧密码登录机制”，它控制的是应用级 token 是否用于指定 OCC 请求，与普通 customer 的 Authorization Code Flow 是两个不同层面。

---

## 十、最终可以这样理解

把 Composable Storefront 想象成一家商场里的自助购物终端：

* **Client token** 相当于终端设备的工作证，证明这台终端属于商场认可的系统。
* **User token** 相当于顾客登录后的会员证，证明当前操作的是哪位顾客。
* **`USE_CLIENT_TOKEN`** 相当于程序在请求上贴的一张内部便签：这次操作需要出示终端工作证。
* **`useClientTokens`** 相当于系统总开关：是否允许终端在这些请求中出示工作证。

因此：

```text
client token 解决应用身份问题，
user token 解决顾客身份问题，
cart GUID 和 ownership 解决购物车归属问题。
```

三者不能互相替代。

[1]: https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/8684f95315e24f52a22f3d9d16ef3af3/ba4c247ef5b9400a8a84ce7e58a3b5b5.html?utm_source=chatgpt.com "Authentication in API Calls"
[2]: https://sap.github.io/spartacus/interceptors/ClientTokenInterceptor.html "storefrontapp documentation"
[3]: https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/cfcf687ce2544bba9799aa6c8314ecd0/6a04941777e242508bdd1dc395a15553.html?utm_source=chatgpt.com "Installing SAP Commerce Cloud 2211 for use with ..."
[4]: https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/7e237cc1245c43219e0a957a2cfa81c2.html?utm_source=chatgpt.com "Composable storefront - Authentication"
[5]: https://sap.github.io/spartacus/injectables/OccCartAdapter.html "storefrontapp documentation"
[6]: https://sap.github.io/spartacus/injectables/OccCheckoutAdapter.html "storefrontapp documentation"
[7]: https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/10a8bc7f635b4e3db6f6bb7880e58a7d/4b769ba91cf248d9b24da0b9f36bc8c8.html?utm_source=chatgpt.com "composable storefront - Update Release 221121.2"
[8]: https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/dc307a52881548e9a15aa6fcba6f7587.html?utm_source=chatgpt.com "Session Management"


SAP Commerce Cloud Composable Storefront 里的 client token，是一个代表“前端应用程序身份”的 OAuth access token。

什么是 client token？

紫薇堂堂主

后端

编程语言

网络与通信

SAP Commerce Cloud中的client token是前端应用的身份凭证，用于认证Composable Storefront应用而非具体用户。它通过OAuth流程获取，用于调用需要应用级认证的API，如匿名购物车操作。与user token不同，client token仅验证应用身份，不涉及用户登录状态。开发时需注意区分client token、OAuth client和USE_CLIENT_TOKEN标记，避免混淆。

代码解释

数据库

OAuth

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SAP Commerce Cloud中的client token是前端应用的身份凭证，用于认证Composable Storefront应用而非具体用户。它通过OAuth流程获取，用于调用需要应用级认证的API，如匿名购物车操作。与user token不同，client token仅验证应用身份，不涉及用户登录状态。开...

什么是 client token？-腾讯云开发者社区-腾讯云

什么是 client token？

什么是 client token？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐