Claude API authenticatie: Anthropic, Bedrock, Vertex

De vier authenticatieroutes voor de Claude API

Authenticatie voor de Claude API komt neer op één beslissing: welke inloggegevens uw client meestuurt. Er zijn vier antwoorden, en dit zijn geen varianten van hetzelfde mechanisme. De directe Anthropic API verstuurt een statische sleutel in een x-api-key header. Amazon Bedrock ondertekent elk verzoek met AWS-inloggegevens; in die configuratie bestaat er nergens een Anthropic-sleutel. Google Cloud verstuurt een kortstondig Google-toegangstoken. Microsoft Foundry gebruikt een door Azure uitgegeven sleutel of een Microsoft Entra-token.

Deze handleiding is bedoeld voor het koppelen van een SDK (software development kit) aan een service die op een Linux-server draait. Als u in plaats daarvan de Claude Code command line tool configureert, zijn de variabelen en de werking anders: zie Claude Code koppelen aan Bedrock of Vertex. Als de service nog niet bestaat, bouw deze dan eerst met een eerste Claude API-app op een VPS en keer hier terug voor de inloggegevens.

Alles hieronder is in augustus 2026 gecontroleerd aan de hand van de platformdocumentatie van Anthropic. Model-id's, prijzen, SDK-versies en endpoint-structuren veranderen continu; daarom linkt deze handleiding naar de pagina's van de aanbieders in plaats van waarden te tonen die snel verouderen.

Route 1: een Anthropic API key

Dit is de directe route en de enige manier waarop Anthropic het geheim verstrekt. Verzoeken gaan naar het Messages-eindpunt op de API-host van Anthropic en elk verzoek bevat drie headers.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Vervang MODEL_ID door een actuele identificatie uit het modellenoverzicht van Anthropic. Een correcte respons is JSON die een content-array en een usage-object bevat. Een onjuiste of verlopen sleutel resulteert in HTTP 401 met authentication_error. Een ontbrekende anthropic-version-header is een afzonderlijke fout, omdat deze header bij elk verzoek vereist is; de SDK's stellen deze automatisch voor u in.

Het opbouwen van de client is de kortste van de vier, omdat er niets geconfigureerd hoeft te worden. Elke officiële SDK leest ANTHROPIC_API_KEY zelfstandig uit de omgeving.

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

Het is aan te raden om de model-identificatie naast de sleutel in de omgeving op te slaan. Modelnamen wijzigen volgens een schema waar u geen controle over heeft, en het opnieuw uitrollen van code om één string aan te passen is onnodig werk.

Sleutels worden aangemaakt in de Console, waar u bij het aanmaken een verloopdatum kiest: presets van 3 uur, 1 dag, 7 dagen of 30 dagen, een aangepaste duur, of Nooit. De verloopdatum staat vast bij het aanmaken en kan achteraf niet worden gewijzigd. Anthropic stuurt de maker van de sleutel een e-mail voordat een langlopende sleutel verloopt, maar een sleutel met een korte levensduur verloopt zonder enige waarschuwingsmail. Een verlopen sleutel geeft een 401-foutmelding en kan niet worden geactiveerd; de enige oplossing is een nieuwe sleutel aanmaken.

Er is geen regio te kiezen bij de directe API en de factuur gaat rechtstreeks naar uw Anthropic-organisatie. Workspaces beperken een sleutel tot één project, wat de meest overzichtelijke manier is om inzicht te krijgen in de kosten van een individuele service. Voor de berekening achter die factuur, zie hoe API-prijzen per token zich verhouden tot een abonnement.

Eén extra optie hoort hier thuis, omdat deze het statische geheim volledig elimineert. Workload Identity Federation stelt een workload in staat om een OpenID Connect (OIDC)-token van een identiteitsprovider die u al vertrouwt, in te ruilen voor een kortstondig Anthropic-token bij POST /v1/oauth/token, waarbij de SDK dit token ververst voordat het verloopt. Er wordt nooit een sk-ant-api...-string aangemaakt of gekopieerd. Dit is geschikt voor Kubernetes, GitHub Actions en cloud-VM's, die al over een platformidentiteit beschikken. Een standaard VPS heeft doorgaans geen dergelijke uitgever, dus op die machine is een API-sleutel in een bestand de meest logische oplossing, en de rest van deze handleiding gaat daarvan uit.

