Linden Consulting.
Architecture

API Gateway 403 Missing Authentication Token: Konfigurationsfehler beheben

2026-05-13 · 8 Min. Lesezeit

Sie haben gerade Ihre API deployt und testen sie mit curl. Die Antwort kommt zurück:

{
  "message": "Missing Authentication Token"
}

HTTP-Status: 403. Sie starren einen Moment darauf. Sie verwenden keine Authentifizierung auf diesem Endpoint. Es ist eine öffentliche API. Warum fragt API Gateway nach einem Authentication Token?

Hier ist die Sache, die die meisten Entwickler auf die harte Tour lernen: Diese Fehlermeldung ist eine der irreführendsten in ganz AWS. In der Mehrheit der Fälle bedeutet "Missing Authentication Token" nicht, dass Ihnen ein Authentication Token fehlt. Es bedeutet, dass die angeforderte Ressource nicht existiert. API Gateway gibt diesen 403 statt eines 404 aus Sicherheitsgründen zurück — es will nicht verraten, welche Pfade existieren und welche nicht.

Lassen Sie mich alle Ursachen dieses Fehlers durchgehen und wie man jede systematisch diagnostiziert.

Schritt 1: API und Stage verifizieren

Beginnen Sie damit zu bestätigen, dass Sie den korrekten API-Endpoint ansprechen. Rufen Sie die Liste Ihrer REST-APIs ab:

aws apigateway get-rest-apis \
  --query 'items[*].{Name:name,Id:id,CreatedDate:createdDate}' \
  --output table

Dann verifizieren Sie, dass die Stage existiert:

aws apigateway get-stages \
  --rest-api-id YOUR_API_ID \
  --query 'item[*].{StageName:stageName,DeploymentId:deploymentId,LastUpdated:lastUpdatedDate}' \
  --output table

Das API-Gateway-Invoke-URL-Format ist:

https://{api-id}.execute-api.{region}.amazonaws.com/{stage}/{resource}

Eine falsche API-ID, falsche Region oder falscher Stage-Name erzeugen alle den "Missing Authentication Token"-Fehler. Ich habe Teams Stunden mit dem Debugging von Authentifizierung verschwenden sehen, wenn das tatsächliche Problem prod vs production im Stage-Namen war.

Ursache 1: Ressourcenpfad existiert nicht

Die häufigste Ursache. Sie fordern /users/123 an, aber die API hat nur /user/123 definiert (Singular vs Plural), oder die Ressource wurde als /users/{id} definiert, aber Sie treffen /users ohne den Pfadparameter.

Listen Sie alle Ressourcen in der API auf:

aws apigateway get-resources \
  --rest-api-id YOUR_API_ID \
  --query 'items[*].{Id:id,Path:path,Methods:resourceMethods}' \
  --output table

Dies zeigt Ihnen jeden Pfad und welche HTTP-Methoden auf jedem konfiguriert sind. Wenn Ihr angeforderter Pfad nicht in dieser Liste ist, haben Sie Ihre Antwort.

Häufige Abweichungen:

  • /api/v1/users vs /v1/users (zusätzliches Präfix)
  • /users/{userId} vs /users/{id} (der Pfadvariablenname ist für das Routing irrelevant, aber die Pfadstruktur zählt)
  • /users/ vs /users (abschließender Schrägstrich — API Gateway behandelt diese als verschiedene Ressourcen)

Ursache 2: Änderungen nicht auf die Stage deployt

Das erwischt regelmäßig Leute. Sie haben eine neue Ressource oder Methode in der API-Gateway-Konsole oder über die API hinzugefügt, aber Sie haben kein neues Deployment erstellt. API Gateway hat einen zweistufigen Prozess: API definieren, dann auf eine Stage deployen. Änderungen an der API-Definition sind erst nach dem Deployment live.

Prüfen Sie das letzte Deployment:

aws apigateway get-deployments \
  --rest-api-id YOUR_API_ID \
  --query 'items[*].{Id:id,CreatedDate:createdDate,Description:description}' \
  --output table

Vergleichen Sie die Deployment-ID auf der Stage mit dem neuesten Deployment:

