Ontbrekende authenticatietoken bij toegang tot API Gateway?

Ik probeer een Lambda-functie aan te roepen via AWS API Gateway.
Als ik authenticatietype GEEN vermeld, werkt het prima, maar API wordt openbaar en iedereen met url heeft toegang tot mijn API.
Om de API-aanroep veilig te maken, gebruik ik het authenticatietype AWS_IAM en
heeft ook het AmazonAPIGatewayInvokeFullAccess-beleid aan mijn gebruiker toegevoegd, maar kreeg deze foutmelding:

{ message: "Missing Authentication Token"}

Ik weet niet wat ik hier mis.

Antwoord 1, autoriteit 100%

Ik denk dat u rechtstreeks toegang probeert te krijgen tot de API-link, dit zal niet werken omdat de API is beveiligd met de IAM-rol en u AWS-authenticatie moet verstrekken, d.w.z. toegangssleutel en geheime sleutel.

Gebruik de Postman Chrome-extensie om uw API te testen:
http://docs .aws.amazon.com/apigateway/latest/developerguide/how-to-use-postman-to-call-api.html

Antwoord 2, autoriteit 91%

Ik heb wat tijd verloren om een dwaze reden:

Als je een stage maakt, bevat de weergegeven link niet het brongedeelte van de URL:

API-URL:
https://1111.execute-api.us-east-1.amazonaws .com/dev

API + RESOURCE-URL
https://1111.execute-api.us-east -1.amazonaws.com/dev/get-list

De /get-listontbrak

En natuurlijk moet u controleren of de configuratie van de methode er als volgt uitziet:

Antwoord 3, autoriteit 51%

Ik had net hetzelfde probleem en het lijkt erop dat dit bericht ook wordt weergegeven als de bron niet kan worden gevonden.

In mijn geval had ik de API bijgewerkt, maar was ik vergeten deze opnieuw te implementeren. Het probleem is opgelost nadat de bijgewerkte API in mijn werkgebied is geïmplementeerd.

Antwoord 4, autoriteit 22%

Zorg ervoor dat u eerst op de specifieke resource in de Stages-structuur klikt, want dat zal een URL vullen met het volledige padnaar de resource (in plaats van alleen het hoofdpad):

Zie voor andere oorzaken http://www. awslessons.com/2017/aws-api-gateway-missing-authentication-token/

Antwoord 5, autoriteit 16%

Het lijkt erop dat (vanaf april 2019) AWS API Gateway deze uitzondering om verschillende redenen genereert – meestal wanneer u een eindpunt bereikt dat API Gateway niet kan bereiken, hetzij omdat het niet is geïmplementeerd, of ook in gevallen waar die specifieke HTTP-methode niet wordt ondersteund.

Ik zou willen dat de gateway meer geschikte foutcodes verzendt, zoals HTTP 405 Methode niet ondersteund of HTTP 404 niet gevonden, in plaats van een generieke HTTP 403 Forbidden.

Antwoord 6, autoriteit 14%

Gevonden in de documenten:

Als de AWS_IAM-autorisatie zou worden gebruikt, zou u het verzoek ondertekenen met behulp van de Signature Version 4-protocollen.

Ondertekeningsverzoek met handtekeningversie 4

U kunt ook een SDK voor uw API genereren.

Een SDK voor een API genereren in API-gateway

Zodra u de SDK voor het platform van uw keuze heeft gegenereerd, wordt in stap 6 vermeld dat als u AWS-inloggegevens gebruikt, het verzoek aan de API zal worden ondertekend:

6. Als u de door API Gateway gegenereerde SDK wilt initialiseren met AWS-referenties, gebruikt u de onderstaande code. Als u AWS-inloggegevens gebruikt, worden alle verzoeken aan de API ondertekend. Dit betekent dat u de juiste CORS Accept-headers moet instellen voor elk verzoek:

   var apigClient = apigClientFactory.newClient({
     accessKey: 'ACCESS_KEY',
     secretKey: 'SECRET_KEY',
   });
   