Route 2: AWS-credentials op Amazon Bedrock

Op Bedrock gebruikt u helemaal geen Anthropic-sleutel. De SDK ondertekent elk HTTP-verzoek met AWS Signature Version 4 (SigV4) met behulp van standaard AWS-credentials, en AWS bepaalt of de aanroeper het model mag aanroepen.

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity toont het accountnummer en de ARN (Amazon Resource Name) van de identiteit waaraan uw credentials zijn gekoppeld. Voer dit als eerste uit. Als dit mislukt, zal de Claude-aanroep ook mislukken, omdat de SDK dezelfde keten doorloopt: eerst de constructor-argumenten, daarna de omgevingsvariabelen AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN en AWS_REGION, vervolgens het AWS-configuratiebestand en de rest van de standaardketen (SSO, assumed roles, de ECS task role, de instance metadata service).

Wat verandert bij het opbouwen van de client is de klasse en één argument.

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

De regio is hier geen decoratie. Bedrock-endpoints zijn regiospecifiek, modeltoegang wordt per regio verleend in de AWS-console, en de regio maakt deel uit van de SigV4-handtekening. Een handtekening die voor de ene regio is berekend, wordt door een andere regio geweigerd. Stel AWS_REGION expliciet in de service-omgeving in. Anthropic documenteert dat de AnthropicBedrock-client AWS_REGION leest en terugvalt op us-east-1 wanneer dit niet is ingesteld, en dat deze ~/.aws/config niet leest voor de regio. Daarom kan de AWS CLI op dezelfde machine Claude-modellen succesvol vermelden terwijl uw Python-proces faalt: de CLI las uw configuratiebestand en de client niet.

Op een EC2-instance koppelt u een IAM (identity and access management) role en komt er nooit een geheim op de schijf terecht, omdat de instance metadata service tijdelijke credentials aan de SDK verstrekt. Een VPS buiten AWS heeft geen instance role en geen metadata service. U kiest dan tussen een langdurig access key-paar van een IAM-gebruiker op de server, wat hetzelfde type geheim is als een Anthropic-sleutel, of federatie: authenticeer bij uw identiteitsprovider, roep AWS STS (security token service) aan en gebruik de tijdelijke credentials die dit teruggeeft. Bedrock accepteert ook een bearer token via AWS_BEARER_TOKEN_BEDROCK, gedocumenteerd met een limiet van 12 uur en door AWS beschreven als de minst geprefereerde methode.

De rekening komt bij uw AWS-account terecht in plaats van bij Anthropic, wat meestal de reden is om hiervoor te kiezen. Regionale endpoints hebben een toeslag van 10% ten opzichte van het globale endpoint, zoals gedocumenteerd in augustus 2026. Eén Bedrock-fout is het herkennen waard omdat deze lijkt op een rechtenprobleem, maar dat niet is: Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model.. Dit betreft model-routing en geen enkele wijziging in credentials zal dit verhelpen.

Route 3: Google-inloggegevens op Vertex AI

Google Cloud maakt gebruik van Application Default Credentials (ADC), een vaste zoekvolgorde die de Google-authenticatiebibliotheken volgen om inloggegevens te vinden zonder dat u deze expliciet hoeft te benoemen. ADC controleert eerst GOOGLE_APPLICATION_CREDENTIALS, daarna het bestand dat is geschreven door gcloud auth application-default login, en vervolgens het serviceaccount dat is gekoppeld via de metadata-server.

pip install -U "anthropic[vertex]"
gcloud auth application-default login

Op een werkstation schrijft die login $HOME/.config/gcloud/application_default_credentials.json en bent u klaar. Op een server is dit het verkeerde hulpmiddel, omdat de opgeslagen inloggegevens toebehoren aan een persoon en ongeldig worden zodra dat account wordt verwijderd. Buiten Google Cloud is er bovendien geen metadata-server, waardoor ADC terugvalt op GOOGLE_APPLICATION_CREDENTIALS dat verwijst naar een sleutelbestand van een serviceaccount. Dat JSON-bestand is een langdurig geheim en vereist exact de afhandeling die later in deze handleiding wordt beschreven. Binnen Google Cloud koppelt u een serviceaccount aan de VM en hoeft u geen bestand te beveiligen.

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

