Sublime Text 不支持 Token Binding，因其是本地编辑器，无 TLS 栈、不处理 HTTP 请求，无法参与 OAuth 2.0 协议流程；Token Binding 需客户端与服务端在 TLS 层协同实现，现已被 IETF 列为 Historic 状态，推荐改用 PKCE、DPoP 或 mTLS 等现代方案。
Sublime Text 本身并不实现 Token Binding 或参与 OAuth 2.0 协议流程，它不是网络客户端或身份认证服务，因此无法直接提供 Token Binding 安全机制来防止 OAuth 2.0 令牌被盗用。Token Binding 是一种 TLS 层的安全协议扩展（RFC 8471），需由浏览器、HTTP 客户端库或后端服务在传输层主动支持，而 Sublime Text 作为本地代码编辑器，不处理 HTTP 请求、不管理 TLS 连接、也不存储或转发访问令牌。
为什么 Sublime Text 不涉及 Token Binding
Token Binding 的核心是将客户端的长期密钥绑定到 TLS 会话，确保 OAuth 令牌只能在原始认证通道中使用。这要求：
- 客户端具备 TLS 栈并启用 TokenBinding 扩展（如 Chrome、Edge 支持，但已逐步弃用）
- 服务器端验证 Token Binding ID 并关联颁发的令牌（如 ID Token 或 Access Token）
- 令牌使用时（如 API 调用）必须复用同一 TLS 通道或携带绑定证明
Sublime Text 没有内置网络栈，即使通过插件（如 RESTer、Advanced REST Client 替代方案）发起 OAuth 请求，其底层仍依赖系统 Python 或 curl，不支持 Token Binding handshake。
真正需要 Token Binding 的场景在哪
Token Binding 主要用于高安全要求的浏览器应用或原生客户端，例如：
覆盖宏观策略、固收研究、行业公司深度分析、量化因子、大类资产配置、可转债、市场情绪、政策快评、行业景气度追踪等34项核心研究能力，证券研究员的全能数字助手。
- 银行/政务类 Web 应用，防范 TLS 中间人窃取 refresh token 后冒充用户
- 企业 SSO 集成中，防止授权码或令牌被截获重放
- 某些 FIDO2 + OAuth 组合认证流程中增强绑定语义
注意：主流浏览器已基本停止支持 Token Binding（Chrome 72+ 移除，Firefox 未实现），IETF 也已将其转为 Historic 状态（RFC 9116）。当前更推荐采用 PKCE、DPoP（Demonstrating Proof-of-Possession）、MTLS 或短期令牌策略替代。
如果你在 Sublime 中处理 OAuth 令牌，该怎么做
虽然无法启用 Token Binding，但可降低令牌泄露风险：
- 绝不硬编码令牌：避免将 client_secret、access_token 写入 .py/.js 文件提交到 Git
- 用环境变量或密钥管理工具：通过 Sublime 插件（如 Environment Settings）加载 os.environ，或调用 1Password/Bitwarden CLI 注入
- 限制令牌作用域与有效期：申请最小权限 scope，设置短 exp（如 5–15 分钟），配合 refresh token 轮换
- 使用 DPoP（推荐替代方案）：若后端支持，客户端生成 DPoP key 并在每个请求头带 DPoP JWT，Sublime 配合 Python 脚本可实现签名逻辑
基本上就这些。Token Binding 是个已被边缘化的机制，与其纠结 Sublime 是否支持，不如关注现代替代方案和开发习惯——比如用 VS Code + REST Client + DPoP 插件，或在服务端强制 MTLS + OAuth Introspection。安全不在编辑器，而在链路设计和运行时控制。
