Authentication

Quick answer: Authentication is how a broker API verifies that a request genuinely comes from you and is authorised to act on your account, typically through API keys, short-lived access tokens, an OAuth-style login flow and often a TOTP second factor.

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.

Purpose

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.

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.

API key vs access token

Practical example

Advantages

• 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

• 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

Common mistakes

• 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

Professional usage

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.

Frequently asked questions

Voice search & related questions

Natural-language questions people ask about Authentication.

Sources & references

Last reviewed 11 July 2026. Educational content only — not investment advice. Markets and rules change; verify current conventions with SEBI, NSE/BSE and your broker.