Authentifizierung und Sicherheit

API v2: Schlüssel, IP-Whitelist, HMAC

Zugriffsmodell. Alle Anfragen an die API v2 werden im Namen eines Schlüsselpaares
publicKey/secretKey
ausgeführt. Die Schlüssel werden im persönlichen Konto oder über v1 (/api/v1/users/generate-api-key) erstellt.

IP-Einschränkung. Geben Sie beim Erstellen eines Schlüssels vertrauenswürdige Adressen in
whiteListIp
an. Anfragen außerhalb dieser Liste werden abgelehnt.

Signatur jeder Anfrage. In den Headern müssen enthalten sein:

X-Api-Public-Key — Ihr publicKey

X-Api-Timestamp — Zeitstempel-Zeichenkette (z. B. Epoch-Millisekunden)

X-Api-Signature — HMAC-SHA256-Signatur in Base64

Signaturformel

StrToSign = timestamp + body + publicKey
Signature = Base64( HMAC_SHA256(StrToSign, secretKey) )

Dabei ist body — JSON ohne überflüssige Leerzeichen (verwenden Sie kompakte Serialisierung).

Beispiel (curl)

curl -X POST "https://quickex.io/api/v2/instruments/public/validate-address" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-Api-Public-Key: {PUBLIC_KEY}" \
  -H "X-Api-Timestamp: {TIMESTAMP_MS}" \
  -H "X-Api-Signature: {HMAC_BASE64}" \
  -d '{"currencyTitle":"USDT","networkTitle":"TRC20","address":"..."}'

API v1: JWT/Session

Zwei Zugangswege. Manuelle Verifizierung über den Support ist möglich — dauerhaften Zugang beantragen (Projekt, Volumina, Whitelist-IP, Partner-ID angeben).

JWT-Authentifizierung. Erhalten Sie Tokens über
POST /api/v1/users/local/authenticate (Felder:
email, password, browserFingerprint).
In der Antwort setzt der Server Cookies:
session_id, access_token, refresh_token.

Beispiel einer Anfrage (JSON-Body)

{
  "email": "user@example.com",
  "password": "yourpassword",
  "browserFingerprint": "unique-browser-id"
}

Tokens/Cookies werden für Aufrufe geschützter v1-Methoden und zur Generierung von API-v2-Schlüsseln über
/api/v1/users/generate-api-key verwendet.

Empfehlungen zur Aufbewahrung von Schlüsseln und Tokens

Nicht im Code/Repository speichern. Verwenden Sie Umgebungsvariablen oder Secret-Manager (Vault, AWS Secrets Manager, GCP Secret Manager usw.).

Umgebungen trennen. Separate Schlüssel für Dev/Stage/Prod. Für Dev — eingeschränkte
whiteListIp und reduzierte Berechtigungen.

Angriffsfläche minimieren. Führen Sie v2-Anfragen nur vom Backend aus, generieren Sie Schlüssel und HMAC niemals im Frontend.

Regelmäßige Rotation. Schlüssel regelmäßig neu ausstellen, ungenutzte löschen
(/api/v1/users/list-api-key, /api/v1/users/delete-api-key).

Logging ohne Geheimnisse. Loggen Sie keine
secretKey, Tokens oder vollständigen Autorisierungs-Header; protokollieren Sie nur Hashes/IDs und Antwortcodes.

Überall TLS. Verwenden Sie ausschließlich
https. Leiten Sie nicht auf unsichere Schemata um.

Sichere Cookies. Für v1 die Flags
HttpOnly, Secure verwenden; Tokens nur in geschützten Sitzungsspeichern ablegen.

Fehlerbehandlung und erneute Versuche. Bei 429/5xx — exponentielles Backoff. Prüfen Sie den Antwort-Body und die Gültigkeit der Pflichtparameter.

Prinzip der geringsten Rechte. Geben Sie Schlüssel und Tokens Diensten nur dort, wo sie benötigt werden; keine unnötige Weitergabe zwischen Teams/Microservices.