Twee zaken veranderen als u onder de SDK doorgaat naar raw HTTP. De model-identifier verplaatst zich vanuit de request body naar het URL-pad, en anthropic_version verplaatst zich vanuit de header naar de body, waar deze vertex-2023-10-16 moet lezen. De inloggegevens zijn een standaard Google access token.

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

De regio is een essentieel argument. global routeert dynamisch voor beschikbaarheid, us en eu zijn multi-region identifiers, en een naam zoals us-east5 zet een enkele regio vast. Multi-region en regionale endpoints kosten 10% meer dan global, zoals gedocumenteerd in augustus 2026. De facturering verloopt via het Google Cloud-project, dus quota en facturen zijn van Google.

Route 4: Microsoft Foundry is de Azure-route

Als u zocht naar Claude op Azure, dan is dit de sectie die u zocht, en er bestaat inderdaad een ondersteunde route. Claude draait in Microsoft Foundry (voorheen Azure AI Foundry), waarbij de facturatie verloopt via de Azure Marketplace in Claude Consumption Units. U maakt een Foundry-resource aan, implementeert een Claude-model daarin en roept een door Azure gehost endpoint aan op https://{resource}.services.ai.azure.com/anthropic/v1/*.

Er zijn twee soorten inloggegevens mogelijk. De eerste is een door Azure uitgegeven key van het tabblad Details van de implementatie in de Foundry-portal, die u meestuurt in een api-key- of x-api-key-header. De tweede is een Microsoft Entra-token; dit is de betere keuze op een server omdat Azure role-based access control (RBAC) dan beheert wie het endpoint mag aanroepen.

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Het veld model bevat uw deployment name, niet een model-identifier. Deze twee komen standaard overeen, maar ze wijken af zodra u zelf een naam geeft aan een implementatie. Dit is de gebruikelijke oorzaak van een Deployment not found-fout bij een verder correct verzoek. De Python- en TypeScript-SDK's lezen ANTHROPIC_FOUNDRY_API_KEY en ANTHROPIC_FOUNDRY_RESOURCE uit de omgeving. Foundry-ondersteuning zit niet in elke SDK: zoals gedocumenteerd in augustus 2026, dekt het C#, Java, PHP, Python en TypeScript, terwijl de Go- en Ruby-SDK's de generieke client nodig hebben die naar de Foundry-basis-URL wijst.

Aan die workaround kleeft een risico. Als ANTHROPIC_API_KEY nog steeds is ingesteld in de omgeving, pikt de generieke client deze op en stuurt uw Anthropic-key naar een Microsoft-endpoint. Verwijder de variabele of schakel omgevingsstandaarden uit op de client. Entra-tokens verlopen na ongeveer een uur, dus een langlopend proces moet deze verversen in plaats van er bij de start één vast te leggen.

Hoe lang is de inloggegevens op uw server geldig?

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

Dit zijn de maxima en standaardwaarden zoals gepubliceerd door elke provider en geraadpleegd in augustus 2026; het zijn geen gemeten waarden. Ze zijn om één reden van belang: ze geven aan hoe lang een gelekte inloggegeven bruikbaar blijft terwijl u nog bezig bent te ontdekken dat deze is gelekt. De kortstondige tokens onderaan de tabel zijn elk 1 uur geldig en de SDK ververst deze automatisch, waardoor de korte levensduur geen extra beheerlast met zich meebrengt. Een aangenomen rol (assumed role) is 12 uur geldig. Een sleutel die is aangemaakt met de voorinstelling van 30 dagen blijft 720 uur geldig, en dat is de inloggegeven die een maand lang in een bestand op uw server staat.

Waar de inloggegevens op een VPS worden opgeslagen

Plaats het geheim in een bestand dat alleen door root kan worden gelezen en laat systemd dit aan het proces doorgeven. Dit onderdeel overleeft elke SDK-versie, dus het is de moeite waard om dit eenmalig en correct uit te voeren.

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

