Comment résoudre les erreurs « non autorisées » lors de l'exécution de requêtes GraphQL dans AWS AppSync ?

Dernière mise à jour : 20/07/2022

Je reçois des erreurs « Non autorisé » lorsque j'exécute des requêtes GraphQL avec AWS AppSync. Comment résoudre ces erreurs ?

Brève description

Il existe deux types d'erreurs « non autorisées » définies par le code d'état HTTP renvoyé dans la réponse :

  • 401 Non autorisé : la demande est refusée par AWS AppSync ou le mode d'autorisation, car les informations d'identification sont manquantes ou non valides.
  • 200 réponses OK avec une erreur de type non autorisé : la demande est refusée en raison d'un problème au niveau du résolveur ou à un niveau supérieur à celui-ci.

Pour déterminer la cause de l'erreur non autorisée, essayez de reproduire le problème dans un navigateur Web. Utilisez ensuite les outils réseau du navigateur pour capturer les messages de requête et de réponse HTTP. Analysez les messages pour déterminer où l'erreur s'est produite. Remarque : pour une analyse hors connexion, enregistrez les messages dans un fichier d'archive HTTP (HAR).

Solution

401 Réponse non autorisée

Pour une réponse 401 Non autorisé, vérifiez la demande réseau qui envoie la charge utile GraphQL afin de confirmer que :

  • L'en-tête Autorisation ou x-api-key est présente et contient les informations d'identification correctes pour le mode d'autorisation requis pour l'opération ou le champ. Si l'en-tête ne possède pas des informations d'identification correctes, le mode d'autorisation rejette la demande.
  • Pour les jetons Web JSON (JWT), l'en-tête d’autorisation n'inclut pas le texte « Bearer » (depuis le site Web GitHub).
  • Le JWT provient du groupe d'utilisateurs Amazon Cognito ou du fournisseur OIDC approprié.
  • Les informations d'identification sont valides et n'ont pas expiré.

Réponse 200 OK

Pour plus de détails sur les causes des erreurs non autorisées donnant lieux à une réponse 200 OK, activez Amazon CloudWatch Logs sur l'API AWS AppSync. Pour résoudre les problèmes, il est recommandé de définir la journalisation sur Tout au niveau du champ et d'inclure du contenu détaillé.

Les demandes qui reçoivent une réponse 200 OK avec le type d'erreur non autorisé et le message Accès X non autorisé de type Y sont refusées par logique dans le mappage du résolveur Apache Velocity Template Language (VTL) modèles. Pour résoudre ce problème, suivez les étapes de dépannage suivantes pour le mode d'autorisation que vous utilisez.

Autorisation Amazon Cognito et OIDC

Comparez les revendications de token de l'utilisateur, telles que groups, email_verified et l'ID client ou l'audience, avec les vérifications d'autorisation dans les modèles de mappage de résolveur VTL. Vous pouvez utiliser l'outil tiers jwt.io (d'AuthO) pour vérifier les revendications de jetons. Si vous utilisez AWS Amplify, vérifiez que les revendications de jeton prennent en charge les exigences de la règle d'autorisation sur le type de schéma du modèle.

A titre d’exemple, le modèle de mappage de résolveur suivant pour Amplify vérifie les données transmises par la vérification d'autorisation préliminaire effectuée par AWS AppSync.

#if( $util.authType() == "User Pool Authorization" )
  #if( !$isAuthorized )
    #set( $staticGroupRoles = [{"claim":"cognito:groups","entity":"Admin","allowedFields":xxxxx,yyyyy}] )
    #foreach( $groupRole in $staticGroupRoles )
      #set( $groupsInToken = $util.defaultIfNull($ctx.identity.claims.get($groupRole.claim), []) )
      #if( $groupsInToken.contains($groupRole.entity) )
        #if( $groupRole.isAuthorizedOnAllFields )
          #set( $isAuthorized = true )
          #break
        #else
          $util.qr($allowedFields.addAll($groupRole.allowedFields))
        #end
      #end
    #end
  #end
#end

De même, si vous utilisez Amplify, vérifiez que les règles d'autorisation du schéma autorisent les opérations de création, de lecture, de mise à jour ou de suppression.

Autorisation IAM

Passez en revue les politiques appliquées à l'utilisateur ou au rôle AWS Identity and Access Management (IAM) qui signe la requête à AWS AppSync. Vérifiez que AppSync:GraphQL est accordé dans le bloc Action pour chacun des champs auxquels l'utilisateur accède.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "appsync:GraphQL"
      ],
      "Resource": [
        "arn:aws:appsync:us-east-1:111122223333:apis/graphql-api-id/types/Query/fields/field-1",
        "arn:aws:appsync:us-east-1:111122223333:apis/graphql-api-id/types/Mutation/fields/field-2"
      ]
    }
  ]
}

Remarque : remplacez graphql-api-id par l'ID de votre API GraphQL et field-1 et field-2 par vos champs.

Si vous utilisez Amplify pour générer les modèles de mappage de résolveur, vérifiez les éléments suivants :

  • Le nom de session de rôle avec lequel les informations d'identification IAM sont émises correspond à CognitoIdentityCredentials.
  • Les informations d'identification IAM sont identiques au rôle auth ou unauth généré par Amplify.

Si le nom de session du rôle ne correspond pas à la chaîne, l'accès au champ ou à l'opération est refusé.

Autorisation Lambda

  • Vérifiez toute logique personnalisée que vous avez écrite dans le code de fonction Lambda où IsAuthorized sera affiché pour vous assurer qu'elle est définie sur true.
  • Assurez-vous que le tableau DeniedFields ne contient pas le champ ou l'opération demandé.
  • Consultez les journaux CloudWatch ou ajoutez des instructions de débogage pour vérifier le flux logique permettant de déterminer l'autorisation des utilisateurs.

Utilisation de plusieurs modes d'autorisation

Lorsque votre API AWS AppSync dispose de plusieurs modes d'autorisation, l'API utilise le mode d'autorisation défini par défaut. Pour un type ou un champ nécessitant l'un des autres modes d'autorisation, vous devez également définir une directive d'autorisation pour ce mode. Pour plus d'informations, consultez la section Utilisation de plusieurs types d'autorisations avec les API GraphQL AWS AppSync.

Par exemple, pour une API AWS AppSync, API_KEY est défini comme mode d'autorisation par défaut et AMAZON_COGNITO_USER_POOLS est défini comme mode d'autorisation supplémentaire. Si vous souhaitez utiliser les deux modes, vous devez définir les directives d'autorisation @aws_api_key et @aws_cognito_user_pools.

type Post @aws_api_key @aws_cognito_user_pools {
 id: ID!
 author: String
 title: String
}

Remarque : Le mode d'autorisation API_KEY par défaut rejette les requêtes pour les raisons suivantes :

  • Un JWT Amazon Cognito est envoyé dans l'en-tête de la demande.
  • Les directives sont absentes du schéma GraphQL.

Cet article vous a-t-il été utile ?


Avez-vous besoin d'aide pour une question technique ou de facturation ?