Comment résoudre les erreurs HTTP 403 Forbidden (Accès interdit) lors de l'utilisation d'un mécanisme d'autorisation Lambda avec une API REST API Passerelle ?

Lecture de 6 minute(s)

Les appels vers mon API REST Amazon API Passerelle renvoient des erreurs 403 Forbidden (Accès interdit) après la création d'un mécanisme d'autorisation AWS Lambda. Comment résoudre ces erreurs ?

Brève description

Une erreur peut se produire pour les raisons suivantes :

La fonction du mécanisme d'autorisation Lambda renvoie un document de politique AWS Identity and Access Management (IAM) qui refuse explicitement l'accès à l'appelant.
L'API dispose d'une politique de ressources attachée qui refuse explicitement l'accès à l'appelant.

Si l'appel à votre API contient un jeton ou des référentiels d'identité manquants, nuls ou non validés, vous obtenez une erreur 401 Unauthorized. Pour plus d'informations, consultez Pourquoi est-ce que je reçois des erreurs 401 Unauthorized (Non autorisé) de la passerelle API après avoir créé un mécanisme d'autorisation Lambda ?

Remarque : cet article traite uniquement des erreurs 403 liées aux mécanismes d'autorisation Lambda configurés pour une API REST. Pour en savoir plus sur le dépannage d'autres types d'erreurs 403, voir Comment résoudre les erreurs « HTTP 403 Forbidden » (Accès interdit) dans API Gateway ?

Solution

Confirmer la cause de l'erreur

Remarque :

Si vous ne l'avez pas déjà fait, activez CloudWatch Logs pour votre API REST API Gateway.
Si vous obtenez des erreurs lors de l'exécution de commandes dans l'interface de ligne de commande AWS (AWS CLI), assurez-vous d'utilisez la dernière version d'AWS CLI.
Si vous avez apporté des modifications à la configuration du mécanisme d'autorisation, l'API doit être redéployée.

1. Passez en revue le message d'erreur dans la réponse d'API Gateway. Recherchez un message d'erreur similaire à l'un des éléments suivants.

Exemple de message d'erreur pour les mécanismes d'autorisation Lambda qui renvoient un document de la politique IAM avec un refus explicite

{
    "message": "User is not authorized to access this resource with an explicit deny"
}

Exemple de message d'erreur pour les fonctions d'autorisation Lambda qui renvoient un document de politique IAM avec un refus implicite

{
    "message": "User is not authorized to access this resource"
}

Exemple de message d'erreur pour les API REST qui ont une stratégie de ressources attachée qui refuse implicitement l'accès à l'appelant

{
    "message": "User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn>"
}

Exemple de message d'erreur pour les API REST qui ont une politique de ressources attachée qui refuse explicitement l'accès à l'appelant

{
    "message": "User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn> with an explicit deny"
}

Remarque : Pour plus d'informations sur le comportement résultant lorsque l'accès à une passerelle API est contrôlé par une politique IAM, consultez la section Tableaux des résultats de l'évaluation des stratégies.

2. Consultez les journaux d'exécution de la passerelle API dans CloudWatch pour consulter le flux d'autorisation. Notez la sortie du mécanisme d'autorisation Lambda et le résultat de l'évaluation de la stratégie de ressources de la passerelle API. Vous voyez également un message d'erreur de journal semblable à l'un des éléments suivants.

Exemple de message d'erreur de journal pour lorsqu'un jeton requis est manquant ou ne correspond pas à la validation du jeton

Extended Request Id: MY92nHDwwwIdGxzR=
Unauthorized request: <request-id>

Remarque : l'ID de demande étendue est généré de façon aléatoire. La valeur de l'ID de demande étendue de vos journaux est différente.

Exemple de message d'erreur de journal pour quand un mécanisme d’autorisation Lambda renvoie une politique qui refuse l'accès

Sending request to https://lambda.<region>.amazonaws.com/2015-03-31/functions/<lambda-authorizer-arn>/invocations
Authorizer result body before parsing:
{
  "principalId": "user",
  "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Deny",
        "Resource": "<resource-arn>"
      }
    ]
  }
}
Using valid authorizer policy for principal: <principal>
Successfully completed authorizer execution
The client is not authorized to perform this operation.

Remarque : la stratégie renvoyée dépend de votre mécanisme d'autorisation Lambda. Si l'arn-ressource de la stratégie renvoyée n'inclut pas la ressource demandeuse, la demande sera implicitement refusée.

Exemple de message d'erreur de journal lorsque la stratégie de ressource de la passerelle API refuse la demande

Extended Request Id: MY-BIVb4GEdGeZB=
ExplicitDenyException User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn> with an explicit deny: <request-id>

Résoudre les erreurs « not authorized to access this resource »(non autorisé à accéder à cette ressource) du mécanisme d'autorisation Lambda

L’erreur « not authorized to access this resource »(non autorisé à accéder à cette ressource) s’affiche parfois en raison de la mise en cache des politiques. Pour confirmer que la mise en cache des autorisations est activée, vérifiez la configuration de votre mécanisme d'autorisation Lambda dans la console API Gateway. Ensuite, effectuez l'une des actions suivantes :

Pour un test ponctuel, exécutez la commande d’AWS CLI flush-stage-authorizers-cache. Lorsque les entrées de cache du mécanisme d'autorisation sont vidées, appelez à nouveau votre API.
Désactivez la mise en cache des politiques, puis appelez à nouveau votre API.
Remarque : lorsque vous désactivez la mise en cache des politiques pour un mécanisme d'autorisation basé sur des paramètres de demande, API Gateway ne valide pas les appels à votre API avant d'appeler la fonction du mécanisme d'autorisation Lambda.
Modifiez la clé de cache du mécanisme d'autorisation en mettant à jour le nom d'en-tête spécifié dans Token Source (Source du jeton) (pour les mécanismes d'autorisation basés sur les jetons) ou Identity Source (Source d'identité) (pour les mécanismes d'autorisation basés sur les paramètres de demande). Redéployez votre API pour valider les modifications. Ensuite, appelez à nouveau votre API à l'aide de l'en-tête de jeton nouvellement configuré ou des sources d'identité.

Si cette erreur se produit constamment, déterminez la raison pour laquelle votre mécanisme d'autorisation refuse explicitement l'accès à l'appelant en passant en revue le code de fonction de votre mécanisme d'autorisation Lambda. Si vous avez déterminé que le problème est provoqué par la mise en cache, vous pouvez mettre à jour le code afin qu'il autorise l'accès à l'appelant. Pour obtenir des instructions, consultez Pourquoi ma ressource proxy API Gateway avec un mécanisme d'autorisation Lambda dont la mise en cache est activée renvoie-t-elle des erreurs HTTP 403 ?

Résoudre les erreurs « not authorized to perform : execute-api : Invoke » (non autorisé à exécuter : execute-api:Invoke)

Déterminez si votre politique de ressources API est valide ou non, ou si elle refuse explicitement l'accès à vos appels en passant en revue la politique de ressources de votre API. Vous pouvez afficher les journaux d'exécution de votre API afin de voir le résultat de la réponse pour la politique de ressources.

Pour plus d'informations, consultez Présentation du langage de la politique d’accès pour Amazon API Gateway et la politique de ressources et du mécanisme d'autorisation Lambda.