Die Claude API unterstützt zwei Möglichkeiten, Anfragen zu authentifizieren:
| Methode | Anmeldedaten | Am besten geeignet für |
|---|---|---|
| API-Key | Statisches sk-ant-api...-Secret im x-api-key-Header | Lokale Entwicklung, Prototyping, Skripte und Single-Tenant-Server, bei denen du die Speicherung der Secrets kontrollierst |
| Workload Identity Federation | Kurzlebiges Bearer-Token, das gegen das Identity-Token deines Identity-Providers eingetauscht wird | Produktions-Workloads auf Cloud-Plattformen (AWS, Google Cloud, Azure), CI/CD-Pipelines und Kubernetes, wo du statische Secrets eliminieren möchtest |
Beide Methoden gewähren denselben Zugriff auf die Claude API-Endpunkte. Wähle API-Keys, um schnell loszulegen, und wechsle zu Workload Identity Federation, wenn dein Workload bereits über eine von der Plattform ausgestellte Identität verfügt, die du föderieren kannst.
API-Keys sind statische Secrets, die du in der Claude Console generierst und bei jeder Anfrage übergibst.
x-api-key-Header bei direkten HTTP-Anfragen oder setze die Umgebungsvariable ANTHROPIC_API_KEY, und die Client-SDKs übernehmen sie automatisch.POST /v1/messages
x-api-key: YOUR_API_KEY
anthropic-version: 2023-06-01
content-type: application/jsonSpeichere API-Keys in einem Secrets-Manager, rotiere sie regelmäßig und widerrufe jeden Key, bei dem du vermutest, dass er geleakt wurde. Du kannst beim Erstellen eines Keys auch eine Ablaufzeit festlegen, um zu begrenzen, wie lange ein geleaktes Anmeldedatum nutzbar bleibt.
client = Anthropic(api_key="my-anthropic-api-key")
# oder, wenn ANTHROPIC_API_KEY in der Umgebung gesetzt ist:
client = Anthropic()Wenn du einen API-Key über die API-Keys-Seite in der Claude Console erstellst, wählst du eine Ablaufzeit: eine Voreinstellung (3 Stunden, 1 Tag, 7 Tage oder 30 Tage), eine benutzerdefinierte Dauer oder Never für Keys, die du in einem Secrets-Manager speicherst und selbst rotierst. Wenn deine Organisation eine Richtlinie für die maximale Ablaufzeit hat, begrenzt die Console Voreinstellungen und benutzerdefinierte Dauern auf das Richtlinienmaximum, und Never ist nicht verfügbar. Bestehende Keys behalten ihr aktuelles Verhalten; die Ablaufzeit wird bei der Erstellung festgelegt und kann danach nicht mehr geändert werden. Dieselbe Ablaufzeit-Auswahl gilt, wenn du einen Admin-API-Key erstellst in der Claude Console.
Anthropic sendet dem Ersteller des Keys eine E-Mail, wenn der Ablauf näher rückt: 7 Tage vor Ablauf für Keys, die mit einer Lebensdauer von mindestens 14 Tagen erstellt wurden, und 1 Tag vorher für Keys mit einer Lebensdauer von mindestens 7 Tagen. Keys mit kürzerer Lebensdauer laufen ohne Warn-E-Mail ab.
Nachdem ein Key abgelaufen ist, geben damit gestellte Anfragen einen 401 authentication_error zurück. Erstelle einen neuen Key, um den Zugriff wiederherzustellen; abgelaufene Keys können nicht reaktiviert werden.
Die API-Keys-Tabelle in der Console zeigt die Ablaufzeit jedes Keys an, und die Admin API meldet den expires_at-Zeitstempel jedes Keys auf den Endpunkten List API Keys und Retrieve API Key, sodass du Keys prüfen und rotieren kannst, bevor sie ablaufen. Das Feld ist null für Keys ohne Ablaufzeit.
Eine Ablaufzeit begrenzt die Lebensdauer eines geleakten Anmeldedatums, ist aber kein Ersatz für Secret-Hygiene. Speichere Keys unabhängig von der Ablaufzeit in einem Secrets-Manager und widerrufe jeden Key, bei dem du vermutest, dass er geleakt wurde.
„Workload Identity Federation" (Workload-Identitätsföderation), oder WIF, ermöglicht es einem Workload, sich mit einem kurzlebigen Identity-Token zu authentifizieren, das von einem Identity-Provider (IdP) ausgestellt wird, dem du bereits vertraust, wie AWS IAM, Google Cloud oder jedem standardkonformen OIDC-Aussteller (wie GitHub Actions, Kubernetes-Service-Accounts, SPIFFE, Microsoft Entra ID oder Okta). Der Workload tauscht sein vom IdP ausgestelltes JWT bei POST /v1/oauth/token gegen ein kurzlebiges Claude API-Zugriffstoken ein, und das SDK aktualisiert dieses Token automatisch, bevor es abläuft. Es gibt keinen sk-ant-api...-String, der erstellt, verteilt oder rotiert werden muss.
Föderation entfernt langlebige Claude API-Keys aus deiner Umgebung, was den Schadensradius eines geleakten Anmeldedatums verkleinert und dir ermöglicht, den Zugriff mit denselben IdP-Kontrollen zu verwalten, die du bereits für Cloud-Ressourcen verwendest. Sie garantiert für sich genommen keine Ende-zu-Ende-Sicherheit: Die Vertrauenskette ist nur so stark wie die Konfiguration deines Identity-Providers, und ein langlebiges Secret einen Schritt weiter oben (zum Beispiel ein statisches Cloud-Anmeldedatum, das IdP-Tokens erstellen kann) kann sie dennoch untergraben. Kombiniere Föderation mit den Kontrollen deines Providers, wie IP-Allowlists, MFA und Audit-Logging.
Um Föderation zu konfigurieren, erstellst du drei Ressourcen in der Claude Console (einen Service-Account, einen Federation-Issuer und eine Federation-Rule) und richtest dann dein SDK auf die Rule aus. Siehe Workload Identity Federation für die vollständige Einrichtungsanleitung.
Konfiguriere Issuer, Rules und Service-Accounts und tausche dann Tokens aus
Schritt-für-Schritt-Anleitungen für AWS, Google Cloud, Azure, GitHub Actions, Kubernetes, SPIFFE und Okta
Umgebungsvariablen, Validierungsregeln, Profilkonfiguration und Fehlerreferenz
Python, TypeScript, C#, Go, Java, PHP, Ruby und die CLI
Was this page helpful?