# Aktuelle Deployment-ID der Stage abrufen
aws apigateway get-stage \
  --rest-api-id YOUR_API_ID \
  --stage-name prod \
  --query '{DeploymentId:deploymentId,LastUpdated:lastUpdatedDate}' \
  --output table

Wenn die Deployment-ID der Stage nicht mit dem neuesten Deployment übereinstimmt, erstellen Sie ein neues Deployment:

aws apigateway create-deployment \
  --rest-api-id YOUR_API_ID \
  --stage-name prod \
  --description "Neue Ressourcen deployen"

Ursache 3: Fehlender API-Key in der Anfrage

Wenn Ihre API-Methode einen API-Key erfordert (apiKeyRequired: true) und die Anfrage keinen x-api-key-Header enthält, erhalten Sie den "Missing Authentication Token"-Fehler.

Prüfen Sie, ob die Methode einen API-Key erfordert:

aws apigateway get-method \
  --rest-api-id YOUR_API_ID \
  --resource-id RESOURCE_ID \
  --http-method GET \
  --query '{ApiKeyRequired:apiKeyRequired,AuthorizationType:authorizationType}' \
  --output table

Wenn ApiKeyRequired true ist, müssen Sie den API-Key in Ihrer Anfrage mitschicken:

curl -H "x-api-key: YOUR_API_KEY" \
  https://YOUR_API_ID.execute-api.us-east-1.amazonaws.com/prod/users

Verifizieren Sie auch, dass der API-Key mit einem Usage-Plan verknüpft ist, der Ihre API-Stage enthält:

# Usage-Plans auflisten
aws apigateway get-usage-plans \
  --query 'items[*].{Name:name,Id:id,ApiStages:apiStages}' \
  --output json

# API-Keys in einem Usage-Plan auflisten
aws apigateway get-usage-plan-keys \
  --usage-plan-id YOUR_USAGE_PLAN_ID \
  --query 'items[*].{Name:name,Id:id,Type:type}' \
  --output table

Ursache 4: IAM-Autorisierung ohne SigV4-Signierung

Wenn der Autorisierungstyp der Methode AWS_IAM ist, muss jede Anfrage mit Signature Version 4 signiert werden. Eine Anfrage ohne SigV4-Signierung erhält den "Missing Authentication Token"-Fehler.

Prüfen Sie den Autorisierungstyp:

aws apigateway get-method \
  --rest-api-id YOUR_API_ID \
  --resource-id RESOURCE_ID \
  --http-method GET \
  --query 'authorizationType' \
  --output text

Wenn dies AWS_IAM zurückgibt, müssen Sie Ihre Anfragen signieren. Mit dem AWS-CLI:

# awscurl-Tool für SigV4-signierte Anfragen verwenden
pip install awscurl

awscurl --service execute-api \
  --region us-east-1 \
  "https://YOUR_API_ID.execute-api.us-east-1.amazonaws.com/prod/users"

Oder wenn Sie für Tests auf offenen Zugriff wechseln möchten:

aws apigateway update-method \
  --rest-api-id YOUR_API_ID \
  --resource-id RESOURCE_ID \
  --http-method GET \
  --patch-operations op=replace,path=/authorizationType,value=NONE

# Nach der Änderung nicht vergessen zu deployen
aws apigateway create-deployment \
  --rest-api-id YOUR_API_ID \
  --stage-name prod

Ursache 5: Cognito-Authorizer-Fehlkonfiguration

Wenn Sie einen Cognito-User-Pool-Authorizer verwenden, können verschiedene Fehlkonfigurationen den 403-Fehler verursachen:

  • Der Authorization-Header enthält ein abgelaufenes oder ungültiges JWT-Token
  • Der Authorizer ist mit der falschen User-Pool-ID konfiguriert
  • Die Audience (aud-Claim) des Tokens stimmt nicht mit der im Authorizer konfigurierten App-Client-ID überein
  • Das Token ist ein Access-Token, aber der Authorizer erwartet ein ID-Token (oder umgekehrt)

Prüfen Sie die Authorizer-Konfiguration:

aws apigateway get-authorizers \
  --rest-api-id YOUR_API_ID \
  --query 'items[*].{Name:name,Type:type,ProviderARNs:providerARNs,IdentityValidationExpression:identityValidationExpression}' \
  --output json

