Authentication

Fortkey distinguishes two kinds of users, with a different authentication model for each.

Human traders

Human users authenticate through OIDC with your organization's own identity provider. Only pre-approved, company-configured email addresses can access the platform. Fortkey never stores passwords, and sessions inherit whatever MFA and conditional access rules your IdP enforces.

Bot traders

Bots authenticate with a challenge-response protocol (CRA) based on asymmetric cryptography: the bot proves ownership of its registered private key, and no static API secret ever crosses the wire. There is no long-lived API key to leak, rotate, or scrape from a config file.

The Rust SDK does all of this automatically. For teams integrating without the SDK, the endpoint flow is three steps:

1. Request a challenge: POST /auth/login with your bot user id and auth_method: "cra". The response contains a one-time challenge and a deadline for completing it.
2. Sign the challenge: sign it with the bot's private key, using one of the supported hash algorithms.
3. Exchange for a session token: POST /auth/cra with the challenge and your signature. The response contains a session token, a refresh token, and the expiry. Use the session token on subsequent API calls.

Session controls

Admins can see all active sessions (human and bot) in the console and can suspend any session they do not trust, forcing a logout. Session invalidation ends the current session but does not block future logins; to fully lock a user out, revoke their access or delete the user. Logins can additionally be restricted to specific IP addresses or CIDR ranges.