Het bestand bevat platte KEY=value-regels. Geen export, geen aanhalingstekens, geen shell-syntaxis, omdat systemd dit zelf parseert in plaats van het via een shell uit te voeren.

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd leest EnvironmentFile= als root, voordat het overschakelt naar User=claudeapp, waardoor het service-account nooit leestoegang tot het bestand nodig heeft. Modus 600 met root als eigenaar is voldoende; daarom stelt het bovenstaande install-commando dit op die manier in. Start het met sudo systemctl enable --now claude-app en bevestig daarna met systemctl status claude-app dat de unit de status active (running) heeft bereikt in plaats van in een herstartlus te blijven hangen.

Vermijd de volgende vier zaken, elk met een reden die u zelf kunt verifiëren:

• Schrijf de sleutel niet met Environment= in het unit-bestand. Een unit onder /etc/systemd/system is leesbaar voor iedereen, waardoor systemctl cat claude-app het geheim aan elke lokale gebruiker toont.
• Commit het bestand niet. .gitignore houdt een nieuw bestand uit een commit, maar doet niets aan een bestand dat al is gecommit, omdat de git-geschiedenis alles bewaart wat erin is geplaatst.
• Verwerk het niet in een container-image. ENV-regels en --build-arg-waarden worden vastgelegd in de image-lagen en docker history --no-trunc toont deze weer. Het verwijderen van het bestand in een latere laag verwijdert het niet uit de eerdere laag. Geef geheimen door tijdens runtime met --env-file of een gemount bestand.
• Behandel de procesomgeving niet als privé ten opzichte van root. sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ toont de sleutel weer. Het doel is om het geheim weg te houden bij elk ander account op de server, niet bij root, die het hoe dan ook kan lezen.

Dat laatste punt markeert de grens van wat dit ontwerp u oplevert. Een omgevingsvariabele is een prima container voor een geheim wanneer de enige entiteiten die het kunnen lezen de service en root zijn. Het is de verkeerde container wanneer het proces code uitvoert die u niet zelf heeft geschreven, omdat alles wat het proces kan uitvoeren ook zijn eigen omgeving kan lezen. Geheimen buiten het bereik van een AI-agent houden behandelt dat scenario, wat een ander probleem is met een ander antwoord.

Hoe roteer ik de sleutel zonder downtime?

Roteer vooruit en trek de oude daarna in.

1. Maak de nieuwe sleutel aan in de Console, in dezelfde workspace als de oude.
2. Schrijf deze naar /etc/claude-app/env met sudoedit.
3. Voer sudo systemctl restart claude-app uit.
4. Bevestig dat de service reageert op verzoeken en trek daarna de oude sleutel in de Console in.

EnvironmentFile wordt gelezen wanneer de unit start, dus een draaiend proces behoudt de waarde die het bij de start kreeg. systemctl daemon-reload leest unit-bestanden opnieuw in en raakt de omgeving van een draaiend proces niet aan, dus alleen een herstart verwerkt de nieuwe sleutel. Intrekken in stap 1 in plaats van stap 4 veroorzaakt een storing die duurt tot stap 3.

De andere drie routes roteren bij de provider. Een IAM-gebruiker ondersteunt twee actieve toegangssleutels tegelijk, dus maak de tweede aan, implementeer deze en verwijder daarna de eerste. Een Google service account-sleutel roteert op dezelfde manier. Een Foundry-sleutel wordt opnieuw gegenereerd in de portal, wat de oude onmiddellijk ongeldig maakt; schrijf dus de nieuwe waarde weg voordat u klikt. Entra-tokens en gefedereerde Anthropic-tokens behoeven helemaal geen rotatie, en dat is het sterkste argument om deze te gebruiken waar mogelijk.

Terwijl u in de Console bent, stelt u een bestedingslimiet in op de workspace. Een gelekte sleutel is kostbaar nog voordat het iets anders is, en het beperken van wat een agent op een VPS kan uitgeven doorloopt de instellingen.

Waarom geeft mijn client een 401- of 403-foutmelding?

401 met authentication_error op de directe API. De sleutel is onjuist, ingetrokken of verlopen. De vervaldatum wordt vaak over het hoofd gezien, omdat de code niet is gewijzigd en het verzoek gisteren nog werkte. Controleer de kolom voor de vervaldatum van de sleutel in de Console, of lees expires_at uit via de Admin API, waar deze null is voor sleutels zonder vervaldatum.

