Retrieve Live Session Token Signature
This step is the most cryptographically involved stage of the IBKR OAuth flow. It combines a Diffie-Hellman (DH) key exchange with an OAuth 1.0a-style signed request to obtain the materials necessary to compute the Live Session Token (LST) — the key ultimately used to sign all subsequent authenticated IBKR API calls (replacing the Access Token Secret from the previous step).
This function does not compute the final Live Session Token itself. It performs the request/response exchange and returns the raw components (dh_random, prepend, dh_response, lst_signature, lst_expiration) required for that computation, which is documented in the next step.
Generate the Diffie-Hellman Challenge
This computes the client’s half of a standard Diffie-Hellman key exchange:
Critical secret material:
dh_randomis returned by this function and must be retained (in memory, or securely if persisted) — it is required as an input to compute the final Live Session Token from IBKR’sdh_responsein the next step.
Decrypt the Access Token Secret to Produce the Base String Prepend
This is a step unique to the IBKR OAuth model and has no equivalent in the prior Request Token / Access Token steps.
Process:
- Base64-decode
access_token_secret(received as a string from the Access Token response) into raw ciphertext bytes. - Decrypt using PKCS#1 v1.5 encryption padding (note: encryption/decryption padding, distinct from the PKCS#1 v1.5 signature padding used elsewhere) with the private
encryption_key. - Convert the resulting decrypted bytes to a hex string — this becomes the
prepend. - The
prependis placed at the very beginning of what will become the signature base string — before the standardMETHOD&URL&PARAMSstructure.
Construct the Signature Base String
Parameter set for this request:
This is the most important structural distinction in this entire flow: the signature base string is prefixed with the hex-encoded decrypted secret (prepend) before the standard METHOD&URL&PARAMS string is appended. This prepend is not URL-encoded and is not separated from the rest of the base string by an & — it is direct string concatenation.
Sign the Base String with RSA-SHA256
Process:
- Encode the base string to UTF-8 bytes.
- Compute the SHA-256 digest.
- Sign the digest using PKCS#1 v1.5 padding with your RSA private key (
signature_key— aCrypto.PublicKey.RSAkey object). - Base64-encode the raw signature bytes into a transmittable string.
Construct the Authorization Header
The header follows the standard OAuth scheme format:
Parameters are sorted alphabetically (matching convention, though not strictly required at this stage since the signature was already computed).
User-Agent Note: IBKR’s API gateway may enforce User-Agent validation. Update this value to reflect your actual runtime/client rather than hardcoding "python/3.11" for production deployments — pin it to your actual interpreter/environment version, or set a custom identifying string as permitted by IBKR’s integration guidelines.
Parse the Response
Response fields:
The next stage in computing the Live Session Token will require the following details from the Live Session Token Signature request:
dh_random— client’s private DH exponent (Step 1)prepend— decrypted secret hex string (Step 2)dh_response— server’s public DH value (this step)lst_signature— for verifying the computed LSTlst_expiration— for session lifecycle management

