Skip to Content

Rate Limiting

Auris setzt Rate Limits auf allen API-Endpunkten durch, um die Plattform vor Missbrauch zu schützen, Credential-Stuffing-Angriffe zu verhindern und eine faire Ressourcenzuteilung zwischen Tenants sicherzustellen.

Rate-Limiting-Stufen

Auris wendet je nach Sensitivität und Ressourcenkosten des Endpunkts unterschiedliche Rate Limits an. Es gibt vier Stufen:

Auth-Stufe (Streng)

Gilt für Authentifizierungsendpunkte, die Anmeldedaten verarbeiten:

  • POST /api/auth/login (E-Mail/Passwort-Login)
  • POST /api/auth/signup (Benutzerregistrierung)
  • POST /api/auth/token (Token-Exchange und -Refresh)
  • POST /api/auth/magic-link (Magic-Link-Initiierung)
  • POST /api/oauth/authenticate (Gehostetes Login-Formular)

Standard-Limits: Niedrige Anfragen pro Minute pro IP, mit zusätzlichen Pro-Konto-Limits auf Login-Endpunkten.

Sensible Stufe (Moderat)

Gilt für sicherheitskritische Operationen, die nicht häufig aufgerufen werden sollten:

  • POST /api/user/2fa/* (2FA-Registrierung und -Verifizierung)
  • POST /api/auth/forgot-password (Passwort-Reset-Initiierung)
  • POST /api/auth/change-password (Passwortänderung)

Standard-Limits: Moderate Anfragen pro Minute pro IP und pro Benutzer.

API-Stufe (Standard)

Gilt für allgemeine authentifizierte API-Endpunkte:

  • GET/POST/PATCH/DELETE /api/users/*
  • GET/POST/PATCH/DELETE /api/roles/*
  • GET/POST/PATCH/DELETE /api/organizations/*
  • Alle anderen authentifizierten CRUD-Endpunkte

Öffentliche Stufe (Entspannt)

Gilt für offene Endpunkte, die keine Authentifizierung erfordern:

  • GET /.well-known/openid-configuration
  • GET /.well-known/jwks.json
  • POST /api/scim/v2/* (SCIM-Provisionierung mit Bearer-Token)

Rate-Limit-Header lesen

Jede Antwort von einem rate-limitierten Endpunkt enthält Standard-Header:

HeaderTypBeschreibung
X-RateLimit-LimitIntegerMaximale Anzahl erlaubter Anfragen im aktuellen Fenster
X-RateLimit-RemainingIntegerVerbleibende Anfragen vor dem Erreichen des Limits
X-RateLimit-ResetUnix-ZeitstempelWann das aktuelle Fenster zurückgesetzt wird
Retry-AfterIntegerSekunden bis zum Wiederversuch (nur bei 429-Antworten)

Beispielantwort bei Rate Limiting:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1737014400
Retry-After: 47
Content-Type: application/json
 
{
  "ok": false,
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Zu viele Anfragen. Bitte versuche es in 47 Sekunden erneut."
  }
}

429-Antworten behandeln

Grundlegender Wiederholungsversuch mit Backoff

async function callAurisApi(
  url: string,
  options: RequestInit,
  maxRetries = 3
): Promise<Response> {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options)
 
    if (response.status !== 429) {
      return response
    }
 
    const retryAfter = parseInt(response.headers.get('Retry-After') || '60', 10)
 
    if (attempt === maxRetries) {
      throw new Error(`Rate limited nach ${maxRetries} Versuchen. Wiederholung in ${retryAfter}s.`)
    }
 
    await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000))
  }
 
  throw new Error('Unerwarteter Fehler: Wiederholungs-Schleife überschritten')
}

Exponentieller Backoff mit Jitter

Für Produktionssysteme mit hohem Traffic verwende exponentiellen Backoff mit Jitter, um das Thundering-Herd-Problem zu vermeiden:

async function callWithExponentialBackoff(
  url: string,
  options: RequestInit,
  maxRetries = 5
): Promise<Response> {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options)
 
    if (response.status !== 429) {
      return response
    }
 
    if (attempt === maxRetries) {
      throw new Error('Rate Limit überschritten: Maximale Wiederholungen erreicht')
    }
 
    const retryAfter = response.headers.get('Retry-After')
    let delay: number
 
    if (retryAfter) {
      delay = parseInt(retryAfter, 10) * 1000
    } else {
      // Exponentieller Backoff: 1s, 2s, 4s, 8s, 16s
      const baseDelay = Math.pow(2, attempt) * 1000
      const jitter = Math.random() * baseDelay * 0.5
      delay = baseDelay + jitter
    }
 
    await new Promise((resolve) => setTimeout(resolve, delay))
  }
 
  throw new Error('Unerwarteter Fehler: Wiederholungs-Schleife überschritten')
}

Pro-Konto-Limits auf Auth-Endpunkten

Zusätzlich zu IP-basierten Rate Limits setzt Auris Pro-Konto-Limits durch, die in Verbindung mit dem Brute-Force-Schutzsystem arbeiten:

SchwellenwertAktion
Aufeinanderfolgende fehlgeschlagene LoginsZähler wird erhöht
Zähler erreicht Sperr-Schwellenwert (Standard: 5)Konto für eskalierende Dauer gesperrt
1. Sperre5 Minuten
2. Sperre30 Minuten
3. Sperre24 Stunden

Pro-Konto-Sperre ist von IP-basiertem Rate Limiting getrennt. Ein verteilter Angriff von mehreren IPs gegen dasselbe Konto löst trotzdem die Sperre aus.

SDK-automatisches Wiederholungsverhalten

Das @auris/js-SDK enthält integriertes Rate-Limit-Handling für Token-Operationen:

  • Token-Refresh: Wenn eine Refresh-Token-Anfrage eine 429 erhält, wartet das SDK die Retry-After-Dauer und versucht es einmal automatisch erneut
  • API-Aufrufe über den Management-Client: Der Management-Client wiederholt nicht automatisch

Best Practices

Retry-After immer respektieren. Wenn du eine 429 erhältst, sagt der Retry-After-Header genau, wie lange du warten sollst.

Exponentiellen Backoff mit Jitter verwenden. Für Bulk-Operationen oder High-Throughput-Szenarien.

Circuit Breaker für kritische Pfade implementieren. Wenn deine Anwendung von Auris-API-Aufrufen im Anfragepfad abhängt (z. B. Berechtigungsprüfungen), verwende einen Circuit Breaker, um elegant zu scheitern.

Antworten cachen, wo möglich. Reduziere API-Aufrufe durch Caching von Benutzerprofilen, Rollenlisten und Berechtigungsprüfungen.

Rate-Limit-Header in der Produktion überwachen. Protokolliere den X-RateLimit-Remaining-Wert und richte Alerts ein, wenn er unter einen Schwellenwert fällt.

Verwandte Leitfäden

Architektur