Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# AWS Signature Version 4 pour les demandes d'API
**Important**
Si vous utilisez un AWS SDK (voir [Exemple de code et bibliothèques](https://aws.amazon.com/developer/)) ou un outil AWS Command Line Interface (AWS CLI) pour envoyer des demandes d'API AWS, vous pouvez ignorer le processus de signature, car les clients du SDK et de la CLI authentifient vos demandes à l'aide des clés d'accès que vous fournissez. À moins que vous n'ayez une bonne raison de ne pas le faire, nous vous recommandons de toujours utiliser un kit SDK ou la CLI.
Dans les régions qui prennent en charge plusieurs versions de signature, les demandes de signature manuelle impliquent que vous devez spécifier la version de signature à utiliser. Lorsque vous envoyez des demandes à des points d'accès multirégionaux, SDKs la CLI passe automatiquement à l'utilisation de Signature Version 4A sans configuration supplémentaire.
Les informations d'authentification que vous envoyez dans une demande doivent inclure une signature. AWS Signature Version 4 (SigV4) est le protocole de AWS signature permettant d'ajouter des informations d'authentification aux demandes d' AWS API.
Vous n’utilisez pas votre clé d’accès secrète pour signer les requêtes d’API. Vous utilisez plutôt le processus de signature SigV4. La signature des requêtes implique :
1. Création d’une requête canonique basée sur les détails de la requête.
1. Calcul d'une signature à l'aide de vos AWS informations d'identification.
1. Ajout de cette signature à la requête en tant qu’en-tête Autorisation.
AWS reproduit ensuite ce processus et vérifie la signature, en accordant ou en refusant l'accès en conséquence.
Le SigV4 symétrique vous oblige à dériver une clé limitée à un seul AWS service, dans une seule AWS région, un jour donné. La clé et la signature calculée sont donc différentes pour chaque région, ce qui signifie que vous devez connaître la région à laquelle la signature est destinée.
Asymmetric Signature Version 4 (SigV4a) est une extension qui permet de signer avec un nouvel algorithme et de générer des signatures individuelles vérifiables dans plusieurs Régions AWS . Avec SigV4A, vous pouvez signer une demande pour plusieurs régions, avec un routage et un basculement fluides entre les régions. Lorsque vous utilisez le AWS SDK ou AWS CLI que vous invoquez une fonctionnalité qui nécessite une signature multirégionale, le type de signature est automatiquement modifié pour utiliser SigV4a. Pour en savoir plus, consultez [Comment fonctionne AWS SigV4A](#how-sigv4a-works).
## Comment fonctionne AWS SigV4
Les étapes suivantes décrivent le processus général de calcul d’une signature à l’aide de SigV4 :
1. La **chaîne à signer** dépend du type de demande. Par exemple, lorsque vous utilisez l’en-tête d’autorisation HTTP ou les paramètres de requête pour l’authentification, vous utilisez une combinaison d’éléments de requête pour créer la chaîne à signer. Pour une requête HTTP POST, la politique `POST` de la demande est la chaîne que vous signez.
1. La **clé de signature** est une série de calculs, le résultat de chaque étape étant intégré dans la suivante. La dernière étape est la clé de signature.
1. Lorsqu'un AWS service reçoit une demande authentifiée, il recrée la **signature** à l'aide des informations d'authentification contenues dans la demande. Si les signatures correspondent, le service traite la demande. Sinon, il rejette la demande.
Pour de plus amples informations, veuillez consulter [Éléments d'une signature de demande d' AWS API](reference_sigv-signing-elements.md).
## Comment fonctionne AWS SigV4A
Sigv4a utilise des signatures asymétriques basées sur le chiffrement à clé publique-privée. SigV4a suit un processus de dérivation d’informations d’identification similaire à celui de Sigv4, sauf que Sigv4a utilise la même clé pour Signer toutes les demandes sans avoir besoin de dériver une clé de Signature distincte en fonction de la date, du service et de la région. Une paire de clés ECDSA ([Elliptic Curve Digital Signature Algorithm](https://csrc.nist.gov/glossary/term/ecdsa)) peut être dérivée de votre clé d'accès secrète existante. AWS
Le système utilise le chiffrement asymétrique pour vérifier les signatures multirégions, de sorte qu’ AWS n’a besoin de stocker que vos clés publiques. Les clés publiques ne sont pas secrètes et ne peuvent pas être utilisées pour signer des requêtes. Des signatures asymétriques sont requises pour les requêtes d’API multirégionales, comme pour les points d’accès multirégionaux Amazon S3.
Les étapes suivantes décrivent le processus général de calcul d’une signature à l’aide de SigV4a :
1. La **chaîne à signer** dépend du type de demande. Par exemple, lorsque vous utilisez l’en-tête d’autorisation HTTP ou les paramètres de requête pour l’authentification, vous utilisez une combinaison d’éléments de requête pour créer la chaîne à signer. Pour une requête HTTP POST, la politique `POST` de la demande est la chaîne que vous signez.
1. La **clé de signature** est dérivée d’une clé d’accès secrète AWS par le biais d’une série de calculs, le résultat de chaque étape étant intégré dans la suivante. La dernière étape produit la paire de clés.
1. Lorsqu'un AWS service reçoit une demande signée avec SigV4a, AWS vérifie la signature en utilisant uniquement la moitié publique de la paire de clés. Si la signature est valide, la requête est authentifiée et le service la traite. Les requêtes dont les signatures ne sont pas valides sont rejetées.
Pour plus d'informations sur SIGv4a pour les requêtes d'API multirégionales, consultez le projet [a-signing-examplessigv4](https://github.com/aws-samples/sigv4a-signing-examples) sur. GitHub
## Quand signer des demandes ?
Lorsque vous écrivez du code personnalisé qui envoie des demandes d'API AWS, vous devez inclure le code qui signe les demandes. Vous pouvez écrire du code personnalisé pour les raisons suivantes :
+ Vous utilisez un langage de programmation pour lequel il n'existe aucun kit SDK AWS .
+ Vous avez besoin d'un contrôle total sur la manière dont les demandes sont envoyées AWS.
Alors que les demandes d'API authentifient l'accès avec AWS SigV4, AWS SDKs puis AWS CLI authentifient vos demandes à l'aide des clés d'accès que vous fournissez. Pour plus d'informations sur l'authentification avec AWS SDKs et le AWS CLI, consultez[Ressources supplémentaires](#reference_aws-signing-resources).
## Pourquoi les demandes sont-elles signées ?
Le processus de signature aide à sécuriser les demandes de différentes façons :
+ **Vérifier l'identité du demandeur**
Les demandes authentifiées nécessitent une signature que vous créez à l'aide de vos clés d'accès (ID de clé d'accès, clé d'accès secrète). Si vous utilisez des informations d'identification de sécurité temporaires, les calculs de signature nécessitent également un jeton de sécurité. Pour plus d'informations, veuillez consulter la rubrique [Accès par programmation des informations d'identification de sécuritéAWS](security-creds-programmatic-access.md).
+ **Protéger les données en transit**
Pour éviter qu'une demande ne soit falsifiée pendant son transit, certains de ses éléments sont utilisés pour calculer son hachage (digest) et la valeur de hachage obtenue est incluse comme partie intégrante de la demande. Lorsqu'un Service AWS reçoit la demande, il utilise les mêmes informations pour calculer un hachage et le compare à la valeur de hachage de votre demande. Si les valeurs ne correspondent pas, AWS refuse la demande.
+ **Assurer une protection contre les attaques potentielles par relecture**
Dans la plupart des cas, une demande doit parvenir AWS dans les cinq minutes suivant l'horodatage indiqué dans la demande. Dans le cas contraire, AWS refuse la demande.
AWS SigV4 peut être exprimé dans l'en-tête d'autorisation HTTP ou sous forme de chaîne de requête dans l'URL. Pour de plus amples informations, veuillez consulter [Méthodes d’authentification](reference_sigv-authentication-methods.md).
## Ressources supplémentaires
+ Pour plus d’informations sur le processus de signature SigV4 pour les différents services, consultez [Demander des exemples de signature](reference_sigv-examples.md).
+ Pour configurer les informations d'identification pour l'accès programmatique à la AWS CLI, voir [Authentification et informations d'accès](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*.
+ Ils AWS SDKs incluent le code source GitHub pour signer les demandes AWS d'API. Pour obtenir des exemples de code, veuillez consulter [Exemples de projets dans le référentiel AWS d'échantillons](reference_sigv-examples.md#signature-v4-examples-sdk).
+ AWS SDK pour .NET — [AWS4Signer.cs](https://github.com/aws/aws-sdk-net/blob/master/sdk/src/Core/Amazon.Runtime/Internal/Auth/AWS4Signer.cs)
+ AWS SDK pour C\$1\$1 — [AWSAuthV4Signer.cpp](https://github.com/aws/aws-sdk-cpp/blob/main/src/aws-cpp-sdk-core/source/auth/signer/AWSAuthV4Signer.cpp)
+ AWS SDK pour Go — [sigv4.go](https://github.com/aws/smithy-go/blob/a4c9efcda6aa54c75d1a130d1320a2709eebf51d/aws-http-auth/sigv4/sigv4.go)
+ AWS SDK pour Java — [BaseAws4Signer.java](https://github.com/aws/aws-sdk-java-v2/blob/master/core/auth/src/main/java/software/amazon/awssdk/auth/signer/internal/BaseAws4Signer.java)
+ AWS SDK pour JavaScript — [signature-v4](https://github.com/smithy-lang/smithy-typescript/tree/main/packages/signature-v4)
+ AWS SDK pour PHP — [SignatureV4.php](https://github.com/aws/aws-sdk-php/blob/master/src/Signature/SignatureV4.php)
+ AWS SDK pour Python (Boto) — [signers.py](https://github.com/boto/botocore/blob/develop/botocore/signers.py)
+ AWS SDK pour Ruby — [signer.rb](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sigv4/lib/aws-sigv4/signer.rb)
# Éléments d'une signature de demande d' AWS API
**Important**
À moins que vous n'utilisiez la CLI AWS SDKs ou, vous devez écrire du code pour calculer les signatures qui fournissent des informations d'authentification dans vos demandes. Le calcul des AWS signatures dans la version 4 de Signature peut être une tâche complexe, et nous vous recommandons d'utiliser la AWS SDKs CLI dans la mesure du possible.
Chaque HTTP/HTTPS demande utilisant la signature Signature Version 4 doit contenir ces éléments.
**Topics**
+ [
## Spécification du point de terminaison
](#endpoint-specification)
+ [
## Action
](#action)
+ [
## Paramètres d'action
](#parameters)
+ [
## Date
](#date)
+ [
## Informations d'authentification
](#authentication)
## Spécification du point de terminaison
Spécifie le nom DNS du point de terminaison auquel vous envoyez la requête. Ce nom contient généralement le code du service et la région. Par exemple, le nom du point de terminaison Amazon DynamoDB de la région `us-east-1` est `dynamodb.us-east-1.amazonaws.com`.
Pour les requêtes HTTP/1.1, vous devez inclure l'en-tête `Host`. Pour les requêtes HTTP/2, vous pouvez utiliser l'en-tête `:authority` ou `Host`. Utilisez uniquement l'en-tête `:authority` à des fins de conformité avec la spécification HTTP/2. Tous les services ne prennent pas en charge les requêtes HTTP/2.
Pour les points de terminaison pris en charge par chaque service, consultez [Points de terminaison et quotas de service](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) dans *Références générales AWS*.
## Action
Spécifie une action d'API pour le service. Par exemple, l'action DynamoDB `CreateTable` ou l'action Amazon EC2 `DescribeInstances`.
Pour les actions prises en charge par chaque service, consultez la [référence d'autorisation des services](https://docs.aws.amazon.com//service-authorization/latest/reference/reference.html).
## Paramètres d'action
Spécifie les paramètres de l'action spécifiée dans la requête. Chaque action d' AWS API comporte un ensemble de paramètres obligatoires et facultatifs. La version de l'API est généralement un paramètre obligatoire.
Pour connaître les paramètres pris en charge par une action d'API, consultez la référence d’API du service.
## Date
Spécifie la date et l'heure de la requête. L'inclusion de la date et de l’heure dans la requête permet d'empêcher des tiers d'intercepter cette dernière et de la soumettre à nouveau ultérieurement. La date que vous spécifiez dans l’étendue des informations d'identification doit correspondre à la date de votre requête.
L'horodatage doit être au format UTC et au format ISO 8601 suivant : *AAAAMMJJ*T*HHMMSS*Z. Par exemple, `20220830T123600Z`. N'incluez pas de millisecondes dans l'horodatage.
Vous pouvez utiliser un en-tête `date` ou `x-amz-date`, ou inclure `x-amz-date` comme un paramètre de requête. Si nous ne trouvons pas d'en-tête `x-amz-date`, nous cherchons un en-tête `date`.
## Informations d'authentification
Chaque demande que vous envoyez doit inclure les informations suivantes. AWS utilise ces informations pour garantir la validité et l'authenticité de la demande.
+ Algorithme : algorithme que vous utilisez dans le cadre du processus de signature.
+ SigV4 : `AWS4-HMAC-SHA256` permet de spécifier la version 4 de la Signature à l’aide de l’algorithme de hachage `HMAC-SHA256`.
+ SigV4a : utilisez `AWS4-ECDSA-P256-SHA256` pour spécifier l’algorithme de hachage `ECDSA-P256-SHA-256`.
+ Informations d’identification : chaîne formée en concaténant votre ID de clé d’accès et les composants de votre champ d’application d’informations d’identification.
+ SigV4 : la portée des informations d’identification comprend votre clé d’accès, la date au format *AAAAMMJJ*, le code de région, le code de service et la chaîne de terminaison `aws4_request`, séparés par des barres obliques (/). Le code Région, le code de service et la chaîne de terminaison doivent utiliser des caractères minuscules.
```
AKIAIOSFODNN7EXAMPLE/YYYYMMDD/region/service/aws4_request
```
+ SigV4a : la portée des informations d’identification comprend la date au format AAAAMMJJ, le nom du service et la chaîne de terminaison `aws4_request`, séparés par des barres obliques (/). Notez que la portée des informations d’identification n’inclut pas la région, car celle-ci est couverte dans un en-tête `X-Amz-Region-Set` distinct.
```
AKIAIOSFODNN7EXAMPLE/YYYYMMDD/service/aws4_request
```
+ En-têtes signés : en-têtes HTTP à inclure dans la signature, séparés par des points-virgules (;). Par exemple, `host;x-amz-date`.
Pour SigV4a, vous devez inclure un en-tête de jeu de régions qui spécifie l’ensemble des régions dans lesquelles la demande sera valide. L’en-tête `X-Amz-Region-Set` est spécifié sous forme de liste de valeurs séparées par des virgules. L’exemple suivant montre un en-tête de région qui permet d’effectuer une demande dans les régions us-east-1 et us-west-1.
```
X-Amz-Region-Set=us-east-1,us-west-1
```
Vous pouvez utiliser des caractères génériques (\$1) dans les régions pour spécifier plusieurs régions. Dans l’exemple suivant, l’en-tête permet de faire une demande à la fois dans les régions us-west-1 et us-west-2.
```
X-Amz-Region-Set=us-west-*
```
+ Signature : chaîne codée en hexadécimal qui représente la signature calculée. Vous devez calculer la signature en utilisant l'algorithme que vous avez spécifié dans le paramètre `Algorithm`.
Pour de plus amples informations, veuillez consulter [Méthodes d’authentification](reference_sigv-authentication-methods.md).
# Méthodes d’authentification
**Important**
À moins que vous n'utilisiez la CLI AWS SDKs ou, vous devez écrire du code pour calculer les signatures qui fournissent des informations d'authentification dans vos demandes. Le calcul des AWS signatures dans la version 4 de Signature peut être une tâche complexe, et nous vous recommandons d'utiliser la AWS SDKs CLI dans la mesure du possible.
Vous pouvez exprimer les informations d'authentification à l'aide de l'une des méthodes suivantes.
## En-tête d'autorisation HTTP
L'en-tête HTTP `Authorization` est l'une des méthodes d'authentification des demandes les plus courantes. Toutes les opérations de l'API REST (à l'exception des chargements via un navigateur utilisant des demandes `POST`) nécessitent cet en-tête.
Les exemples suivants montrent la valeur d’en-tête `Authorization` pour SigV4 et SigV4a. Des sauts de ligne sont ajoutés à cet exemple pour faciliter la lecture. Dans votre code, l'en-tête doit être une chaîne continue. Il n'y a pas de virgule entre l'algorithme et les informations d'identification, mais les autres éléments doivent être séparés par des virgules.
**Example SigV4**
```
Authorization: AWS4-HMAC-SHA256
Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,
SignedHeaders=host;range;x-amz-date,
Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024
```
**Example SigV4a**
```
Authorization: AWS4-ECDSA-P256-SHA256
Credential=AKIAIOSFODNN7EXAMPLE/20130524/s3/aws4_request,
SignedHeaders=host;range;x-amz-date;x-amz-region-set,
Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024
```
Le tableau suivant décrit les différents composants de la valeur de l'en-tête d'autorisation dans l'exemple précédent :
| Composant | Description |
| --- | --- |
| Autorisation | Algorithme utilisé pour calculer la signature. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) |
| Informations d'identification | Votre ID de clé d’accès et les informations relatives au champ d’application. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) La valeur est spécifiée à l’aide du format AAAAMMJJ. La valeur est S3 lors de l’envoi d’une demande à Amazon S3. |
| SignedHeaders | Une liste d’en-têtes de demande séparés par des points-virgules que vous avez utilisés pour calculer Signature. La liste inclut uniquement les noms d'en-tête, qui doivent être en minuscules. Par exemple : `host;range;x-amz-date` Pour SigV4a, vous devez inclure un en-tête de jeu de régions qui spécifie l’ensemble des régions dans lesquelles la demande sera valide. L’en-tête X-Amz-Region-Set est spécifié sous forme de liste de valeurs séparées par des virgules. |
| Signature | La signature de 256 bits exprimée en 64 caractères hexadécimaux minuscules. Exemples :`fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024` Veuillez noter que les calculs de signature varient en fonction de l'option que vous choisissez pour transférer la charge utile. |
## Paramètres des chaînes de requête
Vous pouvez utiliser une chaîne de requête pour exprimer entièrement une demande dans une URL. Dans ce cas, vous utilisez les paramètres de requête pour fournir les informations de demande, y compris les informations d'authentification. Comme la signature de la demande fait partie de l'URL, ce type d'URL est généralement appelé URL présignée. Vous pouvez utiliser le présigné URLs pour intégrer des liens cliquables au format HTML, qui peuvent être valables jusqu'à sept jours. Pour plus d'informations, consultez [Authentification des demandes : utilisation des paramètres de requête (AWS Signature version 4)](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html) dans le manuel *Amazon S3 API Reference*.
Les exemples suivants montrent le présigné URLs pour SigV4 et SigV4a. Des sauts de ligne sont ajoutés à cet exemple pour faciliter la lecture :
**Example SigV4**
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ?
X-Amz-Algorithm=AWS4-HMAC-SHA256 &
X-Amz-Credential=/20130721//s3/aws4_request &
X-Amz-Date=20130721T201207Z &
X-Amz-Expires=86400 &
X-Amz-SignedHeaders=host &X-Amz-Signature=
```
**Example SigV4a**
```
http://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ?
X-Amz-Algorithm=AWS4-ECDSA-P256-SHA256 &
X-Amz-Credential=/20240721/s3/aws4_request &
X-amz-Region-Set= &
X-Amz-Date=20240721T201207Z &
X-Amz-Expires=86400 &
X-Amz-SignedHeaders=host;x-amz-region-set &
X-Amz-Signature=
```
**Note**
La valeur `X-Amz-Credential` dans l'URL affiche le caractère « / » uniquement pour des raisons de lisibilité. En pratique, il doit être encodé sous la forme %2F. Par exemple :
`&X-Amz-Credential=%2F20130721%2Fus-east-1%2Fs3%2Faws4_request`
Le tableau suivant décrit les paramètres de requête de l'URL qui fournissent des informations d'authentification.
| Nom du paramètre de la chaîne d'interrogation | Description |
| --- | --- |
| X-Amz-Algorithm | Version de AWS signature et algorithme que vous avez utilisés pour calculer la signature. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) |
| X-Amz-Credential | Outre l’ID de votre clé d’accès, ce paramètre fournit également le champ d’application pour lequel la signature est valide. Cette valeur doit correspondre au champ d'application que vous utilisez dans les calculs de signature, comme indiqué dans la section suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) Pour obtenir la liste des chaînes AWS régionales, consultez la section [Points de terminaison régionaux](https://docs.aws.amazon.com//general/latest/gr/rande.html#regional-endpoints) dans le manuel de *référence AWS général*. |
| X-Amz-Region-Set | Ensemble de régions dans lesquelles la demande sera valide. L’en-tête x-amz-region-set est spécifié sous forme de liste de valeurs séparées par des virgules. |
| X-Amz-Date | Le format de date et d'heure doit respecter la norme ISO 8601 et doit être au format `yyyyMMddTHHmmssZ`. Par exemple, si la date et l'heure étaient « 01/08/2016 15:32:41.982-700 », elles doivent d'abord être converties en UTC (temps universel coordonné), puis soumises sous la forme « 20160801T223241Z ». |
| X-Amz-Expires | Indique la période, en secondes, pendant laquelle l'URL présignée générée est valide. Par exemple, 86 400 (24 heures). Cette valeur est un nombre entier. La valeur minimale que vous pouvez définir est 1 et la valeur maximale est de 604 800 (sept jours). Une URL présignée peut être valide pendant sept jours au maximum, car la clé de signature que vous utilisez pour le calcul de la signature est valide pendant sept jours au maximum. |
| X-Amz- SignedHeaders | Répertorie les en-têtes que vous avez utilisés pour calculer la signature. Les en-têtes suivants sont obligatoires pour les calculs de signature : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) Pour plus de sécurité, vous devez signer tous les en-têtes de demande que vous prévoyez d'inclure dans votre demande. |
| X-Amz-Signature | Fournit la signature pour authentifier votre demande. Cette signature doit correspondre à la signature que le service calcule, sinon, le service refuse la demande. Par exemple, `733255ef022bec3f2a8701cd61d4b371f3f28c9f193a1f02279211d48d5193d7` Les calculs de signature sont décrits dans la section suivante. |
| X-Amz-Security-Token | Paramètre d'information d'identification facultatif si vous utilisez des informations d'identification provenant du service STS. |
# Création d'une demande AWS d'API signée
**Important**
Si vous utilisez un AWS SDK (voir [Exemple de code et bibliothèques](https://aws.amazon.com/developer/)) ou un outil AWS Command Line Interface (AWS CLI) pour envoyer des demandes d'API AWS, vous pouvez ignorer cette section car les clients du SDK et de la CLI authentifient vos demandes à l'aide des clés d'accès que vous fournissez. À moins que vous n'ayez une bonne raison de ne pas le faire, nous vous recommandons de toujours utiliser un kit SDK ou la CLI.
Dans les régions qui prennent en charge plusieurs versions de signature, les demandes de signature manuelle impliquent que vous devez spécifier la version de signature utilisée. Lorsque vous envoyez des demandes à des points d'accès multirégionaux, SDKs la CLI passe automatiquement à l'utilisation de Signature Version 4A sans configuration supplémentaire.
Vous pouvez utiliser le protocole de signature AWS SigV4 pour créer une demande signée pour les demandes AWS d'API.
1. Création d’une requête canonique basée sur les détails de la requête.
1. Calcul d'une signature à l'aide de vos AWS informations d'identification.
1. Ajout de cette signature à la requête en tant qu’en-tête Autorisation.
AWS reproduit ensuite ce processus et vérifie la signature, en accordant ou en refusant l'accès en conséquence.
Pour savoir comment utiliser AWS SigV4 pour signer des demandes d'API, consultez[Demander des exemples de signature](reference_sigv-examples.md).
Le tableau suivant décrit les fonctions utilisées dans le processus de création d’une demande signée. Vous devez implémenter du code pour ces fonctions. Pour plus d'informations, consultez les [exemples de code dans le AWS SDKs](reference_sigv.md#reference_aws-signing-resources).
| Fonction | Description |
| --- | --- |
| `Lowercase()` | Convertit la chaîne en minuscules. |
| `Hex()` | Encodage en minuscules en base 16. |
| `SHA256Hash()` | Fonction de hachage cryptographique Secure Hash Algorithm (SHA, algorithme de hachage sécurisé). |
| `HMAC-SHA256()` | Calcule le HMAC en utilisant l' SHA256 algorithme avec la clé de signature fournie. Il s’agit de la Signature finale lorsque vous Signez avec Sigv4. |
| `ECDSA-Sign` | Signature ECDSA (Elliptic Curve Digital Signature Algorithm) calculée à l’aide de signatures asymétriques basées sur le chiffrement à clé publique-privée. |
| `KDF(K, Label, Context, L)` | [Un NIST SP800 -108 KDF en mode compteur utilisant la fonction PRF HMAC- telle SHA256 que définie dans le NIST SP 800-108r1.](https://doi.org/10.6028/NIST.SP.800-108r1-upd1) |
| `Oct2Int(byte[ ])` | Une fonction octet vers entier telle que décrite dans la norme ANSI X9.62. |
| `Trim()` | Supprimez tous les espaces blancs de début ou de fin. |
| `UriEncode()` | L'URI code chaque octet. UriEncode() doit appliquer les règles suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/reference_sigv-create-signed-request.html) Les UriEncode fonctions standard fournies par votre plateforme de développement peuvent ne pas fonctionner en raison de différences de mise en œuvre et de l'ambiguïté associée au niveau du sous-jacent RFCs. Nous vous recommandons d'écrire votre propre UriEncode fonction personnalisée pour garantir le bon fonctionnement de votre encodage. Pour voir un exemple de UriEncode fonction en Java, consultez la section [Utilitaires Java](https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-core/src/main/java/com/amazonaws/util/SdkHttpUtils.java#L66) sur le GitHub site Web. |
**Note**
Lorsque vous signez vos demandes, vous pouvez utiliser AWS SigV4 ou AWS SigV4a. La principale différence entre les deux est déterminée par la façon dont la signature est calculée. Avec SigV4a, l’ensemble de régions est inclus dans la chaîne à Signer, mais ne fait pas partie de l’étape de dérivation des informations d’identification.
## Requêtes de signature avec des informations d’identification de sécurité temporaires
Au lieu d'utiliser des informations d'identification à long terme pour signer une demande, vous pouvez utiliser des informations de sécurité temporaires fournies par AWS Security Token Service (AWS STS).
Lorsque vous utilisez des informations d’identification de sécurité temporaires, vous devez ajouter `X-Amz-Security-Token` à l’en-tête Autorisation ou l’inclure à la chaîne de requête pour contenir le jeton de session. Certains services nécessitent que vous ajoutiez `X-Amz-Security-Token` à la requête canonique. Pour les autres services, vous n’avez qu’à ajouter `X-Amz-Security-Token` à la fin, une fois que vous avez calculé la signature. Consultez la documentation de chacun Service AWS pour connaître les exigences spécifiques.
## Récapitulatif des étapes de signature
**Création d’une requête canonique**
Organisez le contenu de votre demande (hôte, action, en-têtes, etc.) dans un format standard canonique. La requête canonique est l’une des entrées utilisées pour créer la chaîne de connexion. Pour plus de détails sur la création de la requête canonique, consultez [Éléments d'une signature de demande d' AWS API](reference_sigv-signing-elements.md).
**Création d’un hachage de la requête canonique**
Hashez la requête canonique avec le même algorithme que celui que vous avez utilisé pour créer le hachage des données utiles. Le hachage de la requête canonique est une chaîne de caractères hexadécimaux en minuscules.
**Création d’une chaîne à signer**
Créez une chaîne de connexion avec la requête canonique et des informations supplémentaires telles que l’algorithme, la date de la requête, la portée des informations d’identification et le hachage de la requête canonique.
**Dérivation d’une clé de signature**
Utilisez la clé d’accès secrète pour dériver la clé utilisée pour signer la demande.
**Calcul de la signature**
Effectuez une opération de hachage à clé sur la chaîne à signer en utilisant la clé de signature dérivée comme clé de hachage.
**Ajout d’une signature à la requête**
Ajouter la signature calculée à un en-tête HTTP ou à la chaîne de requête de la requête.
## Création d’une requête canonique
Pour créer une requête canonique, concaténez les chaînes suivantes, séparées par des caractères de saut de ligne. Cela permet de garantir que la signature que vous calculez peut correspondre à la signature AWS calculée.
```
\n
\n
\n
\n
\n
```
+ *HTTPMethod*— La méthode HTTP, telle que `GET``PUT`,`HEAD`, et`DELETE`.
+ *CanonicalUri*— Version codée en URI de l'URI du composant du chemin absolu, en commençant par `/` celui qui suit le nom de domaine et jusqu'à la fin de la chaîne ou jusqu'au point d'interrogation (`?`) si vous avez des paramètres de chaîne de requête. Si le chemin d’accès absolu est vide, utilisez un caractère barre oblique (`/`). L’URI de l’exemple suivant, `/amzn-s3-demo-bucket/myphoto.jpg`, est le chemin absolu et vous n’encodez pas la `/` dans le chemin absolu :
```
http://s3.amazonaws.com/amzn-s3-demo-bucket/myphoto.jpg
```
+ *CanonicalQueryString*— Les paramètres de chaîne de requête codés en URI. Vous encodez individuellement chaque nom et chaque valeur par URI. Vous devez également trier les paramètres de la chaîne de requête canonique par ordre alphabétique par nom de clé. Le tri s'effectue après l'encodage. La chaîne de requête dans l'exemple d'URI suivant est la suivante :
```
http://s3.amazonaws.com/amzn-s3-demo-bucket?prefix=somePrefix&marker=someMarker&max-keys=2
```
La chaîne de requête canonique est la suivante (des sauts de ligne sont ajoutés à cet exemple pour faciliter la lecture) :
```
UriEncode("marker")+"="+UriEncode("someMarker")+"&"+
UriEncode("max-keys")+"="+UriEncode("20") + "&" +
UriEncode("prefix")+"="+UriEncode("somePrefix")
```
Lorsqu’une requête cible une sous-ressource, la valeur du paramètre de requête correspondant est une chaîne vide (`""`). Par exemple, l'URI suivant identifie la sous-ressource `ACL` sur le compartiment `amzn-s3-demo-bucket` :
```
http://s3.amazonaws.com/amzn-s3-demo-bucket?acl
```
Dans ce cas, CanonicalQueryString ce serait :
```
UriEncode("acl") + "=" + ""
```
Si l’URI ne contient pas de `?`, la requête ne contient aucune chaîne de requête et vous définissez la chaîne de requête canonique sur une chaîne vide (`""`). Vous devrez tout de même inclure le caractère de saut de ligne (`"\n"`).
+ *CanonicalHeaders*— Liste des en-têtes de requêtes avec leurs valeurs. Les paires de nom et de valeur d’en-tête individuelles sont séparées par le caractère de saut de ligne (`"\n"`). Voici un exemple de CanonicalHeader :
```
Lowercase()+":"+Trim()+"\n"
Lowercase()+":"+Trim()+"\n"
...
Lowercase()+":"+Trim()+"\n"
```
CanonicalHeaders la liste doit inclure les éléments suivants :
+ En-tête `host` HTTP.
+ Si l'`Content-Type`en-tête est présent dans la demande, vous devez l'ajouter à la *CanonicalHeaders* liste.
+ Les en-têtes `x-amz-*` que vous prévoyez d'inclure dans votre demande doivent également être ajoutés. Par exemple, si vous utilisez des informations d'identification de sécurité temporaires, vous devez inclure `x-amz-security-token` dans votre demande. Vous devez ajouter cet en-tête dans la liste des*CanonicalHeaders*.
+ Pour SigV4a, vous devez inclure un en-tête de jeu de régions qui spécifie l’ensemble des régions dans lesquelles la demande sera valide. L’en-tête `X-Amz-Region-Set` est spécifié sous forme de liste de valeurs séparées par des virgules. L’exemple suivant montre un en-tête de région qui permet d’effectuer une demande dans les régions us-east-1 et us-west-1.
`X-Amz-Region-Set=us-east-1,us-west-1 `
Vous pouvez utiliser des caractères génériques (\$1) dans les régions pour spécifier plusieurs régions. Dans l’exemple suivant, l’en-tête permet de faire une demande à la fois dans les régions us-west-1 et us-west-2.
`X-Amz-Region-Set=us-west-*`
**Note**
L’en-tête `x-amz-content-sha256` est obligatoire pour les requêtes AWS Amazon S3. Il fournit un hachage de la charge utile de la requête. S'il n'y a pas de charge utile, vous devez fournir le hachage d'une chaîne vide.
Chaque nom d'en-tête doit :
+ utiliser des caractères minuscules ;
+ apparaître par ordre alphabétique ;
+ être suivi de deux points (`:`).
Pour les valeurs, vous devez :
+ supprimer toutes les espaces de début ou de fin ;
+ convertir des espaces séquentielles en une espace unique ;
+ séparez les valeurs d'un en-tête à valeurs multiples par des virgules.
+ Vous devez inclure l'en-tête hôte (HTTP/1.1) ou l'en-tête :authority (HTTP/2), ainsi que tout en-tête `x-amz-*` dans la signature. Vous pouvez éventuellement inclure d'autres en-têtes standard dans la signature, tels que content-type.
Les fonctions `Lowercase()` et `Trim()` utilisées dans cet exemple sont décrites dans la section précédente.
L'exemple suivant est une chaîne `CanonicalHeaders`. Les noms d'en-tête sont en minuscules et sont triés.
```
host:s3.amazonaws.com
x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
x-amz-date:20130708T220855Z
```
**Note**
Aux fins du calcul d’une signature d’autorisation, seuls l’hôte et les en-têtes `x-amz-*` sont obligatoires. Toutefois, afin d’éviter toute altération des données, vous devez envisager d’inclure les en-têtes supplémentaires dans le calcul de la signature.
N'incluez pas hop-by-hop les en-têtes fréquemment modifiés lors du transit dans un système complexe. Cela inclut tous les en-têtes de transport volatils qui sont modifiés par les proxys, les équilibreurs de charge et les nœuds d’un système distribué, y compris `connection`, `x-amzn-trace-id`, `user-agent`, `keep-alive`, `transfer-encoding`, `TE`, `trailer`, `upgrade`, `proxy-authorization`, et `proxy-authenticate`.
+ *SignedHeaders*— Une liste triée par ordre alphabétique et séparée par des points-virgules de noms d'en-tête de demande en minuscules. Les en-têtes de demande de la liste sont les mêmes que ceux que vous avez inclus dans la chaîne `CanonicalHeaders`. Dans l'exemple précédent, la valeur de *SignedHeaders* serait la suivante :
```
host;x-amz-content-sha256;x-amz-date
```
+ *HashedPayload*— Chaîne créée à l'aide de la charge utile contenue dans le corps de la requête HTTP comme entrée d'une fonction de hachage. Cette chaîne utilise des caractères hexadécimaux minuscules.
```
Hex(SHA256Hash(>))
```
Si la requête ne contient pas de données utiles, vous calculez un hachage de la chaîne vide, comme lorsque vous récupérez un objet à l’aide d’une requête `GET`, il n’y a rien dans les données utiles.
```
Hex(SHA256Hash(""))
```
**Note**
Pour Amazon S3, incluez la chaîne littérale `UNSIGNED-PAYLOAD` lors de la création d’une requête canonique, et définissez la même valeur que celle de l’en-tête `x-amz-content-sha256` lors de l’envoi de la requête.
`Hex(SHA256Hash("UNSIGNED-PAYLOAD"))`
## Création d’un hachage de la requête canonique
Créez un hachage (digest) de la requête canonique avec le même algorithme que celui que vous avez utilisé pour créer le hachage de la charge utile. Le hachage de la requête canonique est une chaîne de caractères hexadécimaux en minuscules.
## Création d’une chaîne à signer
Pour créer une chaîne, concaténez les chaînes suivantes, séparées par des sauts de ligne. Ne terminez pas cette chaîne par un caractère de saut de ligne.
```
Algorithm \n
RequestDateTime \n
CredentialScope \n
HashedCanonicalRequest
```
+ *Algorithm*— Algorithme utilisé pour créer le hachage de la demande canonique.
+ SigV4 : utilisez `AWS4-HMAC-SHA256` pour spécifier l’algorithme de hachage `HMAC-SHA256`.
+ SigV4a : utilisez `AWS4-ECDSA-P256-SHA256` pour spécifier l’algorithme de hachage `ECDSA-P256-SHA-256`.
+ *RequestDateTime*— Date et heure utilisées dans le champ d'application des informations d'identification. Cette valeur est l'heure UTC actuelle au format ISO 8601 (par exemple, `20130524T000000Z`).
+ *CredentialScope*— L'étendue des informations d'identification, qui limite la signature résultante à la région et au service spécifiés.
+ SigV4 : les informations d’identification comprennent votre clé d’accès, la date au format `YYYYMMDD`, le code de région, le code de service et la chaîne de terminaison `aws4_request`, séparés par des barres obliques (/). Le code Région, le code de service et la chaîne de terminaison doivent utiliser des caractères minuscules. La chaîne a le format suivant : `YYYYMMDD/region/service/aws4_request`.
+ SigV4a : les informations d’identification comprennent la date au format `YYYYMMDD`, le nom du service et la chaîne de terminaison `aws4_request`, séparés par des barres obliques (/). Notez que la portée des informations d’identification n’inclut pas la région, car celle-ci est couverte dans un en-tête `X-Amz-Region-Set` distinct. La chaîne a le format suivant : `YYYYMMDD/service/aws4_request`.
+ *HashedCanonicalRequest*— Le hachage de la demande canonique, calculé à l'étape précédente.
L'exemple suivant est une chaîne de connexion.
```
"" + "\n" +
timeStampISO8601Format + "\n" +
+ "\n" +
Hex(())
```
## Dérivation d’une clé de signature
Pour dériver une clé de Signature, choisissez l’un des processus suivants afin de calculer une clé de Signature pour SigV4 ou SigV4a.
### Dérivation d’une clé de Signature pour SigV4
Pour obtenir une clé de signature pour SigV4, effectuez une succession d'opérations de hachage par clé (HMAC) à la date, à la région et au service de la demande, en utilisant votre clé d'accès AWS secrète comme clé pour l'opération de hachage initiale.
Pour chaque étape, appelez la fonction de hachage avec la clé et les données requises. Le résultat de chaque appel à la fonction de hachage devient l'entrée du prochain appel à la fonction de hachage.
L’exemple suivant montre comment vous obtenez la `SigningKey` utilisée dans la section suivante de cette procédure, en indiquant l’ordre dans lequel vos données sont concaténées et hachées. `HMAC-SHA256` est la fonction de hachage utilisée pour hacher les données comme indiqué.
```
DateKey = HMAC-SHA256("AWS4"+"", "")
DateRegionKey = HMAC-SHA256(, "")
DateRegionServiceKey = HMAC-SHA256(, "")
SigningKey = HMAC-SHA256(, "aws4_request")
```
**Entrée obligatoire**
+ `Key` : une chaîne contenant votre clé d’accès secrète.
+ `Date` : une chaîne contenant la date utilisée dans l’étendue des informations d’identification, au format *AAAAMMJJ*
+ `Region` : une chaîne contenant le code Région (par exemple, `us-east-1`).
Pour obtenir la liste des chaînes régionales, consultez la section [Points de terminaison régionaux](https://docs.aws.amazon.com//general/latest/gr/rande.html#regional-endpoints) dans les *Références générales AWS*.
+ `Service` : une chaîne contenant le code de service (par exemple, `ec2`).
+ Chaîne de connexion que vous avez créée à l'étape précédente.
**Pour dériver une clé de Signature pour SigV4**
1. Concaténez `"AWS4"` et la clé d’accès secrète. Appelez la fonction de hachage avec la chaîne concaténée en tant que clé et la chaîne de date en tant que données.
```
DateKey = hash("AWS4" + Key, Date)
```
1. Appelez la fonction de hachage en utilisant le résultat de l'appel précédent en tant que clé et la chaîne Région en tant que données.
```
DateRegionKey = hash(kDate, Region)
```
1. Appelez la fonction de hachage en utilisant le résultat de l'appel précédent en tant que clé et la chaîne de service en tant que données.
Le code de service est défini par le service. Vous pouvez utiliser [get-products](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/pricing/get-products.html) dans l’*interface de ligne de commande de tarification AWS * pour renvoyer le code de service d’un service.
```
DateRegionServiceKey = hash(kRegion, Service)
```
1. Appelez la fonction de hachage en utilisant le résultat de l'appel précédent en tant que clé et « aws4\$1request » en tant que données.
```
SigningKey = hash(kService, "aws4_request")
```
### Dérivation d’une clé de Signature pour SigV4a
Pour créer une clé de Signature pour SigV4a, utilisez le processus suivant afin de dériver une paire de clés à partir de la clé d’accès secrète. Pour un exemple d'implémentation de cette dérivation, voir l'[implémentation de l'authentification côté client dans la bibliothèque C99 AWS](https://github.com/awslabs/aws-c-auth/blob/e8360a65e0f3337d4ac827945e00c3b55a641a5f/source/key_derivation.c#L291.)
```
n = [NIST P-256 elliptic curve group order]
G = [NIST P-256 elliptic curve base point]
label = "AWS4-ECDSA-P256-SHA256"
akid = [AWS access key ID as a UTF8 string]
sk = [AWS secret access Key as a UTF8 Base64 string]
input_key = "AWS4A" || sk
count = 1
while (counter != 255) {
context = akid || counter // note: counter is one byte
key = KDF(input_key, label, context, 256)
c = Oct2Int(key)
if (c > n - 2) {
counter++
} else {
k = c + 1 // private key
Q = k * G // public key
}
}
if (c < 255) {
return [k, Q]
} else {
return FAILURE
}
```
## Calcul de la signature
Une fois la clé de signature dérivée, calculez la signature à ajouter à votre demande. Cette procédure varie en fonction de la version de signature que vous utilisez.
**Pour calculer une Signature SigV4**
1. Appelez la fonction de hachage en utilisant le résultat de l’appel précédent en tant que clé et la **chaîne de signature** en tant que données. Utilisez la clé de signature dérivée comme la clé de hachage pour cette opération. Le résultat est la signature sous forme de valeur binaire.
```
signature = hash(SigningKey, string-to-sign)
```
1. Convertissez la signature de la représentation binaire à la représentation hexadécimale, en caractères minuscules.
**Pour calculer une Signature SigV4a**
1. À l’aide de l’algorithme de signature numérique (ECDSA P-256), signez la **chaîne de signature** que vous avez créée à l’étape précédente. La clé utilisée pour cette signature est la clé asymétrique privée dérivée de la clé d’accès secrète telle que décrite ci-dessus.
```
signature = base16(ECDSA-Sign(k, string-to-sign))
```
1. Convertissez la signature de la représentation binaire à la représentation hexadécimale, en caractères minuscules.
## Ajout d’une signature à la requête
Ajoutez la signature calculée à votre demande.
**Example Exemple : en-tête d'autorisation**
**SigV4**
L'exemple suivant montre un `Authorization` en-tête pour l'`DescribeInstances`action utilisant AWS SigV4. Pour des raisons de lisibilité, cet exemple est formaté avec des sauts de ligne. Dans votre code, il doit s'agir d'une chaîne continue. Il n'y a pas de virgule entre l'algorithme et `Credential`. Toutefois, les autres éléments doivent être séparés par des virgules.
```
Authorization: AWS4-HMAC-SHA256
Credential=AKIAIOSFODNN7EXAMPLE/20220830/us-east-1/ec2/aws4_request,
SignedHeaders=host;x-amz-date,
Signature=calculated-signature
```
**SigV4a**
L'exemple suivant montre un en-tête d'autorisation pour l'`CreateBucket`action utilisant AWS SigV4a. Pour des raisons de lisibilité, cet exemple est formaté avec des sauts de ligne. Dans votre code, il doit s'agir d'une chaîne continue. Il n’y a pas de virgule entre l’algorithme et Informations d’identification. Toutefois, les autres éléments doivent être séparés par des virgules.
```
Authorization: AWS4-ECDSA-P256-SHA256
Credential=AKIAIOSFODNN7EXAMPLE/20220830/s3/aws4_request,
SignedHeaders=host;x-amz-date;x-amz-region-set,
Signature=calculated-signature
```
**Example Exemple : requête avec des paramètres d'authentification dans la chaîne de requête**
**SigV4**
L'exemple suivant montre une requête pour l'`DescribeInstances`action utilisant AWS SigV4 qui inclut les informations d'authentification. Pour des raisons de lisibilité, cet exemple est formaté avec des sauts de ligne et n’est pas code en URL. Dans votre code, la chaîne de requête doit être une chaîne continue codée en URL.
```
https://ec2.amazonaws.com/?
Action=DescribeInstances&
Version=2016-11-15&
X-Amz-Algorithm=AWS4-HMAC-SHA256&
X-Amz-Credential=AKIAIOSFODNN7EXAMPLE/20220830/us-east-1/ec2/aws4_request&
X-Amz-Date=20220830T123600Z&
X-Amz-SignedHeaders=host;x-amz-date&
X-Amz-Signature=calculated-signature
```
**SigV4a**
L’exemple suivant présente une requête pour l’action `CreateBucket` en utilisant AWS SigV4a qui inclut les informations d’authentification. Pour des raisons de lisibilité, cet exemple est formaté avec des sauts de ligne et n’est pas code en URL. Dans votre code, la chaîne de requête doit être une chaîne continue codée en URL.
```
https://ec2.amazonaws.com/?
Action=CreateBucket&
Version=2016-11-15&
X-Amz-Algorithm=AWS4-ECDSA-P256-SHA256&
X-Amz-Credential=AKIAIOSFODNN7EXAMPLE/20220830/s3/aws4_request&
X-Amz-Region-Set=us-west-1&
X-Amz-Date=20220830T123600Z&
X-Amz-SignedHeaders=host;x-amz-date;x-amz-region-set&
X-Amz-Signature=calculated-signature
```
# Demander des exemples de signature
Les exemples suivants de demandes de AWS signature montrent comment utiliser SigV4 pour signer des demandes envoyées sans le AWS SDK ni l'outil de ligne de AWS commande.
## Chargement d'Amazon S3 basé sur le navigateur avec HTTP POST
[Authentification des demandes : chargements basés sur le navigateur](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authentication-HTTPPOST.html) décrit la signature et les informations pertinentes qu'Amazon S3 utilise pour calculer la signature lors de la réception de la demande.
[Exemple : le téléchargement basé sur un navigateur à l'aide de HTTP POST ( AWS Using Signature Version 4)](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-post-example.html) fournit plus d'informations grâce à un exemple de politique POST et à un formulaire que vous pouvez utiliser pour télécharger un fichier. L'exemple de politique et les informations d'identification fictives vous montre le flux de travail ainsi que la signature et le hachage de la politique qui en résultent.
## Demandes authentifiées VPC Lattice
[Exemples pour les demandes authentifiées par Signature Version 4 (SigV4)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sigv4-authenticated-requests.html) fournit des exemples en Python et en Java qui vous montrent comment signer les demandes avec et sans intercepteurs personnalisés.
## Utilisation de Signature Version 4 avec Amazon Translate
[La traduction en direct dans le métavers](https://aws.amazon.com/blogs/spatial/live-translations-in-the-metaverse/) montre comment créer une application qui produit une solution de traduction en temps quasi réel. Cette solution de speech-to-speech traduction utilise le AWS SigV4 dans le codage des flux d'événements afin de produire des transcriptions en temps réel.
## Utilisation de Signature Version 4 avec Neptune
[Exemple : connexion à Neptune à l'aide de Python avec la signature Signature Version 4](https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-connecting-python.html) montre comment envoyer des demandes signées à Neptune à l'aide de Python. Cet exemple inclut des variations pour l'utilisation d'une clé d'accès ou d'informations d'identification temporaires.
## Signature des demandes HTTP à Amazon Glacier
[L'API Example Signature Calculation for Streaming](https://docs.aws.amazon.com/amazonglacier/latest/dev/amazon-glacier-signing-requests.html) vous explique en détail comment créer une signature pour Upload Archive (archive POST), l'une des deux solutions de streaming APIs sur Amazon Glacier.
## Envoi de demandes HTTP à Amazon SWF
[Envoyez des demandes HTTP à Amazon SWF](https://docs.aws.amazon.com/amazonswf/latest/developerguide/UsingJSON-swf.html#HTTPHeader) présente le contenu de l'en-tête d'une demande JSON envoyée à Amazon SWF.
## Calcul des signatures pour APIs le streaming sur Amazon OpenSearch Service
[La signature d'une demande de recherche Amazon OpenSearch Service avec le AWS SDK pour PHP version](https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/service_es-data-plane.html) 3 inclut un exemple d'envoi de requêtes HTTP signées à OpenSearch Amazon Service.
## Exemples de projets dans le référentiel AWS d'échantillons
Les exemples de projets suivants montrent comment signer des demandes pour envoyer des requêtes d'API Rest à AWS des services utilisant des langages courants tels que Python, Node.js, Java, C\$1, Go et Rust.
### Projets de Signature Version 4a
Le projet [sigv4-signing-examples fournit des exemples](https://github.com/aws-samples/sigv4-signing-examples) de la façon de signer des requêtes avec Sigv4 pour envoyer des requêtes d'API Rest avec des langages Services AWS courants tels que Python, Node.js, Java, C\$1, Go et Rust.
Le a-signing-examples projet [sigv4](https://github.com/aws-samples/sigv4a-signing-examples) fournit des exemples de signature de demandes d'API multirégionales, par exemple des [points d'accès multirégionaux dans Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html).
### Publier sur AWS IoT Core
[Le code Python pour publier à AWS IoT Core l'aide HTTPs du protocole](https://github.com/aws-samples/aws-iot-core-python-node-sigv4-https) fournit des conseils sur la façon de publier des messages à AWS IoT Core l'aide du protocole HTTPS et de l'authentification AWS Sigv4. Il possède deux implémentations de référence, l'une en Python et l'autre en NodeJs.
[L'application .Net Framework pour publier à AWS IoT Core l'aide HTTPs du protocole](https://github.com/aws-samples/aws-iot-core-http-sigv4-dotnet-app) fournit des conseils sur la façon de publier des messages à AWS IoT Core l'aide du protocole HTTPS et de l'authentification AWS SigV4. Ce projet inclut également une implémentation correspondant à .NET Core.
# Résoudre les problèmes de signature de la version 4 de Signature pour les demandes AWS d'API
**Important**
À moins que vous n'utilisiez la CLI AWS SDKs ou, vous devez écrire du code pour calculer les signatures qui fournissent des informations d'authentification dans vos demandes. Le calcul de la signature SigV4 peut être une tâche complexe, et nous vous recommandons d'utiliser la CLI AWS SDKs or dans la mesure du possible.
Lorsque vous développez du code qui crée une demande signée, vous pouvez recevoir le protocole HTTP 403 `SignatureDoesNotMatch` de Services AWS. Ces erreurs signifient que la valeur de signature de votre requête HTTP AWS ne correspond pas à la signature Service AWS calculée. Les erreurs HTTP 401 `Unauthorized` sont renvoyées lorsque les autorisations ne permettent pas à l'appelant d'effectuer la requête.
Les demandes d'API peuvent renvoyer une erreur si :
+ La demande d'API n'est pas signée et elle utilise l'authentification IAM.
+ Les informations d'identification IAM utilisées pour signer la demande sont incorrectes ou ne sont pas autorisées à invoquer l'API.
+ La signature de la demande d'API signée ne correspond pas à la signature calculée par le service AWS .
+ L'en-tête de demande d'API est incorrect.
**Note**
Mettez à jour votre protocole de AWS signature de la version 2 (SigV2) à la version AWS Signature 4 (SigV4) avant d'explorer d'autres solutions aux erreurs. Les services, tels qu’Amazon S3, et les régions ne prennent plus en charge la signature SigV2.
**Topics**
+ [
## Erreurs d'informations d'identification
](#signature-v4-troubleshooting-credential)
+ [
## Erreurs de requête canonique et de chaîne de signature
](#signature-v4-troubleshooting-canonical-errors)
+ [
## Erreurs d’étendue des informations d'identification
](#signature-v4-troubleshooting-credential-scope)
+ [
## Erreurs de signature de clé
](#signature-v4-troubleshooting-key-signing)
## Erreurs d'informations d'identification
Assurez-vous que la demande d'API est signée avec SigV4. Si la demande d'API n'est pas signée, il se peut que vous receviez le message d'erreur : `Missing Authentication Token`. [Ajoutez la signature manquante](https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-request.html#add-signature-to-request) et renvoyez la demande.
Vérifiez que les informations d'identification de la clé d'accès et de la clé secrète sont correctes. Si la clé d'accès est incorrecte, le message d'erreur suivant peut s'afficher : `Unauthorized`. Assurez-vous que l'entité utilisée pour signer la demande est autorisée à effectuer cette dernière. Pour en savoir plus, consultez [Résolution des problèmes liés aux messages d’erreur d’accès rejeté](troubleshoot_access-denied.md).
## Erreurs de requête canonique et de chaîne de signature
Si le calcul de la requête canonique est incorrect dans [Création d’un hachage de la requête canonique](reference_sigv-create-signed-request.md#create-canonical-request-hash) ou [Création d’une chaîne à signer](reference_sigv-create-signed-request.md#create-string-to-sign), l'étape de vérification de la signature effectuée par le service échoue avec le message d'erreur :
```
The request signature we calculated does not match the signature you provided
```
Lorsque le AWS service reçoit une demande signée, il recalcule la signature. S'il existe des différences entre les valeurs, les signatures ne correspondent pas. Comparez la requête canonique et la chaîne à votre demande signée avec la valeur du message d'erreur. Modifiez le processus de signature en cas de différence.
**Note**
Vous pouvez également vérifier que vous n'avez pas envoyé la requête via un proxy qui modifie les en-têtes ou la requête.
**Example Exemple de requête canonique**
```
GET -------- HTTP method
/ -------- Path. For API stage endpoint, it should be /{stage-name}/{resource-path}
-------- Query string key-value pair. Leave it blank if the request doesn't have a query string.
content-type:application/json -------- Header key-value pair. One header per line.
host:0123456789.execute-api.us-east-1.amazonaws.com -------- Host and x-amz-date are required headers for all signed requests.
x-amz-date:20220806T024003Z
content-type;host;x-amz-date -------- A list of signed headers
d167e99c53f15b0c105101d468ae35a3dc9187839ca081095e340f3649a04501 -------- Hash of the payload
```
Pour vérifier que la clé secrète correspond à l'ID de la clé d'accès, vous pouvez les tester avec une implémentation fonctionnelle connue. Par exemple, utilisez un AWS SDK ou la AWS CLI pour envoyer une demande à AWS.
### En-tête de la demande d'API
Lorsque l’en-tête d’autorisation est vide, que la clé ou la signature des informations d’identification est manquante ou incorrecte, que l’en-tête ne commence pas par un nom d’algorithme ou que les paires clé-valeur n’incluent pas de signe égal, vous recevez l’une des erreurs suivantes :
+ L’en-tête d’autorisation ne peut pas être vide.
+ L’en-tête d’autorisation nécessite le paramètre « Informations d’identification ».
+ L’en-tête d’autorisation nécessite le paramètre « Signature ».
+ La signature contient une paire clé=valeur non valide (signe égal manquant) dans l’en-tête d’autorisation.
Assurez-vous que l’en-tête d’autorisation SigV4 que vous avez ajouté dans [Calcul de la signature](reference_sigv-create-signed-request.md#calculate-signature) comprend la clé d’informations d’identification correcte, ainsi que la date de la requête à l’aide de HTTP Date ou de l’en-tête `x-amz-date`.
Si vous avez reçu une IncompleteSignatureException erreur et que la construction de la signature est correcte, vous pouvez vérifier que l'en-tête d'autorisation n'a pas été modifié pendant le transfert vers le en Service AWS calculant un hachage SHA-256 et un codage B64 de l'en-tête d'autorisation dans votre demande côté client.
1. Obtenez l’[en-tête d’autorisation](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) que vous avez envoyé dans la requête. Votre en-tête d’autorisation ressemble à l’exemple suivant :
```
Authorization: AWS4-HMAC-SHA256
Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,
SignedHeaders=host;range;x-amz-date,
Signature=example-generated-signature
```
1. Calculez un hachage SHA-256 de l’en-tête d’autorisation.
```
hashSHA256(rawAuthorizationHeader) = hashedAuthorizationHeader
```
1. Codez l’en-tête d’autorisation haché au format Base64.
```
base64(hashedAuthorizationHeader) = encodedHashedAuthorizationHeader
```
1. Comparez la chaîne hachée et codée que vous venez de calculer à la chaîne que vous avez reçue dans votre message d’erreur. Votre message d’erreur doit ressembler à l’exemple suivant :
```
com.amazon.coral.service#IncompleteSignatureException:
The signature contains an in-valid key=value pair (missing equal-sign)
in Authorization header (hashed with SHA-256 and encoded with Base64):
'9c574f83b4b950926da4a99c2b43418b3db8d97d571b5e18dd0e4f3c3ed1ed2c'.
```
+ Si les deux hachages diffèrent, c’est qu’une partie de l’en-tête d’autorisation a été modifiée en transit Ce changement peut être dû au fait que les gestionnaires de votre réseau ou de votre client attachent des en-têtes signés ou modifient l’en-tête d’autorisation d’une manière ou d’une autre.
+ Si les deux hachages correspondent, l'en-tête d'autorisation que vous avez envoyé dans la demande correspond à celui AWS reçu. Consultez le message d’erreur que vous avez reçu pour déterminer si le problème est dû à des informations d’identification ou à une signature incorrectes. Ces erreurs sont traitées dans les autres sections de cette page.
## Erreurs d’étendue des informations d'identification
Le champ d'application des informations d'identification dans [Création d’une chaîne à signer](reference_sigv-create-signed-request.md#create-string-to-sign) limite une signature à une date, une région et un service spécifiques. Cette chaîne présente le format suivant :
```
YYYYMMDD/region/service/aws4_request
```
**Note**
Si vous utilisez SigV4a, la région n'est pas incluse dans le champ d'application des informations d'identification.
**Date**
Si l'étendue des informations d'identification ne spécifie pas la même date que l'en-tête x-amz-date, l'étape de vérification de la signature échoue avec le message d'erreur suivant :
```
Date in Credential scope does not match YYYYMMDD from ISO-8601 version of date from HTTP
```
Si la requête indique une date future, l'étape de vérification de la signature échoue avec le message d'erreur suivant :
```
Signature not yet current: date is still later than date
```
Si la requête a expiré, l'étape de vérification de la signature échoue avec le message d'erreur suivant :
```
Signature expired: date is now earlier than date
```
**Région**
Si l'étendue des informations d'identification ne spécifie pas la même Région que la requête, l'étape de vérification de la signature échoue avec le message d'erreur suivant :
```
Credential should be scoped to a valid Region, not region-code
```
**Service**
Si l'étendue des informations d'identification ne spécifie pas le même service que l'en-tête host, l'étape de vérification de la signature échoue avec le message d'erreur suivant :
```
Credential should be scoped to correct service: 'service'
```
**Chaîne de terminaison**
Si l'étendue des informations d'identification ne se termine pas par aws4\$1request, l'étape de vérification de la signature échoue avec le message d'erreur suivant :
```
Credential should be scoped with a valid terminator: 'aws4_request'
```
## Erreurs de signature de clé
Les erreurs causées par une dérivation incorrecte de la clé de signature ou une utilisation inappropriée du chiffrement sont plus difficiles à résoudre. Après avoir vérifié que la chaîne canonique et la chaîne à signer sont correctes, vous pouvez également vérifier l'existence de l'un des problèmes suivants :
+ La clé d'accès secrète ne correspond pas à l'ID de clé d'accès que vous avez spécifiée.
+ Votre code de dérivation de clé pose problème.
Pour vérifier que la clé secrète correspond à l'ID de la clé d'accès, vous pouvez les tester avec une implémentation fonctionnelle connue. Par exemple, utilisez un AWS SDK ou le AWS CLI pour faire une demande à AWS. Pour obtenir des exemples, consultez [Demander des exemples de signature](reference_sigv-examples.md)