De SDK negeert uw federatie-instelling en gebruikt in plaats daarvan een sleutel. ANTHROPIC_API_KEY en ANTHROPIC_AUTH_TOKEN staan in de prioriteitsvolgorde voor inloggegevens boven federatie, waardoor ze deze overschrijven. Het scherpe randje hiervan: een variabele die als lege string is geëxporteerd, bezet nog steeds zijn plek, dus ANTHROPIC_API_KEY="" zorgt ervoor dat de SDK authenticeert met een lege sleutel in plaats van door te gaan naar de volgende methode. Gebruik unset ANTHROPIC_API_KEY.

401 met de algemene melding Authentication failed bij federatie. Die melding is bewust identiek voor elke mogelijke oorzaak, zodat een aanroeper uw regelconfiguratie niet kan achterhalen door de fouttekst te lezen. De werkelijke reden staat geregistreerd op de pagina met authenticatiegeschiedenis in de Console. Begin daar in plaats van te gissen naar de JWT.

403 op Foundry. Het token is geauthenticeerd, maar uw Azure-account mist een rol die de aanroep toestaat. Wijs een Azure RBAC-rol toe, zoals Foundry User (voorheen Azure AI User) of Cognitive Services User, aan de identiteit die het verzoek doet.

Problemen met Bedrock. Voer eerst aws sts get-caller-identity uit als de servicegebruiker. Dit geeft aan of de server überhaupt over bruikbare AWS-inloggegevens beschikt, wat een probleem met inloggegevens onderscheidt van een probleem met modeltoegang of een regio-mismatch. Modeltoegang wordt per regio verleend in de AWS-console en het is eenvoudig om dit in de ene regio in te schakelen terwijl u een andere regio aanroept.

FAQ

Heb ik een Anthropic API-key nodig om Claude te gebruiken op Bedrock of Vertex?

Nee. Op Amazon Bedrock ondertekent de SDK elk verzoek met AWS-credentials via SigV4, en op Google Cloud wordt een Google-toegangstoken verzonden dat wordt gevonden via Application Default Credentials. In beide configuraties bestaat er geen door Anthropic uitgegeven geheim; het verbruik wordt gefactureerd aan het cloudaccount in plaats van aan Anthropic. Dit is ook de reden waarom een Anthropic-key die achterblijft in ANTHROPIC_API_KEY een risico vormt op deze hosts: een generieke client die naar een cloud-endpoint wijst, zal deze zonder meer meesturen.

Is Claude beschikbaar op Azure?

Ja, via Microsoft Foundry, voorheen Azure AI Foundry. U maakt een Foundry-resource aan, implementeert een Claude-model daarin en roept https://{resource}.services.ai.azure.com/anthropic/v1/messages aan met een door Azure uitgegeven key in een api-key-header of een Microsoft Entra bearer-token. Het verbruik wordt gefactureerd via de Azure Marketplace in Claude Consumption Units. Het veld model in de request-body moet uw deployment-naam bevatten; deze is alleen gelijk aan de model-identifier totdat u een deployment hernoemt.

Waar moet ik de Claude API-key opslaan op een Linux-server?

In een bestand dat eigendom is van root met modus 600, geladen via EnvironmentFile= in een systemd-unit. systemd leest dat bestand als root voordat het overschakelt naar de User= van de unit, dus het service-account heeft er geen toegang voor nodig. Houd de key buiten de repository, buiten het unit-bestand zelf (dat voor iedereen leesbaar is en wordt afgedrukt door systemctl cat), en buiten container-image-layers, aangezien docker history --no-trunc alles weergeeft wat is ingesteld met ENV of --build-arg.

Waarom geeft mijn Claude API-verzoek een 401-foutmelding terwijl er niets is veranderd?

De meest voorkomende oorzaak is een key die de vervaldatum heeft bereikt die bij aanmaak is gekozen. De vervaldatum wordt bij aanmaak ingesteld, kan achteraf niet worden bewerkt, en kortstondige keys verlopen zonder waarschuwingsmail. Een verlopen key kan niet opnieuw worden geactiveerd; maak daarom een vervangende key aan, schrijf deze in het environment-bestand, herstart de service en trek daarna de oude key in. Als de key zeker nog geldig is, controleer dan of een verouderde credential deze niet overschaduwt: ANTHROPIC_API_KEY ingesteld op een lege string krijgt nog steeds voorrang boven elke andere credential-bron.