Die Claude API unterstützt zwei Möglichkeiten, Anfragen zu authentifizieren:
| Methode | Anmeldedaten | Am besten geeignet für |
|---|---|---|
| API-Key | Langlebiges sk-ant-api...-Secret im x-api-key-Header | Lokale Entwicklung, Prototyping, Skripte und Single-Tenant-Server, bei denen du die Speicherung von Secrets kontrollierst |
| Workload Identity Federation | Kurzlebiges Bearer-Token, das aus dem Identity-Token deines Identity Providers eingetauscht wird | Produktions-Workloads auf Cloud-Plattformen (AWS, Google Cloud, Azure), CI/CD-Pipelines und Kubernetes, bei denen du statische Secrets eliminieren möchtest |
Beide Methoden gewähren denselben Zugriff auf Claude API-Endpunkte. Wähle API-Keys, um schnell loszulegen, und wechsle zu Workload Identity Federation, wenn dein Workload bereits eine von der Plattform ausgestellte Identität hat, die du föderieren kannst.
API-Keys sind statische Secrets, die du in der Claude Console generierst und bei jeder Anfrage mitsendest.
x-api-key-Header bei direkten HTTP-Anfragen, oder setze die Umgebungsvariable ANTHROPIC_API_KEY, und die Client-SDKs übernehmen ihn automatisch.POST /v1/messages
x-api-key: YOUR_API_KEY
anthropic-version: 2023-06-01
content-type: application/jsonAPI-Keys haben kein Ablaufdatum. Speichere sie in einem Secrets-Manager, rotiere sie regelmäßig und widerrufe jeden Key, von dem du vermutest, dass er kompromittiert wurde.
client = Anthropic(api_key="my-anthropic-api-key")
# oder, wenn ANTHROPIC_API_KEY in der Umgebung gesetzt ist:
client = Anthropic()„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" (Identitätsanbieter), oder IdP, ausgestellt wird, dem du bereits vertraust – etwa AWS IAM, Google Cloud oder jeder standardkonforme OIDC-Issuer (wie GitHub Actions, Kubernetes-Service-Accounts, SPIFFE, Microsoft Entra ID oder Okta). Der Workload tauscht sein vom IdP ausgestelltes JWT über POST /v1/oauth/token gegen ein kurzlebiges Claude API-Access-Token ein, und das SDK erneuert 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 kompromittierten Credentials verkleinert und dir ermöglicht, den Zugriff mit denselben IdP-Kontrollen zu verwalten, die du bereits für Cloud-Ressourcen verwendest. Sie garantiert jedoch nicht von sich aus End-to-End-Sicherheit: Die Vertrauenskette ist nur so stark wie die Konfiguration deines Identity Providers, und ein langlebiges Secret einen Schritt weiter vorgelagert (zum Beispiel ein statisches Cloud-Credential, das IdP-Tokens ausstellen 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 verweist dann dein SDK auf die Rule. 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?