Verifizieren Sie die Gültigkeit des Tokens durch Dekodierung (JWT-Tokens sind base64-kodiert):

# JWT-Payload dekodieren (mittleres Segment)
echo "YOUR_JWT_TOKEN" | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool

Prüfen Sie die exp- (Ablauf), aud- (Audience) und iss- (Issuer) Claims. Der Issuer sollte mit Ihrer Cognito-User-Pool-URL übereinstimmen: https://cognito-idp.{region}.amazonaws.com/{userPoolId}.

Ursache 6: CORS-Preflight-OPTIONS-Methode nicht konfiguriert

Wenn ein Browser eine Cross-Origin-Anfrage stellt, sendet er zuerst eine OPTIONS-Preflight-Anfrage. Wenn Ihre API keine OPTIONS-Methode auf der Ressource konfiguriert hat, schlägt der Preflight mit dem "Missing Authentication Token"-Fehler fehl, und der Browser blockiert die eigentliche Anfrage.

Prüfen Sie, ob OPTIONS konfiguriert ist:

aws apigateway get-resources \
  --rest-api-id YOUR_API_ID \
  --query 'items[?path==`/users`].resourceMethods' \
  --output json

Wenn OPTIONS nicht in der Liste ist, müssen Sie es hinzufügen. Die OPTIONS-Methode sollte CORS-Header zurückgeben und keine Authentifizierung erfordern:

# OPTIONS-Methode erstellen
aws apigateway put-method \
  --rest-api-id YOUR_API_ID \
  --resource-id RESOURCE_ID \
  --http-method OPTIONS \
  --authorization-type NONE

# Mock-Integration einrichten (OPTIONS braucht kein Backend)
aws apigateway put-integration \
  --rest-api-id YOUR_API_ID \
  --resource-id RESOURCE_ID \
  --http-method OPTIONS \
  --type MOCK \
  --request-templates '{"application/json": "{\"statusCode\": 200}"}'

# Antwort mit CORS-Headern konfigurieren
aws apigateway put-method-response \
  --rest-api-id YOUR_API_ID \
  --resource-id RESOURCE_ID \
  --http-method OPTIONS \
  --status-code 200 \
  --response-parameters '{
    "method.response.header.Access-Control-Allow-Headers": false,
    "method.response.header.Access-Control-Allow-Methods": false,
    "method.response.header.Access-Control-Allow-Origin": false
  }'

aws apigateway put-integration-response \
  --rest-api-id YOUR_API_ID \
  --resource-id RESOURCE_ID \
  --http-method OPTIONS \
  --status-code 200 \
  --response-parameters '{
    "method.response.header.Access-Control-Allow-Headers": "'\''Content-Type,Authorization,X-Api-Key'\''",
    "method.response.header.Access-Control-Allow-Methods": "'\''GET,POST,OPTIONS'\''",
    "method.response.header.Access-Control-Allow-Origin": "'\''*'\''"
  }'

Denken Sie daran, nach dem Hinzufügen der OPTIONS-Methode zu deployen.

Ursache 7: Custom-Domain-Base-Path-Mapping-Probleme

Wenn Sie einen benutzerdefinierten Domainnamen (z.B. api.example.com) mit API Gateway verwenden, kann das Base-Path-Mapping Routing-Probleme verursachen. Wenn das Mapping einen Base-Path wie v1 enthält, wird api.example.com/v1/users auf /users in der API gemappt. Aber wenn Sie api.example.com/users direkt anfragen, wird keine Ressource gefunden.

Prüfen Sie die Base-Path-Mappings:

aws apigateway get-base-path-mappings \
  --domain-name api.example.com \
  --query 'items[*].{BasePath:basePath,RestApiId:restApiId,Stage:stage}' \
  --output table

Wenn der Base-Path v1 ist, müssen Ihre Anfragen /v1/ im Pfad enthalten. Wenn Sie möchten, dass die Root direkt mappt, setzen Sie den Base-Path auf (none).

Ursache 8: WAF blockiert die Anfrage

