OAuth 1.0a 总览

OAuth 1.0a 用于让应用在不保存用户密码的情况下访问 IBKR Web API。它比 Client Portal Gateway 复杂，通常适合机构、第三方应用或正式 Web 服务。

个人桌面开发优先使用 Client Portal Gateway；只有需要把服务部署到服务器、给多用户使用或做正式授权接入时，才需要深入 OAuth。

官方参考：Web API Documentation

OAuth 解决什么问题

问题	OAuth 的作用
不能保存用户密码	用户在 IBKR 授权页完成授权，应用只拿令牌。
需要服务器调用 Web API	服务器用签名请求访问接口。
多用户接入	每个用户有自己的授权和 token。
权限可撤销	用户或 IBKR 可以撤销应用授权。

两种常见模式

模式	中文说明	适合场景
First-party OAuth	一方 OAuth，应用和账户主体更接近	自用系统、机构自有系统。
Third-party OAuth	三方 OAuth，用户授权给外部应用	面向客户的第三方服务。

典型流程

申请并配置 OAuth 应用
    -> 获取 Request Token
    -> 用户授权
    -> 换取 Access Token
    -> 生成 Live Session Token
    -> 使用签名请求调用 Web API

需要准备的资料

资料	说明
Consumer Key	IBKR 分配给应用的标识。
签名密钥	用于 OAuth 1.0a 请求签名。
回调地址	用户授权后跳转回应用的地址。
Access Token	用户授权后获得的访问令牌。
Token Secret	与 Access Token 配套的签名密钥。

这些都属于敏感信息。不要写进前端代码、公开仓库、页面展示或日志。

和 Gateway 的区别

对比项	Client Portal Gateway	OAuth
启动方式	运行 Java Gateway	服务器应用签名请求
登录方式	浏览器登录 Gateway	IBKR 授权流程
适合阶段	桌面开发、单用户调试	正式服务、多用户接入
复杂度	较低	较高

示例边界

OAuth 示例只说明流程、字段和签名结构。真实接入还需要 OAuth 应用审批资料、consumer key、签名密钥、回调配置和用户授权。开发时要把“能生成签名”和“IBKR 接受并返回业务数据”分开验证。