WSO2 Identity Server与API Manager：多访问令牌请求头最佳实践

你当前通过Authorization头存放IS SCIM的Bearer令牌，用自定义Auth-apim头传递APIM令牌的方案，完全可以正常工作——WSO2的组件对自定义请求头没有强制限制，只要你的后端服务能正确解析两个头里的令牌就行。不过还有几种更规范的方案可以参考：

可选优化方案 #

1. 复用Authorization头，用令牌类型区分 #

WSO2支持自定义令牌类型，你可以给APIM令牌指定专属类型（比如APIMBearer），然后在同一个Authorization头里传递两个令牌，格式如下：

Authorization: Bearer <IS_SCIM_TOKEN>, APIMBearer <APIM_TOKEN>

注意：这种格式需要你的后端中间层自行拆分并识别不同类型的令牌，WSO2网关和IS本身不会自动处理多令牌格式，得自己写解析逻辑。

2. 把SCIM API接入APIM，统一令牌管理 #

这是更推荐的长期方案：

• 将IS的SCIM API发布到APIM中作为代理API，指向IS的SCIM端点
• 配置APIM网关与IS的信任关系，让网关能自动获取访问SCIM API的令牌（通过令牌交换或密钥管理功能）
• 前端只需要携带APIM的令牌调用代理后的API，无需同时处理两个令牌，大幅简化前端逻辑

3. 用Cookie存储其中一个令牌 #

如果APIM令牌仅用于后端服务调用，可以把它存在HttpOnly属性的Cookie中，前端只需要在请求头里携带IS的SCIM令牌。这种方式能减少前端显式传递的令牌数量，还能降低XSS窃取令牌的风险，但要注意配置正确的Cookie域和路径，确保后端能正常读取。

总结 #

如果你的业务场景简单，当前的自定义Header方案完全够用；如果追求更规范、易维护的流程，推荐把SCIM API接入APIM，实现单令牌统一管理。

内容的提问来源于stack exchange，提问作者wikipep