Authentication

Quick Answer

Authentication proves to the broker that a request is really yours before it acts on your account. It typically combines a permanent API key, a login that mints a short-lived access token, and a TOTP second factor. Because tokens expire — often daily on Indian broker APIs — an automated system must refresh them and never hard-code secrets.

Definition: Authentication

Authentication is the process of verifying that a request genuinely comes from the account holder, combining a registered key, a short-lived session token and often a one-time code.

Key takeaways: Authentication

• Authentication proves a request is really you and is allowed to act on the account
• Separate long-lived API keys (identity) from short-lived access tokens (session)
• OAuth-style flows and TOTP keep the password on the broker and add a second factor — but the seed is a secret too
• Never hardcode secrets; use env vars or a secrets manager, apply least privilege, and be ready to revoke

Authentication at a glance

Authentication in simple words

Authentication is the API's way of checking you are who you claim to be before it lets your code touch real money. Instead of a username typed into a screen, your program presents credentials — a key and a token — with every request. Because these credentials can place orders, protecting them is as important as protecting your bank password.

What Authentication is for

Authentication exists so that only you can drive your account through the API; without it, anyone who guessed your endpoint could trade on your behalf, so it is the security foundation of everything else.

Authentication — professional explanation

API keys: identifying the application

An API key (often a key plus a secret) identifies your application to the broker. The public key names you; the secret proves it is really you and must never be exposed. Keys are relatively long-lived and are usually issued once when you register an app. Because a leaked secret lets an attacker impersonate your application, it is treated like a password: never committed to source code, never logged, never sent to the browser. The key identifies; it does not, by itself, grant a live trading session — that usually requires a further login step producing a short-lived token.

Access tokens and sessions

Most broker APIs separate long-lived identity (the API key) from a short-lived access token that authorises the current trading session. You obtain the token by completing a login flow, and then attach it to every request, commonly in an Authorization header. Access tokens typically expire — often daily, aligned with the trading day — which limits the damage if one leaks and forces a fresh, deliberate login. Some systems also issue a refresh token that can mint new access tokens without a full re-login. Your client must detect an expired token (a 401) and re-authenticate cleanly rather than looping on failed requests.

OAuth-style login flows

Rather than handing your broker password to a third-party app, modern broker APIs use an OAuth-style redirect flow. Your app sends the user to the broker's own login page; the user authenticates there (password plus second factor); the broker redirects back with a short-lived request token; and your app exchanges that request token, together with the API secret, for an access token. The point of this dance is that the password is entered only on the broker's domain and never touches the app, and the resulting token is scoped and expirable. Understanding the exact sequence — request token, exchange, access token — is essential because each broker's endpoints and field names differ.

TOTP and the second factor

Two-factor authentication adds a time-based one-time password (TOTP) — the rotating six-digit code from an authenticator app — on top of the password. TOTP is derived from a shared secret seed and the current time using a standard algorithm, so the same seed generates the same code on your device and the broker's server without any network call. For automated login, some systems generate the TOTP programmatically from the seed. This is powerful but dangerous: the TOTP seed is itself a high-value secret, and storing it insecurely defeats the entire purpose of the second factor. If you automate TOTP, the seed deserves the same protection as the API secret.

Storing secrets safely — never hardcode

The single most important rule is that secrets never live in source code. Hardcoding an API secret or token into a Python file means it travels into version control, and a public or later-shared repository leaks it permanently — attackers actively scan public code for exactly these strings. Instead, secrets belong in environment variables, a dedicated secrets manager, an encrypted vault, or a config file that is excluded from version control (via a gitignore entry) and readable only by the running user. On shared or cloud machines, prefer a managed secrets service over plaintext files. Rotating keys periodically and immediately on any suspected exposure is standard hygiene.

Least privilege, scope and revocation

Good authentication design also limits what a credential can do and for how long. Where a broker offers scoped keys or read-only tokens, use the narrowest scope a component needs — a monitoring dashboard should not hold order-placement rights. Keep the ability to revoke a key instantly, and know the procedure before you need it, because the response to a suspected leak is to revoke first and investigate second. Combine short token lifetimes, least privilege and fast revocation and a leaked credential becomes a contained incident rather than a drained account.

Worked example: Authentication

API key vs access token

Advantages of Authentication

• Ensures only authorised code can read your account and place orders
• Short-lived tokens limit the blast radius if a credential leaks
• OAuth-style flows keep your broker password on the broker's domain, never in the app
• Scoped and revocable credentials let you grant least privilege and shut off access fast

Limitations of Authentication

• Automating TOTP means storing the seed, a high-value secret that can undermine 2FA if exposed
• Daily token expiry forces a re-authentication routine that itself must be reliable
• A single leaked secret can drain or disrupt the account before you notice
• Login flows and field names differ per broker and change between API versions
• Managing secrets correctly across dev, test and production adds real operational overhead

How professionals treat Authentication

Professional setups inject secrets at runtime from a managed vault or environment, never from the codebase, and enforce that no credential is ever logged. They separate identity (long-lived key) from session (short-lived token), automate a clean re-authentication path on 401, and apply least privilege so each component holds only the scope it needs. Key rotation is scheduled, revocation procedures are rehearsed, and any suspected leak triggers an immediate revoke-first response.

Common misconceptions about Authentication

Common mistakes with Authentication

• Hardcoding API keys, secrets or tokens into source code that reaches version control
• Logging tokens or secrets, or printing them to the console during debugging
• Storing the TOTP seed in plaintext alongside the code, defeating two-factor security
• Retrying requests on a 401 instead of re-authenticating to obtain a fresh token
• Committing a config file with real credentials because it was not added to gitignore
• Granting a monitoring or research component full order-placement privileges it does not need

Authentication: frequently asked questions

Voice search: how people ask about Authentication

Natural-language questions people ask about Authentication.

Sources & references

• SEBI, “Safer participation of retail investors in Algorithmic Trading”, Circular, 4 February 2025 (implementation extended to 1 October 2025)
• Ernest P. Chan, “Quantitative Trading: How to Build Your Own Algorithmic Trading Business”, 2nd ed., Wiley, 2021