OAuth 1.0aLive Session Token

Validate the Live Session Token

View as MarkdownOpen in Claude

This step closes the loop on the Live Session Token derivation process, addressing the critical gap flagged in the prior documentation: verifying that the locally computed LST matches IBKR’s own computation before it is trusted and put into use for signing future API requests.

This is a mandatory security checkpoint, not an optional integrity check. Only upon successful verification here does computed_lst become the authoritative live_session_token used for all subsequent authenticated API calls.

1

Prerequisites

InputSourceDescription
computed_lstPrevious derivation stepThe locally computed, Base64-encoded Live Session Token
consumer_keyApplication credentialsSame consumer key used throughout the OAuth flow
lst_signatureLST request responseThe signature IBKR returned alongside dh_response in the Live Session Token request step
2

Compute the Verification Hash

1hex_str_hmac_hash_lst = HMAC.new(
2    key=base64.b64decode(computed_lst),
3    msg=consumer_key.encode("utf-8"),
4    digestmod=SHA1,
5).hexdigest()

This computes a second, independent HMAC-SHA1 operation — distinct in purpose from the HMAC used to derive the LST in the prior step:

verification_hash=HMAC-SHA1(key=base64_decode(computed_lst), message=consumer_key)\text{verification\_hash} = \text{HMAC-SHA1}(\text{key}=\text{base64\_decode}(\text{computed\_lst}),\ \text{message}=\text{consumer\_key})

ParameterValueNote
keyThe raw bytes of computed_lst, obtained by Base64-decoding the string produced in the derivation stepNote the directional inversion vs. the previous step: there, K was encoded into bytes; here, the LST string is decoded back into bytes to serve as an HMAC key
msgThe application’s consumer_key, UTF-8 encodedThis is the same value used as oauth_consumer_key throughout the entire OAuth flow
digestmodSHA1Consistent with the SHA-1 usage established in the derivation step — not SHA-256
Output format.hexdigest() — a hex string, not raw bytes or Base64Differs from the derivation step’s output encoding (Base64) — this must match the format IBKR uses for lst_signature for the comparison in Step 2 to be valid

⚠️ Purpose distinction — do not confuse these two HMAC operations:

  • Derivation step (previous document): HMAC keyed by the DH shared secret (K), over the decrypted access token secret (prepend_bytes) → produces the LST itself.
  • This step: HMAC keyed by the computed LST, over the consumer key → produces a verification value to confirm the LST derivation is correct.
3

Compare Against the Server-Provided Signature

1if hex_str_hmac_hash_lst == lst_signature:
2    live_session_token = computed_lst

If the locally computed hex digest matches lst_signature (returned by IBKR in the Live Session Token request response), the derivation is confirmed correct, and computed_lst is promoted to live_session_token — the value that should be used going forward for signing authenticated API requests.

🔒 This comparison is the sole gate on trusting the derived LST. A match cryptographically confirms that:

  1. The Diffie-Hellman shared secret K was computed correctly by both parties.
  2. The Access Token Secret was correctly decrypted (prepend/prepend_bytes).
  3. All byte-encoding edge cases (odd-length hex, sign-bit padding) were handled identically to IBKR’s server-side implementation.

A mismatch means any of the above may have failed, and computed_lst must not be used for further requests.

4

5

6