OAuth vs. API-Schlüssel-Authentifizierung

Diese Seite dokumentiert die zwei Authentifizierungsmechanismen, die vom Cryptohopper Market Data MCP unterstützt werden — OAuth 2.0 und Bearer-Token (API-Schlüssel)-Authentifizierung — und erklärt, wann du welche wählen solltest.

Vom MCP unterstützte Authentifizierungsmethoden

Der Cryptohopper Market Data MCP unterstützt zwei Authentifizierungsmechanismen:

1. OAuth 2.0 — ein browserbasierter Autorisierungs-Flow. Kein langlebiges Geheimnis wird in der Client-Konfiguration gespeichert; der MCP-Client übernimmt den Token-Austausch und die Aktualisierung für dich.
2. Bearer-Token (API-Schlüssel) — ein langlebiger Schlüssel, der über die Cryptohopper-Kontooberfläche generiert wird und im Authorization-Header jeder MCP-Anfrage übergeben wird:

Beide Mechanismen sind vollwertig und werden fortlaufend unterstützt. Du kannst jederzeit zwischen ihnen wechseln, indem du deine Client-Konfiguration aktualisierst. Für das vollständige Konto- und Schlüsselmodell siehe Kontoübersicht.

Für client-spezifische Einrichtungsschritte siehe:

• How to set up the Cryptohopper MCP in Claude Code
• How to set up the Cryptohopper MCP in Codex
• How to set up the Cryptohopper MCP in the Claude desktop app

Was OAuth kurz gesagt ist

OAuth 2.0 ist ein delegiertes Autorisierungsprotokoll, bei dem ein Benutzer einer Client-Anwendung begrenzten Zugriff auf sein Konto gewährt, ohne Zugangsdaten zu teilen. Dem Client wird ein Token ausgestellt, das die Berechtigung repräsentiert.

Typische OAuth-Flows umfassen:

• Einen benutzergesteuerten Autorisierungsschritt (der Benutzer klickt "Zulassen" im Browser).
• Eine Weiterleitung mit einem Autorisierungscode.
• Einen Token-Austauschschritt, der ein Zugriffstoken (und optional ein Refresh-Token) erzeugt.

Die Tokens sind Scope-basiert (die Berechtigung legt fest, welche Berechtigungen erteilt werden), zeitlich begrenzt und widerrufbar.

Wann du OAuth mit dem MCP verwenden solltest

OAuth ist im Allgemeinen die bessere Wahl, wenn:

• Du den MCP in einem interaktiven Client (Claude Code, Codex, die Claude-Desktop-App) auf einem Gerät einrichtest, auf dem du eine browserbasierte Anmeldung durchführen kannst.
• Du es vorziehst, kein langlebiges Geheimnis in einer Konfigurationsdatei zu speichern.
• Du kurzlebige Zugriffstokens möchtest, die der Client automatisch aktualisiert.
• Du den Zugriff für ein bestimmtes Gerät oder einen bestimmten Client widerrufen möchtest, ohne andere Integrationen zu beeinträchtigen.

Da OAuth-Tokens kurzlebig sind und automatisch aktualisiert werden, ist OAuth tendenziell die wartungsärmere Option für die tägliche Nutzung auf persönlichen Geräten.

Wann du einen API-Schlüssel mit dem MCP verwenden solltest

Ein Bearer-Token-API-Schlüssel ist im Allgemeinen die bessere Wahl, wenn:

• Die Integration Maschine-zu-Maschine erfolgt: Skripte, CI-Jobs, Agenten oder jede unbeaufsichtigte Automatisierung, bei der eine browserbasierte Anmeldung nicht praktikabel ist.
• Du mehrere Schlüssel zur Segmentierung innerhalb eines einzelnen Kontos ausstellen möchtest (z. B. einen pro Skript oder Umgebung).
• Einfachheit der Einrichtung wichtiger ist als Token-Rotation: Ein einfaches Kopieren und Einfügen des Schlüssels in die Client-Konfiguration ist ausreichend.
• Das Deployment-Ziel einen interaktiven OAuth-Flow nicht einfach durchführen kann (Headless-Server, Container usw.).

Vergleich

Aspekt	API-Schlüssel (Bearer-Token)	OAuth 2.0
Einrichtungskomplexität	Niedrig — Schlüssel in Konfiguration einfügen	Browserbasierter Autorisierungs-Flow
Typischer Akteur	Skripte, CI, Agenten, unbeaufsichtigte Automatisierung	Interaktive Clients auf einem persönlichen Gerät
Token-Lebensdauer	Langlebig bis zum Widerruf	Zugriffstokens kurzlebig, automatisch aktualisiert
Geheimnis in Client-Konfiguration gespeichert	Ja (der Schlüssel)	Nein
Widerruf	Pro Schlüssel, sofort	Pro Berechtigung, sofort
Benutzer im Loop für Ausstellung	Nein — Benutzer generiert Schlüssel direkt	Ja — Autorisierungsschritt erforderlich
Am besten geeignet für	Headless / automatisierte Nutzung	Interaktive / persönliche Nutzung

Beide im selben Konto verwenden

Ein einzelnes Cryptohopper-Konto kann OAuth- und Bearer-Token-Authentifizierung nebeneinander verwenden. Zum Beispiel könntest du OAuth in Claude Code auf deinem Laptop verwenden, während du einen geplanten Agenten in CI ausführst, der sich mit einem langlebigen API-Schlüssel authentifiziert. Die beiden Mechanismen werden unabhängig voneinander ausgestellt, rotiert und widerrufen.

Verwandte Cryptohopper-Produkte

Andere Cryptohopper-Produkte können unterschiedliche Authentifizierungsmechanismen verwenden. Die Cryptohopper REST Trading API verwendet ein eigenes Zugangsdatenschema, das von der MCP-Authentifizierung getrennt ist. Siehe Combine MCP + Cryptohopper Trading API for end-to-end agents, wie die beiden zusammen verwendet werden.

Ein einzelnes Cryptohopper-Konto kann MCP-Zugangsdaten (OAuth-Berechtigungen und/oder Bearer-Token-Schlüssel) neben Trading-API-Zugangsdaten enthalten. Alle werden unabhängig verwaltet.