Comment puis-je résoudre les erreurs « Unauthorized » lors de l'exécution de requêtes GraphQL dans AWS AppSync ?

Brève description

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

• 401 Unauthorized : La requête est refusée par AWS AppSync ou par le mode d'autorisation car les informations d'identification sont manquantes ou non valides.
• Réponse 200 OK avec une erreur de type Unauthorized : La requête est refusée en raison d'un problème au niveau du résolveur ou au-delà.

Pour déterminer la cause de l'erreur non autorisée, essayez de reproduire le problème dans un navigateur Web. Puis, utilisez 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. Pour les analyser hors ligne, enregistrez les messages dans un fichier HTTP Archive (HAR).

Résolution

Réponse 401 Unauthorized

Pour une réponse 401 Unauthorized, vérifiez la requête réseau qui envoie les données utiles de GraphQL pour confirmer que :

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

Réponse 200 OK

Pour en savoir plus sur les causes des erreurs Unauthorized lors d'une réponse 200 OK, activez les journaux Amazon CloudWatch sur l'API AWS AppSync. Il est recommandé de définir la journalisation au niveau des champs sur Tout et d'inclure du contenu détaillé.

Les requêtes qui reçoivent une réponse 200 OK avec le type d'erreur Unauthorized et le message Not Authorized to access X on type Y sont refusées par logique dans les modèles de mappage du résolveur Apache Velocity Template Language (VTL). 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 réclamations relatives aux jetons de l'utilisateur, telles que les groupes, email_verified, et l'ID client ou le public, avec les vérifications d'autorisation dans les modèles de mappage du résolveur VTL. Vous pouvez utiliser l'outil tiers jwt.io sur le site Web d’AuthO pour vérifier les réclamations relatives aux jetons. Si vous utilisez AWS Amplify, vérifiez que les réclamations relatives aux jetons répondent aux exigences des règles d'autorisation pour le type de schéma du modèle. Par exemple, le modèle de mappage de résolveur suivant pour Amplify vérifie les données transmises lors de 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 plus, 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. Pour plus d'informations, consultez la page Personnaliser les règles d'autorisation sur le site Web d'Amplify Docs.

Autorisation IAM

Examinez les stratégies appliquées à l'utilisateur ou au rôle AWS Identity and Access Management (IAM) qui signe la requête à AWS AppSync. Pour vérifier que appsync:GraphQL est accordé dans le bloc Action pour chacun des champs auxquels l'utilisateur accède, exécutez la commande suivante :

{
  "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 des résolveurs, vérifiez les points suivants :

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

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

Autorisation Lambda

• Vérifiez la logique personnalisée que vous avez écrite dans le code de la fonction Lambda dans lequel isAuthorized est émis 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és.
• Consultez les journaux CloudWatch ou ajoutez des instructions de débogage pour vérifier le flux logique afin de déterminer l'autorisation de l'utilisateur.

Utilisation de plusieurs modes d'autorisation

Lorsque votre API AWS AppSync dispose de plusieurs modes d'autorisation, l'API utilise le mode d'autorisation par défaut qui est défini. Pour un type ou un champ qui requiert 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'autorisation avec les API AWS AppSync GraphQL. Par exemple, une API AWS AppSync a défini API_KEY comme mode d'autorisation par défaut et AMAZON_COGNITO_USER_POOLS 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 requête.
• Les directives sont manquantes dans le schéma GraphQL.