Antwoord 7, autoriteit 14%

Zorg ervoor dat u Resource maakt en vervolgens de methode erin maakt. Dat was voor mij het probleem. Bedankt

Antwoord 8, autoriteit 12%

Ik probeer al het bovenstaande, als je alle stappen in de bovenstaande antwoorden hebt uitgevoerd en je het probleem niet oplost, dan:

1. klik in het linkermenu op ‘Bronnen’
2. klik rechts op “Bronnen” op de api-methode die u wilt testen, zoals “POST/GET enz.)
3. klik op de “ACTIE” lijst (deze staat hierboven bij de API-methode in stap 2
4. selecteer “DEPLOY API” (doe het alstublieft, zelfs als u uw api al implementeert)
5. selecteer in “implementatiefase” “prod” of wat u ook schrijft in uw vorige implementatie (het zal uw vorige implementatie overschrijven
6. druk op implementeren

Ik denk dat omdat, wanneer ik het “METHODEVERZOEK” aanmaak (zie stap 2 hoe je naar dit menu gaat), in “Autorisatie” ik “AWS_IAM” selecteer
na het testen van api, in aws-testoptie, probeer ik het in “postbode”
Dan begrijp ik de in “methode-aanvraag”, in “Autorisatie”, zou ik “geen”

selecteren

Ik verander het op geen, maar ik ding de AWS, moet het opnieuw inzetten, zoals ik

uitleg

Antwoord 9, Autoriteit 8%

Als u AWS_IAM-authenticatie inschakelt, moet u uw verzoek ondertekenen met AWS-inloggegevens met AWS Signature versie 4 .

Opmerking : Aanmelden bij de AWS-console ondertekent de verzoeken van uw browser niet automatisch aan uw API.

Antwoord 10, Autoriteit 6%

Soms wordt dit bericht weergegeven wanneer u een verkeerde API roept

Controleer uw API-eindpunt

Antwoord 11, Autoriteit 4%

In mijn geval heb ik ‘/’ backslash aan het einde van API gemist.
Zo’n domme fout.

https: //le9dq5L9.execute-api. EU-WEST-1.AMAZONAWS.COM/V1/PUTDOCTORINFO/

Antwoord 12, Autoriteit 2%

Deze fout komt meestal wanneer u een verkeerd API-eindpunt belt.
Controleer uw API-eindpunt die u belt en verifieert dit op API GATEWAY.

Antwoord 13, Autoriteit 2%

Voor de record, als u geen inloggegevens zou gebruiken, laat deze fout ook zien wanneer u de Validator instelt in uw post- / poct-methode om “lichaam, query-stringparameters en headers te” valideren van het lichaam “Of de andere optie” Valideer Query String Parameters en headers “…. In dat geval zal het op zoek zijn naar de inloggegevens op de kop en het verzoek af te wijzen. Om het op te vatten, als u niet van plan bent inloggegevens te verzenden en deze open wilt houden, moet u deze optie niet instellen op aanvraag Validator (stel deze in op geen of om het lichaam te valideren)

Antwoord 14, Autoriteit 2%

Als u een API gebruikt met eindpunt van het type privé , moet u zeker zijn van:

1. U roept de API binnen bij uw AWS-account (bijvoorbeeld: van een EC2-instantie die in uw account is gemaakt)

2. Zet noodzakelijke referentie (toegangs- en geheime sleutels) in de EC2-instantie in route ~ / .Ws / referenties (deze route is voor Linux-instanties) als IAM-gebruiker MFA AWS_SSESSION_TOKE WERELGEWIJZEN nodig zijn.

3. Gebruik VPCE (VPC Eindpoint) URL. Voorbeeld: Curl Https://vpce-0C0471B7TEST-JKZNIZI5.EXECUTE-API.US-EAST-1.VPCE.AMAZONAWS.com/DEV/API/V1/STATUS

4. Uw EC2-instantie heeft een beveiligingsgroep dan een uitgaande verkeer toestaan ​​aan een andere beveiligingsgroep die eigendom is van de VPCE zoals:

5. Uw VPACE Security Group Staat inkomend verkeer vanuit een andere beveiligingsgroep (vorige SG uit EC2-instantie) in eigendom van de EC2-instantie zoals:

Zie: https: // docs.Aws.amazon.com/Ampayway/latest/developerguide/apayway-private-apis.html

Antwoord 15, Autoriteit 2%

In mijn geval was het behoorlijk een stom.
Ik heb ertoe aangezet dat nieuwe entiteiten worden gemaakt met behulp van de post en het faalde met “Ontbrekende authenticatietoken”. Ik heb dat gemist dat het om een ​​of andere reden werd gedefinieerd als geplaatst die goed werkt.

Antwoord 16, Autoriteit 2%

Volgens mijn ervaring, controleer de volgende stappen:

1. Zorg ervoor dat u aan de kant van de API-gateway het juiste pad toevoegt en de bron publiceert in de gewenste fase. Voor sommige URL-patronen, zoals padparameter(/user/{user_id}), moet meer aandacht worden besteed aan een vinkje.

2. Zorg ervoor dat u de juiste options-methode voor deze bron configureert, want soms zijn het de CORS die dit probleem veroorzaken.

3. Zorg er aan de Lambda-kant voor dat u de juiste handlernaam als ingangspunt opgeeft.

4. Controleer altijd de cloudwatch-logboeken van uw lambda die u kunnen helpen de problemen aan uw lambda-kant te identificeren.

Antwoord 17

Controleer eerst of de API die u in de lamda-functie hebt gemaakt, is geregistreerd bij uw AWS-project of niet. Ga daarvoor naar de API-gateway in je AWS-console. Als het niet is geregistreerd, registreer het dan. Dit is de belangrijkste oorzaak van dit probleem.

Je kunt zelfs in je bestand aws.export.jszien dat er paden zijn die overeenkomen met je API ['/items'].

Uw API moet daar aanwezig zijn, anders wordt het beveiligingstoken niet aan verzoeken toegevoegd. Registreer het hiervoor gewoon in uw project cloud-logic in uw console.

Als het er is, gebruik dan de bovengenoemde oplossing
http:// docs.aws.amazon.com/apigateway/latest/developerguide/how-to-use-postman-to-call-api.html

Antwoord 18

Bijdragen:

Ik had een soortgelijke fout omdat mijn antwoord de ‘body’ niet als volgt bevatte:

retour {
‘statuscode’: 200,
‘body’: “moet de body-tag bevatten als je deze vervangt, werkt niet”
}

Antwoord 19

Ik had hetzelfde probleem dat ik op de volgende manier heb opgelost:

GET-methodetest

https://54wtstq8d2.execute-api.ap-southeast-2.amazonaws.com/dev/echo/hello

Authorization tab -> 
•   select type(AWS signature)
•   Add AccessKey and SecretKey

Antwoord 20

Als u een IAM-rol instelt voor uw server met de machtiging AmazonAPIGatewayInvokeFullAccess, moet u nog steeds headers doorgeven bij elk verzoek. Je kunt dit in python doen met de aws-requests-authbibliotheek als volgt:

import requests
from aws_requests_auth.boto_utils import BotoAWSRequestsAuth
auth = BotoAWSRequestsAuth(
    aws_host="API_ID.execute-api.us-east-1.amazonaws.com",
    aws_region="us-east-1",
    aws_service="execute-api"
)
response = requests.get("https://API_ID.execute-api.us-east-1.amazonaws.com/STAGE/RESOURCE", auth=auth)

Antwoord 21

Nou, voor iedereen die nog steeds het probleem heeft en ik voel me echt heel dom nadat ik me dit realiseerde, maar ik heb de standaard url van /itemsdoorgegeven tijdens het toevoegen van API. Maar ik bleef het eindpunt bellen met /api. Speciale dank aan Carlos Alberto Schneider, want ik realiseerde me mijn probleem na het lezen van je bericht.