Wenn Sie AWS WAF mit Ihrem API Gateway verknüpft haben, könnte eine WAF-Regel die Anfrage blockieren. WAF-Blockaden können als 403-Fehler erscheinen, die identisch mit der "Missing Authentication Token"-Antwort aussehen.

Prüfen Sie, ob WAF mit der API-Stage verknüpft ist:

aws wafv2 get-web-acl-for-resource \
  --resource-arn arn:aws:apigateway:us-east-1::/restapis/YOUR_API_ID/stages/prod \
  --query 'WebACL.{Name:Name,Id:Id}' \
  --output table

Wenn eine WAF angehängt ist, prüfen Sie die WAF-Logs, ob Ihre Anfrage blockiert wird:

aws wafv2 list-web-acls \
  --scope REGIONAL \
  --query 'WebACLs[*].{Name:Name,Id:Id,ARN:ARN}' \
  --output table

WAF-Blockaden geben typischerweise einen anderen Response-Body zurück als die Standard-"Missing Authentication Token"-Meldung, aber nicht immer — benutzerdefinierte WAF-Response-Bodies können die API-Gateway-Fehlerantwort nachahmen.

Diagnose-Workflow

Wenn Sie "Missing Authentication Token" sehen, folgen Sie dieser Reihenfolge:

  1. URL verifizieren — korrekte API-ID, Region, Stage und Ressourcenpfad
  2. Prüfen, ob die Ressource existiert — get-resources für alle Pfade
  3. Prüfen, ob Änderungen deployt sind — Stage-Deployment-ID mit neuestem vergleichen
  4. Auth-Typ prüfen — NONE, AWS_IAM, CUSTOM oder COGNITO_USER_POOLS?
  5. Für API-Keys — x-api-key-Header und Usage-Plan-Verknüpfung verifizieren
  6. Für IAM-Auth — sicherstellen, dass Anfragen SigV4-signiert sind
  7. Für Cognito — JWT-Token-Claims validieren
  8. Für CORS — prüfen, ob OPTIONS-Methode auf der Ressource existiert
  9. Für Custom-Domains — Base-Path-Mapping verifizieren
  10. Für WAF — prüfen, ob Regeln die Anfrage blockieren

Präventions-Best-Practices

  1. CloudWatch-Access-Logging verwenden auf Ihren API-Stages. Das gibt Ihnen den vollständigen Anfragepfad, die Methode und den Response-Code für jede Anfrage und macht es einfach, Pfad-Abweichungen zu erkennen:
aws apigateway update-stage \
  --rest-api-id YOUR_API_ID \
  --stage-name prod \
  --patch-operations op=replace,path=/accessLogSettings/destinationArn,value=arn:aws:logs:us-east-1:123456789012:log-group:api-gateway-access-logs

  1. Deployments automatisieren. Verlassen Sie sich niemals auf manuelle Deployments auf Stages. Verwenden Sie CI/CD-Pipelines, die nach der Aktualisierung der API-Definition immer ein Deployment erstellen.

  2. OpenAPI/Swagger-Definitionen verwenden, um Ihre API zu verwalten. Importieren Sie die vollständige API-Definition bei jedem Deployment, damit Sie nie unsynchronisierte Ressourcen haben.

  3. Detaillierte CloudWatch-Metriken aktivieren und Alarme für 4xx-Fehlerraten einrichten, um Konfigurationsprobleme zu erkennen, bevor Benutzer sie melden.

  4. Vor dem Client-Deployment mit curl testen. Ein einfacher curl-Befehl mit ausführlicher Ausgabe (curl -v) zeigt die genaue URL, Header und Antwort und durchbricht Abstraktionsebenen, die das eigentliche Problem verbergen können.

Hilfe bei der API-Gateway-Konfiguration nötig?

Die Fehlermeldungen von API Gateway können Sie stundenlang auf die falsche Debugging-Fährte schicken. Wenn Ihre API unerwartete 403er zurückgibt oder Sie eine neue API aufbauen und die Authentifizierung, CORS und Custom-Domain-Konfiguration von Anfang an richtig machen möchten, können wir helfen. Kontaktieren Sie uns für eine kostenlose AWS-Beratung — wir haben Hunderte von API-Gateway-Deployments konfiguriert und können schnell identifizieren, was Ihre 403-Fehler verursacht.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen