Access Token & Access Token Secret
Access Token & Access Token Secret
This is the third and final step of the initial OAuth 1.0a handshake with the Interactive Brokers API. Having obtained an authorized Request Token (rToken) and an oauth_verifier (vToken) from the user consent step, the application now exchanges these credentials for a permanent Access Token and Access Token Secret.
Structurally, this step closely mirrors the Request Token step (same signing method, same header construction pattern), with two key differences: the inclusion of oauth_token and oauth_verifier in the parameter set, and a response payload containing an additional secret component.
Note on terminology: In the IBKR OAuth model, the oauth_token_secret returned here is not used directly as a signing key for subsequent requests, unlike in standard OAuth 1.0a. IBKR requires a further Diffie-Hellman-based derivation to produce the Live Session Token, which is used for signing all subsequent authenticated API calls. This should be clarified in the docs for this step to prevent integrators from misusing aTokenSecret directly. This distinction is critical and should be flagged loudly for downstream implementers — treating aTokenSecret as an HMAC signing key (as in canonical OAuth 1.0a) will produce silent authentication failures against IBKR endpoints.
Construct the Endpoint URL
The Access Token endpoint follows the same host as the Request Token endpoint, differing only in path. As with the prior step, this is invoked via POST.
Assemble OAuth Parameters
This parameter set extends the Request Token step’s set with two additional required fields:
Nonce/timestamp warning: A new nonce and timestamp are generated for this request, as required by the spec. Do not reuse values from the Request Token step — each signed request must carry its own unique nonce/timestamp pair, even within the same overall authorization flow.
Build the Signature Base String
This follows the identical pattern established in the Request Token step:
- Parameters sorted alphabetically by key.
- Joined into a raw
key=value&key=value...string. - URL encoded via
quote_plus(), parameter string encoded viaquote(). - Combined into the
METHOD&URL&PARAMSbase string format.
Sign the Base String with RSA-SHA256
Identical process to the Request Token step: SHA-256 digest of the base string, signed with PKCS#1 v1.5 padding using the application’s RSA private key, then Base64-encoded for transport.
Finalize and Encode the Signature
As before, the signature is percent-encoded prior to header insertion, and realm is appended for the Authorization header only — it remains excluded from the signature base string itself.
Construct the Authorization Header
Identical construction pattern to the Request Token step. See prior documentation regarding the User-Agent hardcoding caveat — the same recommendation to parameterize this value for production applies here.
Execute the Request
As with the Request Token call, no request body is sent — all authentication material is carried in the Authorization header.
Parse the Access Token and Secret
Two credentials are returned on success:
🔒 Critical security handling:
aTokenSecretmust be treated as highly sensitive material. It should:
- Never be logged, including in debug output (
pretty_request_responseshould redact this field if response bodies are logged at any verbosity).- Never be persisted in plaintext at rest — encrypt if storage is required.
- Be held only in memory for the duration needed to complete the Live Session Token derivation, if your architecture allows discarding it afterward.

