

# AWS Signature Version 4 para solicitudes de API
<a name="reference_sigv"></a>

**importante**  
Si utiliza un SDK de AWS (consulte [Sample Code and Libraries](https://aws.amazon.com/developer/)) o la herramienta AWS Command Line Interface (AWS CLI) para enviar solicitudes de API a AWS, puede omitir el proceso de firma porque los clientes del SDK y la CLI autentican sus solicitudes mediante las claves de acceso que les proporciona. A menos que tenga una razón específica para no hacerlo, le recomendamos que utilice siempre un SDK o la CLI.  
En las regiones en las que se admiten varias versiones de firma, las solicitudes de firma manual hacen referencia a que debe especificar qué versión de firma se utiliza. Cuando envía solicitudes a puntos de acceso de varias regiones, los SDK y la CLI cambian de forma automática a Signature Version 4A sin configuración adicional.

La información de autenticación que envíe en una solicitud debe incluir una firma. AWS Signature Version 4 (SigV4) es el protocolo de firma de AWS para agregar información de autenticación a solicitudes de API de AWS.

No se utiliza su clave de acceso secreta para firmar las solicitudes de API. En su lugar, se utiliza el proceso de firma de SigV4. Firmar solicitudes implica:

1. Crear una solicitud canónica en función de los detalles de la solicitud.

1. Calcular una firma con sus credenciales de AWS.

1. Agregar esta firma a la solicitud como encabezado de autorización.

Luego, AWS replica este proceso y verifica la firma, concediendo o denegando el acceso en consecuencia.

El SigV4 simétrico requiere que obtenga una clave que esté destinada a un solo servicio de AWS, en una sola región de AWS, en un día determinado. Esto hace que la clave y la firma calculada sean diferentes para cada región, lo que significa que debes saber a qué región está destinada la firma.

La versión 4 de la firma asimétrica (SigV4a) es una extensión que permite firmar con un nuevo algoritmo y generar firmas individuales que se puedan verificar en más de una región de AWS. Con SigV4a, puede firmar una solicitud para varias regiones, con un enrutamiento y conmutación por error sin problemas entre regiones. Cuando utiliza el SDK de AWS o la AWS CLI para invocar una funcionalidad que requiere la firma en varias regiones, el tipo de firma se cambia automáticamente para usar SigV4a. Para obtener más información, consulte [Cómo funciona AWS SigV4a](#how-sigv4a-works).

## Cómo funciona AWS SigV4
<a name="how-aws-signing-works"></a>

Los siguientes pasos describen el proceso general de cálculo de una firma con SigV4:

1. La **cadena para firmar** depende del tipo de solicitud. Por ejemplo, cuando utiliza el encabezado de autorización HTTP o los parámetros de consulta para la autenticación, utiliza una combinación de elementos de solicitud a fin de crear la cadena para firmar. Para una solicitud HTTP POST, la política `POST` de la solicitud es la cadena que firma.

1. La **clave de firma** consiste en una serie de cálculos en los que el resultado de cada paso se incorpora al siguiente. El último paso es la clave de firma.

1. Cuando un servicio de AWS recibe una solicitud autenticada, vuelve a crear la **firma** con la información de autenticación incluida en la solicitud. Si las firmas coinciden, el servicio procesa la solicitud. De lo contrario, se rechaza la solicitud.

Para obtener más información, consulte [Elementos de una firma de solicitud a la API de AWS](reference_sigv-signing-elements.md).

## Cómo funciona AWS SigV4a
<a name="how-sigv4a-works"></a>

SigV4a utiliza firmas asimétricas basadas en la criptografía de clave público-privada. SigV4a pasa por un proceso de derivación de credenciales de alcance similar al de SigV4, con la diferencia de que Sigv4a utiliza la misma clave para firmar todas las solicitudes sin necesidad de derivar una clave de firma distinta en función de la fecha, el servicio y la región. Se puede obtener un par de claves del [algoritmo de firma digital de curva elíptica](https://csrc.nist.gov/glossary/term/ecdsa) (ECDSA) a partir de su clave de acceso secreta de AWS existente.

El sistema utiliza criptografía asimétrica para verificar las firmas multirregionales, por lo que AWS solo necesita almacenar las claves públicas. Las claves públicas no son secretas y no se pueden utilizar para firmar solicitudes. Las firmas asimétricas son obligatorias para las solicitudes de API multirregionales, por ejemplo, con puntos de acceso multirregionales Amazon S3.

Los siguientes pasos describen el proceso general de cálculo de una firma con SigV4a:

1. La **cadena para firmar** depende del tipo de solicitud. Por ejemplo, cuando utiliza el encabezado de autorización HTTP o los parámetros de consulta para la autenticación, utiliza una combinación de elementos de solicitud a fin de crear la cadena para firmar. Para una solicitud HTTP POST, la política `POST` de la solicitud es la cadena que firma.

1. La **clave de firma** deriva de una clave de acceso secreta de AWS mediante una serie de cálculos en los que el resultado de cada paso se incorpora al siguiente. El paso final produce el par de claves.

1. Cuando un servicio de AWS recibe una solicitud firmada con Sigv4a, AWS verifica la firma utilizando solo la mitad pública del par de claves. Si la firma es válida, la solicitud se autentica y el servicio procesa la solicitud. Se rechazan las solicitudes con firmas no válidas.

Para obtener más información sobre SigV4a para solicitudes de API multirregionales, consulte el proyecto [sigv4a-signing-examples](https://github.com/aws-samples/sigv4a-signing-examples) en GitHub.

## Cuándo firmar las solicitudes
<a name="when-do-you-need-to-sign"></a>

Cuando escribe código personalizado que envía solicitudes de la API a AWS, debe incluir código que firme las solicitudes. Puede escribir código personalizado porque:
+ Si trabaja con un lenguaje de programación para el que no hay un AWS SDK disponible.
+ Necesita control total sobre el modo en que se envían las solicitudes a AWS.

Mientras que las solicitudes de API autentican el acceso con AWS SigV4, los SDK de AWS y la AWS CLI también autentican sus solicitudes mediante las claves de acceso que proporciona. Para obtener más información sobre la autenticación con los SDK de AWS y la AWS CLI, consulte [Recursos adicionales](#reference_aws-signing-resources).

## ¿Por qué se firman las solicitudes?
<a name="why-requests-are-signed"></a>

El proceso de firma ayuda a proteger las solicitudes de las siguientes formas:
+ **Comprobación de la identidad del solicitante**

  Las solicitudes autenticadas requieren una firma que se crea con las claves de acceso (ID de clave de acceso, clave de acceso secreta). Si utiliza credenciales de seguridad temporales, los cálculos de la firma también requieren un token de seguridad. Para obtener más información, consulte [Acceso programático de credenciales de seguridad de AWS](security-creds-programmatic-access.md).
+ **Protección de los datos en tránsito**

  Para evitar que se altere una solicitud mientras están en tránsito, algunos de sus elementos se utilizan para calcular un resumen (hash) de la solicitud y el valor hash resultante se incluye como parte de la solicitud. Cuando un Servicio de AWS recibe la solicitud, utiliza la misma información para calcular un hash y lo compara con el valor de hash contenido en su solicitud. Si los valores no coinciden, AWS deniega la solicitud.
+ **Protección contra posibles ataques de reproducción**

  En la mayoría de los casos, una solicitud debe llegar a AWS en el plazo de cinco minutos a partir de la marca de tiempo que figura en ella. De lo contrario, AWS deniega la solicitud.

AWS SigV4 se puede expresar en el encabezado de autorización HTTP o como una cadena de consulta en la URL. Para obtener más información, consulte [Métodos de autenticación](reference_sigv-authentication-methods.md).

## Recursos adicionales
<a name="reference_aws-signing-resources"></a>
+ A fin de obtener más información sobre el proceso de firma de SigV4 para diferentes servicios, consulte [Ejemplos de firmas de solicitudes](reference_sigv-examples.md).
+ A fin de configurar las credenciales para el acceso programático a la CLI de AWS, consulte [Authentication and access credentials](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*.
+ Los SDK de AWS incluyen código fuente en GitHub para firmar las solicitudes de la API de AWS. Para obtener ejemplos de código, consulte [Proyectos de ejemplo en AWS repositorio de muestras](reference_sigv-examples.md#signature-v4-examples-sdk).
  + AWS SDK para .NET: [AWS4Signer.cs](https://github.com/aws/aws-sdk-net/blob/master/sdk/src/Core/Amazon.Runtime/Internal/Auth/AWS4Signer.cs)
  + AWS SDK para 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 para Go: [sigv4.go](https://github.com/aws/smithy-go/blob/a4c9efcda6aa54c75d1a130d1320a2709eebf51d/aws-http-auth/sigv4/sigv4.go)
  + AWS SDK para 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 para JavaScript: [signatura-v4](https://github.com/smithy-lang/smithy-typescript/tree/main/packages/signature-v4)
  + AWS SDK para PHP: [SignatureV4.php](https://github.com/aws/aws-sdk-php/blob/master/src/Signature/SignatureV4.php)
  + AWS SDK para Python (Boto): [signers.py](https://github.com/boto/botocore/blob/develop/botocore/signers.py)
  + AWS SDK para Ruby: [signer.rb](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sigv4/lib/aws-sigv4/signer.rb)

# Elementos de una firma de solicitud a la API de AWS
<a name="reference_sigv-signing-elements"></a>

**importante**  
A menos que utilice la CLI o los SDK de AWS, debe escribir código para calcular las firmas que brindan información de autenticación en sus solicitudes. El cálculo de firmas en AWS Signature Version 4 puede ser una tarea compleja, por lo que le recomendamos que utilice la CLI o los SDK de AWS siempre que sea posible.

Cada solicitud HTTP/HTTPS que utiliza la firma Signature Version 4 debe contener estos elementos.

**Topics**
+ [Especificación de punto de enlace](#endpoint-specification)
+ [Action](#action)
+ [Parámetros de acciones](#parameters)
+ [Date](#date)
+ [Información de autenticación](#authentication)

## Especificación de punto de enlace
<a name="endpoint-specification"></a>

Especifica el nombre de DNS del punto de conexión al que se envía la solicitud. Este nombre suele contener el código de servicio y la región. Por ejemplo, el punto de conexión de Amazon DynamoDB en la región `us-east-1` es `dynamodb.us-east-1.amazonaws.com`.

Para las solicitudes HTTP/1.1, debe incluir el encabezado `Host`. Para solicitudes HTTP/2, puede incluir el encabezado `:authority` o el encabezado `Host`. Utilice únicamente el encabezado `:authority` de conformidad con la especificación HTTP/2. No todos los servicios son compatibles con las solicitudes HTTP/2.

Para conocer los puntos de conexión admitidos por cada servicio, consulte los [Puntos de conexión y cuotas del servicio](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) en la *Referencia general de AWS*.

## Action
<a name="action"></a>

Especifica una acción de la API para el servicio. Por ejemplo, la acción de DynamoDB `CreateTable` o la acción de Amazon EC2 `DescribeInstances`.

Para ver las acciones admitidas por cada servicio, consulte la [Referencia de autorización del servicio](https://docs.aws.amazon.com//service-authorization/latest/reference/reference.html).

## Parámetros de acciones
<a name="parameters"></a>

Especifica los parámetros de la acción especificada en la solicitud. Cada acción de la API de AWS tiene un conjunto de parámetros obligatorios y opcionales. La versión de la API suele ser un parámetro obligatorio.

Para ver los parámetros admitidos por una acción de la API, consulte la Referencia de la API del servicio.

## Date
<a name="date"></a>

Especifica la fecha y la hora de la solicitud. Incluir la fecha y la hora en una solicitud ayuda a impedir que terceros intercepten su solicitud y vuelvan a enviarla posteriormente. La fecha que especifica en el alcance de credencial debe coincidir con la fecha de su solicitud.

La marca de tiempo debe estar en UTC y en el siguiente formato ISO 8601: *AAAAMMDD*T*HHMMSS*Z. Por ejemplo, `20220830T123600Z`. No incluya milisegundos en la marca de tiempo.

Puede utilizar un encabezado `date` o `x-amz-date`, o puede incluir `x-amz-date` como parámetro de consulta. Si no podemos encontrar un encabezado `x-amz-date`, buscamos un encabezado `date`.

## Información de autenticación
<a name="authentication"></a>

Cada solicitud que envíe debe incluir la siguiente información. AWS usa esta información para garantizar la validez y autenticidad de la solicitud.
+ Algoritmo: el algoritmo hash que está utilizando como parte del proceso de firma. 
  + SigV4: use `AWS4-HMAC-SHA256` para especificar Signature Version 4 con el algoritmo de hash `HMAC-SHA256`. 
  + SigV4a: use `AWS4-ECDSA-P256-SHA256` para especificar el algoritmo hash `ECDSA-P256-SHA-256`.
+ Credencial: una cadena que se forma concatenando sus componentes de ID de clave de acceso y ámbito de credenciales.
  + SigV4: el ámbito de la credencial incluye su clave de acceso, la fecha en formato *DDMMAAAA*, el código de región, el código de servicio y la cadena de terminación `aws4_request`, separados por barras diagonales (/). El código de región, el código de servicio y la cadena de terminación deben utilizar caracteres en minúscula.

    ```
    AKIAIOSFODNN7EXAMPLE/YYYYMMDD/region/service/aws4_request
    ```
  + SigV4a: el ámbito de la credencial incluye la fecha con el formato DDMMAAAA, el nombre del servicio y la cadena de terminación `aws4_request`, separados por barras diagonales (/). Tenga en cuenta que el ámbito de las credenciales no incluye la región, ya que la región está cubierta en un encabezado `X-Amz-Region-Set` independiente.

    ```
    AKIAIOSFODNN7EXAMPLE/YYYYMMDD/service/aws4_request
    ```
+ Encabezados firmados: los encabezados HTTP que se incluirán en la firma, separados por punto y coma (;). Por ejemplo, `host;x-amz-date`.

  En el caso de SigV4a, debe incluir un encabezado de conjunto de regiones que especifique el conjunto de regiones en las que será válida la solicitud. El encabezado `X-Amz-Region-Set` se especifica como una lista de valores separados por comas. En el siguiente ejemplo, se muestra un encabezado de región que permite realizar una solicitud tanto en las regiones us-east-1 como us-west-1.

  ```
  X-Amz-Region-Set=us-east-1,us-west-1
  ```

  Puede utilizar comodines (\$1) en las regiones para especificar varias regiones. En el siguiente ejemplo, el encabezado permite realizar una solicitud tanto en us-west-1 como en us-west-2.

  ```
  X-Amz-Region-Set=us-west-*
  ```
+ Firma: una cadena codificada en formato hexadecimal que representa la firma calculada. Debe calcular la firma utilizando el algoritmo especificado en el parámetro `Algorithm`. 

Para obtener más información, consulte [Métodos de autenticación](reference_sigv-authentication-methods.md)

# Métodos de autenticación
<a name="reference_sigv-authentication-methods"></a>

**importante**  
A menos que utilice la CLI o los SDK de AWS, debe escribir código para calcular las firmas que brindan información de autenticación en sus solicitudes. El cálculo de firmas en AWS Signature Version 4 puede ser una tarea compleja, por lo que le recomendamos que utilice la CLI o los SDK de AWS siempre que sea posible.

Puede expresar la información de autenticación mediante uno de los siguientes métodos.

## Encabezado de autorización HTTP
<a name="aws-signing-authentication-methods-http"></a>

El encabezado de `Authorization` HTTP es el método más común para autenticar una solicitud. Todas las operaciones de la API de REST (excepto las cargas basadas en el navegador mediante solicitudes `POST`) requieren este encabezado.

Los siguientes ejemplos muestran el valor del encabezado `Authorization` de SigV4 y SigV4a. Se agregan saltos de línea a este ejemplo para facilitar la lectura. En su código, el encabezado debe ser una cadena continua. No hay comas entre el algoritmo y la credencial, pero los demás elementos deben estar separados por comas.

**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
```

En la siguiente tabla, se describen los distintos componentes del valor del encabezado de autorización del ejemplo anterior:


| Componente | Descripción | 
| --- | --- | 
|  Autorización  | El algoritmo que se utilizó para calcular la firma. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/reference_sigv-authentication-methods.html)  | 
|  Credential  |  El ID de clave de acceso y la información sobre el alcance. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) Donde el valor <date> se especifica con el formato DDMMAAAA. El valor <aws-service> es S3 al enviar una solicitud a Amazon S3.  | 
|  SignedHeaders  |   Una lista de encabezados de solicitud separados por punto y coma que utilizó para calcular la firma. La lista solo incluye los nombres de los encabezados y estos nombres deben estar en minúsculas. Por ejemplo: .: `host;range;x-amz-date` En el caso de SigV4a, debe incluir un encabezado de conjunto de regiones que especifique el conjunto de regiones en las que será válida la solicitud. El encabezado X-Amz-Region-Set se especifica como una lista de valores separados por comas.  | 
|  Signature  |  La firma de 256 bits expresada en 64 caracteres hexadecimales en minúsculas. Por ejemplo:`fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024` Tenga en cuenta que los cálculos de la firma varían según la opción que elija para transferir la carga.  | 

## Parámetros de cadenas de consulta
<a name="aws-signing-authentication-methods-query"></a>

Puede utilizar una cadena de consulta para expresar una solicitud en su totalidad en una URL. En este caso, utiliza los parámetros de consulta para proporcionar la información de la solicitud, incluida la información de autenticación. Dado que la firma de la solicitud forma parte de la dirección URL, este tipo de URL suele denominarse como URL prefirmada. Puede utilizar URL prefirmadas para incrustar enlaces en los que se puede hacer clic en HTML, que pueden tener una validez de hasta siete días. Para obtener más información, consulte [Autenticación de solicitudes: uso de parámetros de consulta (AWS Signature Version 4)](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html) en la *Referencia de la API de Amazon S3*.

Los siguientes ejemplos muestran las URL prefirmadas de SigV4 y SigV4a. Se agregan saltos de línea a este ejemplo para facilitar la lectura:

**Example SigV4**  

```
https://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ?
X-Amz-Algorithm=AWS4-HMAC-SHA256 &
X-Amz-Credential=<your-access-key-id>/20130721/<region>/s3/aws4_request &
X-Amz-Date=20130721T201207Z &
X-Amz-Expires=86400 &
X-Amz-SignedHeaders=host &X-Amz-Signature=<signature-value>
```

**Example SigV4a**  

```
http://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ?
X-Amz-Algorithm=AWS4-ECDSA-P256-SHA256 &
X-Amz-Credential=<your-access-key-id>/20240721/s3/aws4_request &
X-amz-Region-Set=<regionset> &
X-Amz-Date=20240721T201207Z &
X-Amz-Expires=86400 &
X-Amz-SignedHeaders=host;x-amz-region-set &
X-Amz-Signature=<signature-value>
```

**nota**  
El valor `X-Amz-Credential` de la URL muestra el carácter “/” solo para facilitar la lectura. En la práctica, debe codificarse como %2F. Por ejemplo:  
`&X-Amz-Credential=<your-access-key-id>%2F20130721%2Fus-east-1%2Fs3%2Faws4_request`

En la siguiente tabla, se describen los parámetros de consulta de la URL que proporcionan información de autenticación.


| Nombre del parámetro de la cadena de consulta | Descripción | 
| --- | --- | 
|  X-Amz-Algorithm  |  La versión de la firma de AWS y el algoritmo que utilizó para calcular la firma. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/reference_sigv-authentication-methods.html)  | 
|  X-Amz-Credential  |  Además del ID de clave de acceso, este parámetro también proporciona el alcance para el que es válida la firma. Este valor debe coincidir con el alcance que se utiliza en los cálculos de firmas, como se explica en la siguiente sección. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) Para obtener una lista de las cadenas regionales de AWS, consulte [Puntos de conexión regionales](https://docs.aws.amazon.com//general/latest/gr/rande.html#regional-endpoints) en la *Referencia general de AWS*.  | 
|  X-Amz-Region-Set  |  El conjunto de regiones en las que será válida la solicitud. El encabezado x-amz-region-set se especifica como una lista de valores separados por comas.  | 
|  X-Amz-Date  |  El formato de fecha y hora debe seguir la norma ISO 8601 y debe tener el formato `yyyyMMddTHHmmssZ`. Por ejemplo, si la fecha y la hora son “08/01/2016 15:32:41.982-700”, primero se deben convertir a UTC (hora universal coordinada) y, a continuación, se deben enviar como “20160801T223241Z”.  | 
|  X-Amz-Expires  |  Proporciona el periodo, en segundos, durante el que es válida la URL prefirmada generada. Por ejemplo, 86 400 (24 horas). Este valor es un entero. El valor mínimo que puede establecer es 1 y el máximo es 604 800 (siete días). Una URL prefirmada puede ser válida durante un máximo de siete días porque la clave de firma que utiliza para calcular la firma es válida durante un máximo de siete días.  | 
|  X-Amz-SignedHeaders  |  Muestra los encabezados que utilizó para calcular la firma. Los siguientes encabezados son obligatorios para los cálculos de firmas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) Para mayor seguridad, debe firmar todos los encabezados de solicitud que planea incluir en su solicitud.  | 
|  X-Amz-Signature  |  Proporciona la firma para autenticar la solicitud. Esta firma debe coincidir con la firma que calcula el servicio; de lo contrario, el servicio deniega la solicitud. Por ejemplo: ., `733255ef022bec3f2a8701cd61d4b371f3f28c9f193a1f02279211d48d5193d7` Los cálculos de firmas se describen en la siguiente sección.  | 
|  X-Amz-Security-Token  |  Parámetro de credenciales opcional si se utilizan credenciales procedentes del servicio STS.  | 

# Creación de una solicitud de API de AWS firmada
<a name="reference_sigv-create-signed-request"></a>

**importante**  
Si utiliza un SDK de AWS (consulte [Sample Code and Libraries](https://aws.amazon.com/developer/)) o la herramienta de AWS Command Line Interface (AWS CLI) para enviar solicitudes de API a AWS, puede omitir esta sección porque los clientes del SDK y la CLI autentican sus solicitudes mediante las claves de acceso que les proporciona. A menos que tenga una razón específica para no hacerlo, le recomendamos que utilice siempre un SDK o la CLI.  
En las regiones en las que se admiten varias versiones de firma, las solicitudes de firma manual significan que debe especificar qué versión de firma se utiliza. Cuando envía solicitudes a puntos de acceso de varias regiones, los SDK y la CLI cambian de forma automática a Signature Version 4A sin configuración adicional.

Puede utilizar el protocolo de firma de AWS SigV4 a fin de crear una solicitud firmada para las solicitudes de API de AWS.

1. Crear una solicitud canónica en función de los detalles de la solicitud.

1. Calcular una firma con sus credenciales de AWS.

1. Agregar esta firma a la solicitud como encabezado de autorización.

Luego, AWS replica este proceso y verifica la firma, concediendo o denegando el acceso en consecuencia.

Para conocer cómo puede utilizar AWS SigV4 para firmar solicitudes de API, consulte [Ejemplos de firmas de solicitudes](reference_sigv-examples.md).

En la siguiente tabla, se describen las funciones que se usan en el proceso de creación de una solicitud firmada. Debe implementar código para estas funciones. Para obtener más información, consulte [ejemplos de código en los SDK de AWS](reference_sigv.md#reference_aws-signing-resources).


| Función | Descripción | 
| --- | --- | 
|  `Lowercase()`  |  Convierta la cadena de caracteres en minúsculas.  | 
|  `Hex()`  |  Codificación en minúsculas en base 16.  | 
|  `SHA256Hash()`  |  Función de hash criptográfico del algoritmo de hash seguro (SHA).  | 
|  `HMAC-SHA256()`  |  Calcula el HMAC mediante el algoritmo SHA256 con la clave de firma proporcionada. Esta es la firma final cuando firma con SigV4.  | 
|  `ECDSA-Sign`  |  La firma del Algoritmo de firma digital de curva elíptica (ECDSA) se calcula mediante firmas asimétricas basadas en la criptografía de clave público-privada.   | 
|  `KDF(K, Label, Context, L)`  |  Una KDF de NIST SP800-108 en modo de contador que utiliza la función PRF HMAC-SHA256, tal como se define en [NIST SP 800-108r1](https://doi.org/10.6028/NIST.SP.800-108r1-upd1).  | 
|  `Oct2Int(byte[ ])`  |  Una función de octeto a entero, tal como se describe en ANSI X9.62.  | 
|  `Trim()`  |  Elimine cualquier espacio en blanco inicial o final.  | 
|  `UriEncode()`  |  El URI codifica cada byte. UriEncode() debe aplicar las siguientes reglas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/reference_sigv-create-signed-request.html)  Es posible que las funciones estándar de UriEncode que proporciona su plataforma de desarrollo no funcionen debido a las diferencias en la implementación y a la ambigüedad relacionada en las RFC subyacentes. Le recomendamos que escriba su propia función UriEncode personalizada para asegurarse de que la codificación funcione.  Para ver un ejemplo de una función UriEncode en Java, consulte [Utilidades de Java](https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-core/src/main/java/com/amazonaws/util/SdkHttpUtils.java#L66) en el sitio web de GitHub.  | 

**nota**  
Al firmar sus solicitudes, puede utilizar cualquiera de las siguientes opciones: AWS SigV4 o AWS SigV4a. La diferencia clave entre las dos se determina por la forma en que se calcula la firma. Con SigV4a, el conjunto de regiones se incluye en la cadena que se va a firmar, pero no forma parte del paso de derivación de credenciales.

## Solicitudes de firma con credenciales de seguridad temporales
<a name="temporary-security-credentials"></a>

En lugar de utilizar credenciales de larga duración para firmar una solicitud, puede utilizar las credenciales de seguridad temporales proporcionadas por AWS Security Token Service (AWS STS).

Cuando utilice credenciales de seguridad temporales, debe agregar `X-Amz-Security-Token` al encabezado de autorización o incluirlo a la cadena de consulta para contener el token de sesión. Algunos servicios requieren que agregue `X-Amz-Security-Token` a la solicitud canónica. Otros servicios requieren que solo agregue `X-Amz-Security-Token` al final, después de calcular la firma. Consulte la documentación de cada Servicio de AWS para conocer los requisitos específicos.

## Resumen de pasos de firma
<a name="create-signed-request-steps"></a>

**Crear una solicitud canónica**  
Organice el contenido de la solicitud (host, acción, encabezados, etc.) en un formato canónico estándar. La solicitud canónica es uno de los datos de entrada utilizados con el fin de crear la cadena para firmar. Para obtener detalles sobre cómo crear la solicitud canónica, consulte [Elementos de una firma de solicitud a la API de AWS](reference_sigv-signing-elements.md).

**Crear un hash de la solicitud canónica**  
Cree un hash de la solicitud canónica con el mismo algoritmo que utilizó para crear el hash de la carga. El hash de la solicitud canónica es una cadena de caracteres hexadecimales en minúsculas.

**Crear una cadena para firmar**  
Cree una cadena para firmar con la solicitud canónica e información adicional, como el algoritmo, la fecha de la solicitud, el ámbito de la credencial y el hash de la solicitud canónica.

**Generar una clave de firma**  
Utilice la clave de acceso secreta para obtener la clave utilizada para firmar la solicitud.

**Calcular la firma**  
Lleve a cabo una operación hash con clave en la cadena para firmar con la clave de firma generada como clave de hash.

**Agregar la firma a la solicitud**  
Agregue la firma calculada a un encabezado HTTP o a la cadena de consulta de la solicitud.

## Crear una solicitud canónica
<a name="create-canonical-request"></a>

Para crear una solicitud canónica, concatene las siguientes cadenas, separadas por caracteres de nueva línea. Esto ayuda a garantizar que la firma que calcula pueda coincidir con la firma que calcula AWS.

```
<HTTPMethod>\n
<CanonicalURI>\n
<CanonicalQueryString>\n
<CanonicalHeaders>\n
<SignedHeaders>\n
<HashedPayload>
```
+ *HTTPMethod*: el método HTTP, como `GET`, `PUT`, `HEAD` y `DELETE`.
+ *CanonicalUri*: la versión codificada en URI del componente de ruta absoluta, que comienza con la `/` que sigue al nombre de dominio y continúa hasta el final de la cadena o del signo de interrogación (`?`) si tiene parámetros de cadena de consulta. Si la ruta absoluta está vacía, utilice un carácter de barra diagonal (`/`). El URI del siguiente ejemplo, `/amzn-s3-demo-bucket/myphoto.jpg`, es la ruta absoluta y no se codifica la `/` en la ruta absoluta:

  ```
  http://s3.amazonaws.com/amzn-s3-demo-bucket/myphoto.jpg
  ```
+ *CanonicalQueryString*: los parámetros de la cadena de consulta codificados en URI. Codifique en URI cada nombre y valor de forma individual. También debe ordenar los parámetros de la cadena de consulta canónica alfabéticamente por nombre de clave. La clasificación se produce después de la codificación. La cadena de consulta del siguiente ejemplo de URI es:

  ```
  http://s3.amazonaws.com/amzn-s3-demo-bucket?prefix=somePrefix&marker=someMarker&max-keys=2
  ```

  La cadena de consulta canónica es la siguiente (se agregan saltos de línea a este ejemplo para facilitar la lectura):

  ```
  UriEncode("marker")+"="+UriEncode("someMarker")+"&"+
  UriEncode("max-keys")+"="+UriEncode("20") + "&" +
  UriEncode("prefix")+"="+UriEncode("somePrefix")
  ```

  Cuando una solicitud se dirige a un subrecurso, el valor del parámetro de consulta correspondiente será una cadena vacía (`""`). Por ejemplo, el siguiente URI identifica el subrecurso `ACL` en el bucket `amzn-s3-demo-bucket`:

   

  ```
  http://s3.amazonaws.com/amzn-s3-demo-bucket?acl
  ```

  En este caso, la cadena CanonicalQueryString sería:

   

  ```
  UriEncode("acl") + "=" + ""
  ```

  Si el URI no incluye un `?`, no hay ninguna cadena de consulta en la solicitud y establece la cadena de consulta canónica en una cadena vacía (`""`). Aún tendrá que incluir el carácter de nueva línea (`"\n"`).
+ *CanonicalHeaders*: una lista de los encabezados de las solicitudes con sus valores. Los pares individuales de nombre y valor del encabezado se encuentran separados por el carácter de nueva línea (`"\n"`). El siguiente es un ejemplo de un CanonicalHeader:

  ```
  Lowercase(<HeaderName1>)+":"+Trim(<value>)+"\n"
  Lowercase(<HeaderName2>)+":"+Trim(<value>)+"\n"
  ...
  Lowercase(<HeaderNameN>)+":"+Trim(<value>)+"\n"
  ```

  La lista CanonicalHeaders debe incluir lo siguiente:
  + Encabezado de `host` HTTP.
  + Si el encabezado `Content-Type` se encuentra en la solicitud, debe agregarlo a la lista *CanonicalHeaders*. 
  + También debe agregar cualquier encabezado `x-amz-*` que planea incluir en su solicitud. Por ejemplo, si utiliza credenciales de seguridad temporales, debe incluir `x-amz-security-token` en su solicitud. Debe agregar este encabezado a la lista de *CanonicalHeaders*.
  + En el caso de SigV4a, debe incluir un encabezado de conjunto de regiones que especifique el conjunto de regiones en las que será válida la solicitud. El encabezado `X-Amz-Region-Set` se especifica como una lista de valores separados por comas. En el siguiente ejemplo, se muestra un encabezado de región que permite realizar una solicitud tanto en las regiones us-east-1 como us-west-1.

    `X-Amz-Region-Set=us-east-1,us-west-1 `

    Puede utilizar comodines (\$1) en las regiones para especificar varias regiones. En el siguiente ejemplo, el encabezado permite realizar una solicitud tanto en us-west-1 como en us-west-2.

    `X-Amz-Region-Set=us-west-*`
**nota**  
El encabezado `x-amz-content-sha256` es obligatorio para las solicitudes de AWS de Amazon S3. Proporciona un hash de la carga de solicitud. Si no hay ninguna carga, debe proporcionar el hash de una cadena vacía.

  Cada nombre de encabezado debe:
  + tener caracteres en minúsculas;
  + aparecer en orden alfabético;
  + ir seguido de dos puntos (`:`).

  En el caso de los valores, debe:
  + recortar los espacios iniciales o finales;
  + convertir espacios secuenciales en un solo espacio;
  + separar los valores de un encabezado con varios valores mediante comas.
  + Debe incluir el encabezado de host (HTTP/1.1) o el encabezado :authority (HTTP/2) y cualquier encabezado `x-amz-*` de la firma. Si lo desea, puede incluir otros encabezados estándar en la firma, como content-type.

  Las funciones `Lowercase()` y `Trim()` que se utilizan en este ejemplo se describen en la sección anterior.

  La siguiente es una cadena de `CanonicalHeaders` de ejemplo. Los nombres de encabezado se encuentran en minúsculas y ordenados.

   

  ```
  host:s3.amazonaws.com
  x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
  x-amz-date:20130708T220855Z
  ```

   
**nota**  
Para calcular una firma de autorización, solo se requieren el host y cualquier encabezado `x-amz-*`; sin embargo, a fin de evitar la manipulación de datos, debería considerar la posibilidad de incluir encabezados adicionales en el cálculo de la firma.  
No incluya encabezados salto a salto que se modifican frecuentemente durante el tránsito por un sistema complejo. Esto incluye todos los encabezados de transporte volátiles que mutados por proxies, equilibradores de carga y los nodos de un sistema distribuido, como `connection`, `x-amzn-trace-id`, `user-agent`, `keep-alive`, `transfer-encoding`, `TE`, `trailer`, `upgrade`, `proxy-authorization` y `proxy-authenticate`.
+ *SignedHeaders*: una lista ordenada alfabéticamente y separada por punto y coma de nombres de encabezados de solicitudes en minúsculas. Los encabezados de las solicitudes de la lista son los mismos que incluyó en la cadena de `CanonicalHeaders`. En el caso anterior, el valor de *SignedHeaders* sería el siguiente:

  ```
  host;x-amz-content-sha256;x-amz-date
  ```
+ *HashedPayload*: una cadena creada con la carga del cuerpo de la solicitud HTTP como entrada para una función de hash. Esta cadena utiliza caracteres hexadecimales en minúscula.

  ```
  Hex(SHA256Hash(<payload>>))
  ```

  Si no hay ninguna carga en la solicitud, se calcula un hash de la cadena vacía, por ejemplo, cuando se recupera un objeto mediante una solicitud `GET`, no hay nada en la carga.

  ```
  Hex(SHA256Hash(""))
  ```
**nota**  
En el caso de Amazon S3, incluya la cadena literal `UNSIGNED-PAYLOAD` al crear una solicitud canónica y establezca el mismo valor que el valor del encabezado `x-amz-content-sha256` al enviar la solicitud.  
`Hex(SHA256Hash("UNSIGNED-PAYLOAD"))`

## Crear un hash de la solicitud canónica
<a name="create-canonical-request-hash"></a>

Cree un hash (resumen) de la solicitud canónica con el mismo algoritmo que utilizó para crear el hash de la carga. El hash de la solicitud canónica es una cadena de caracteres hexadecimales en minúsculas.

## Crear una cadena para firmar
<a name="create-string-to-sign"></a>

A fin de crear una cadena para firmar, concatene las siguientes cadenas, separadas por caracteres de nueva línea. No termine esta cadena con un carácter de nueva línea.

```
Algorithm \n
RequestDateTime \n
CredentialScope  \n
HashedCanonicalRequest
```
+ *Algorithm*: el algoritmo utilizado para crear el hash de la solicitud canónica.
  + SigV4: use `AWS4-HMAC-SHA256` para especificar el algoritmo hash `HMAC-SHA256`. 
  + SigV4a: use `AWS4-ECDSA-P256-SHA256` para especificar el algoritmo hash `ECDSA-P256-SHA-256`. 
+ *RequestDateTime*: la fecha y la hora utilizadas en el alcance de la credencial. Este valor es la hora UTC actual en formato ISO 8601 (por ejemplo, `20130524T000000Z`).
+ *CredentialScope*: el ámbito de la credencial, que restringe la firma resultante a la región y el servicio especificados.
  + SigV4: las credenciales incluyen su clave de acceso, la fecha en formato `YYYYMMDD`, el código de región, el código de servicio y la cadena de terminación `aws4_request`, separados por barras diagonales (/). El código de región, el código de servicio y la cadena de terminación deben utilizar caracteres en minúscula. La cadena tiene el siguiente formato: `YYYYMMDD/region/service/aws4_request`.
  + SigV4a: las credenciales incluyen la fecha con el formato `YYYYMMDD`, el nombre del servicio y la cadena de terminación `aws4_request`, separados por barras diagonales (/). Tenga en cuenta que el ámbito de las credenciales no incluye la región, ya que la región está cubierta en un encabezado `X-Amz-Region-Set` independiente. La cadena tiene el siguiente formato: `YYYYMMDD/service/aws4_request`.
+ *HashedCanonicalRequest*: el hash de la solicitud canónica, calculado en el paso anterior.

La siguiente es una cadena de ejemplo para firmar.

```
"<Algorithm>" + "\n" +
timeStampISO8601Format + "\n" +
<Scope> + "\n" +
Hex(<Algorithm>(<CanonicalRequest>))
```

## Generar una clave de firma
<a name="derive-signing-key"></a>

Para obtener una clave de firma, elija uno de los siguientes procesos para calcular una clave de firma para SigV4 o SigV4a.

### Generar una clave de firma para SigV4
<a name="derive-signing-key-sigv4"></a>

Para generar una clave de firma para SigV4, lleve a cabo una sucesión de operaciones hash con clave (HMAC) en la fecha de la solicitud, la región y el servicio, con su clave de acceso secreta de AWS como clave de la operación hash inicial.

Para cada paso, llame a la función de hash con la clave y los datos necesarios. El resultado de cada llamada a la función de hash se convierte en la entrada de la siguiente llamada a la función de hash.

En el siguiente ejemplo, se muestra cómo se genera la `SigningKey` que se utiliza en la siguiente sección de este procedimiento y se muestra el orden en el que se concatena y se codifica la entrada. `HMAC-SHA256` es la función hash que se utiliza para codificar los datos, tal como se muestra.

```
DateKey = HMAC-SHA256("AWS4"+"<SecretAccessKey>", "<YYYYMMDD>")
DateRegionKey = HMAC-SHA256(<DateKey>, "<aws-region>")
DateRegionServiceKey = HMAC-SHA256(<DateRegionKey>, "<aws-service>")
SigningKey = HMAC-SHA256(<DateRegionServiceKey>, "aws4_request")
```

**Datos de ingreso obligatorios**
+ `Key`: una cadena que contiene su clave de acceso secreta.
+ `Date`: una cadena que contiene la fecha utilizada en el alcance de la credencial con el formato *DDMMAAAA*.
+ `Region`: una cadena que contiene el código de región (por ejemplo, `us-east-1`).

  Para obtener una lista de cadenas de región, consulte [Regional Endpoints](https://docs.aws.amazon.com//general/latest/gr/rande.html#regional-endpoints) en la *Referencia general de AWS*.
+ `Service`: una cadena que contiene el código de servicio (por ejemplo, `ec2`).
+ La cadena para firmar que creó en el paso anterior.

**Para generar una clave de firma para SigV4**

1. Concatene `"AWS4"` y la clave de acceso secreta. Llame a la función de hash con la cadena concatenada como clave y la cadena de fecha como datos.

   ```
   DateKey = hash("AWS4" + Key, Date)
   ```

1. Llame a la función de hash con el resultado de la llamada anterior como clave y la cadena de región como datos.

   ```
   DateRegionKey = hash(kDate, Region)
   ```

1. Llame a la función de hash con el resultado de la llamada anterior como clave y la cadena de servicio como datos.

   El servicio define el código de servicio. Puede utilizar [get-products](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/pricing/get-products.html) en la *CLI de precios de AWS* para devolver el código de servicio de un servicio.

   ```
   DateRegionServiceKey = hash(kRegion, Service)
   ```

1. Llame a la función de hash con el resultado de la llamada anterior como clave y “aws4\$1request” como datos.

   ```
   SigningKey = hash(kService, "aws4_request")
   ```

### Generar una clave de firma para SigV4a
<a name="derive-signing-key-sigv4a"></a>

Para crear una clave de firma para SiGV4a, utilice el siguiente proceso a fin de generar un par de claves a partir de la clave de acceso secreta. Para ver un ejemplo de una implementación de esta derivación, consulte la [implementación de la biblioteca C99 de la autenticación de AWS del lado del cliente](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
}
```

## Calcular la firma
<a name="calculate-signature"></a>

Una vez que se genera la clave de firma, calcule la firma para agregar a la solicitud. Este procedimiento varía en función de la versión de firma que utilice.

**Para calcular una firma para SigV4**

1. Llame a la función de hash con el resultado de la llamada anterior como clave y la **cadena para firmar** como datos. Utilice la clave de firma generada como clave hash para esta operación. El resultado es la firma como valor binario.

   ```
   signature = hash(SigningKey, string-to-sign)
   ```

1. Convierta la firma de representación binaria a hexadecimal, en caracteres en minúsculas.

**Para calcular una firma para SigV4a**

1. Con el algoritmo de firma digital (ECDSA P-256), firme la **cadena para firmar** que creó en el paso anterior. La clave utilizada para esta firma es la clave asimétrica privada derivada de la clave de acceso secreta descrita anteriormente.

   ```
   signature = base16(ECDSA-Sign(k, string-to-sign))
   ```

1. Convierta la firma de representación binaria a hexadecimal, en caracteres en minúsculas.

## Agregar la firma a la solicitud
<a name="add-signature-to-request"></a>

Agregue la firma calculada a su solicitud.

**Example Ejemplo: encabezado de autorización**  
**SigV4**  
En el ejemplo siguiente se muestra un encabezado de `Authorization` para la acción `DescribeInstances`mediante AWS SigV4. Para facilitar la lectura, este ejemplo está formateado con saltos de línea. En su código, debe ser una cadena continua. No hay ninguna coma entre el algoritmo y `Credential`. Sin embargo, los demás elementos deben ir separados por comas.

```
Authorization: AWS4-HMAC-SHA256
Credential=AKIAIOSFODNN7EXAMPLE/20220830/us-east-1/ec2/aws4_request,
SignedHeaders=host;x-amz-date,
Signature=calculated-signature
```

**SigV4a**  
En el ejemplo siguiente se muestra un encabezado de autorización para la acción `CreateBucket` mediante AWS SigV4a. Para facilitar la lectura, este ejemplo está formateado con saltos de línea. En su código, debe ser una cadena continua. No hay ninguna coma entre el algoritmo y la credencial. Sin embargo, los demás elementos deben ir separados por comas.

```
Authorization: AWS4-ECDSA-P256-SHA256
Credential=AKIAIOSFODNN7EXAMPLE/20220830/s3/aws4_request,
SignedHeaders=host;x-amz-date;x-amz-region-set,
Signature=calculated-signature
```

**Example Ejemplo: solicitud con parámetros de autenticación en la cadena de consulta**  
**SigV4**  
En el siguiente ejemplo, se muestra una consulta para la acción `DescribeInstances` mediante AWS SigV4 que incluye la información de autenticación. Para facilitar la lectura, este ejemplo está formateado con saltos de línea y no está codificado en URL. En el código, la cadena de consulta debe ser una cadena continua codificada 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**  
En el siguiente ejemplo, se muestra una consulta para la acción `CreateBucket` mediante AWS SigV4a que incluye la información de autenticación. Para facilitar la lectura, este ejemplo está formateado con saltos de línea y no está codificado en URL. En el código, la cadena de consulta debe ser una cadena continua codificada 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
```

# Ejemplos de firmas de solicitudes
<a name="reference_sigv-examples"></a>

Los siguientes ejemplos de solicitudes de firma de AWS muestran cómo se puede usar SigV4 para firmar las solicitudes enviadas sin el AWS SDK o la herramienta de línea de comandos de AWS.

## Carga de Amazon S3 basada en el navegador mediante HTTP POST
<a name="signature-v4-examples-s3-browser"></a>

 [Autenticación de solicitudes: cargas basadas en el navegador](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authentication-HTTPPOST.html) describe la firma y la información relevante que Amazon S3 utiliza para calcular la firma al recibir la solicitud.

[Ejemplo: carga basada en el navegador mediante HTTP POST (con Signature Version 4 de AWS)](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-post-example.html) proporciona más información con un ejemplo de política POST y un formulario que se puede utilizar para cargar un archivo. La política de ejemplo y las credenciales ficticias muestran el flujo de trabajo y el hash de la firma y la política resultantes.

## Solicitudes autenticadas de VPC Lattice
<a name="signature-v4-examples-lattice"></a>

 [Ejemplos de solicitudes autenticadas de Signature Version 4 (SigV4)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sigv4-authenticated-requests.html) proporciona ejemplos de Python y Java que muestran cómo se puede realizar la firma de solicitudes con y sin interceptores personalizados.

## Uso de la Signature Version 4 con Amazon Translate
<a name="signature-v4-examples-translate"></a>

 En [Live Translations in the Metaverse](https://aws.amazon.com/blogs/spatial/live-translations-in-the-metaverse/) se muestra cómo crear una aplicación que produzca una solución de traducción casi en tiempo real. Esta solución de traducción de voz a voz utiliza AWS SigV4 en la codificación de secuencias de eventos para producir transcripciones en tiempo real.

## Uso de Signature Version 4 con Neptune
<a name="signature-v4-examples-neptune"></a>

[Ejemplo: conectarse a Neptune mediante Python con firmas de Signature Version 4](https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-connecting-python.html) muestra cómo realizar solicitudes firmadas a Neptune mediante Python. En este ejemplo, se incluyen variantes para usar una clave de acceso o credenciales temporales.

## Firmar solicitudes HTTP en Amazon Glacier
<a name="signature-v4-examples-streaming-glacier"></a>

[Ejemplo de cálculo de firmas para la API de streaming](https://docs.aws.amazon.com/amazonglacier/latest/dev/amazon-glacier-signing-requests.html) explica los detalles de la creación de una firma para Upload Archive (archivo POST), una de las dos API de streaming de Amazon Glacier.

## Realizar solicitudes HTTP a Amazon SWF
<a name="signature-v4-examples-swf"></a>

[Realizar solicitudes HTTP a Amazon SWF](https://docs.aws.amazon.com/amazonswf/latest/developerguide/UsingJSON-swf.html#HTTPHeader) muestra el contenido del encabezado de una solicitud JSON a Amazon SWF.

## Cálculo de firmas para las API de streaming en Amazon OpenSearch Service
<a name="signature-v4-examples-open-search"></a>

[Firmar una solicitud de búsqueda de Amazon OpenSearch Service con AWS SDK para PHP versión 3](https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/service_es-data-plane.html) incluye un ejemplo de cómo enviar solicitudes HTTP firmadas a Amazon OpenSearch Service.

## Proyectos de ejemplo en AWS repositorio de muestras
<a name="signature-v4-examples-sdk"></a>

Los siguientes proyectos de ejemplo muestran cómo firmar solicitudes para realizar solicitudes de la API Rest a AWS servicios con lenguajes comunes como Python, Node.js, Java, C\$1, Go y Rust. 

### Proyectos exclusivos de la versión 4a
<a name="signature-v4-examples-sigv4a"></a>

En el proyecto [sigv4-signing-examples](https://github.com/aws-samples/sigv4-signing-examples), hay ejemplos de cómo firmar solicitudes con SigV4a para realizar solicitudes de API Rest a Servicios de AWS con lenguajes comunes como Python, Node.js, Java, C\$1, Go y Rust.

El proyecto [sigv4a-signing-examples](https://github.com/aws-samples/sigv4a-signing-examples) proporciona ejemplos para firmar solicitudes de API multirregionales, por ejemplo, [Puntos de acceso multirregionales en Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html).

### Publish to AWS IoT Core
<a name="signature-v4-examples-iot-python"></a>

[Código Python para publicar en AWS IoT Core utilizando el protocolo HTTPS](https://github.com/aws-samples/aws-iot-core-python-node-sigv4-https) proporciona orientación sobre cómo publicar mensajes en AWS IoT Core utilizando el protocolo HTTPS y autenticación SigV4 de AWS. Tiene dos implementaciones de referencia, una en Python y otra en NodeJS.

[Aplicación .Net Framework para publicar en AWS IoT Core utilizando el protocolo HTTPS](https://github.com/aws-samples/aws-iot-core-http-sigv4-dotnet-app) proporciona orientación sobre cómo publicar mensajes en AWS IoT Core utilizando el protocolo HTTPS y autenticación SigV4 de AWS. Este proyecto también incluye una implementación equivalente a .NET core.

# Solución de problemas de firma de Signature Version 4 para las solicitudes de API de AWS
<a name="reference_sigv-troubleshooting"></a>

**importante**  
A menos que utilice la CLI o los SDK de AWS, debe escribir código para calcular las firmas que brindan información de autenticación en sus solicitudes. El cálculo de firmas de SigV4 puede ser una tarea compleja, por lo que recomendamos utilizar los AWS SDK o la CLI siempre que sea posible.

Cuando desarrolla código que crea una solicitud firmada, es posible que reciba HTTP 403 `SignatureDoesNotMatch` por parte de Servicios de AWS. Estos errores significan que el valor de la firma en la solicitud de HTTP a AWS no coincide con la firma que Servicio de AWS calculó. Los errores HTTP 401 `Unauthorized` se producen cuando los permisos no permiten al intermediario realizar la solicitud.

Las solicitudes de API pueden devolver un error en los siguientes casos:
+ La solicitud de API no está firmada y utiliza la autenticación de IAM.
+ Las credenciales de IAM utilizadas para firmar la solicitud son incorrectas o no tienen permisos para invocar la API.
+ La firma de la solicitud de API firmada no coincide con la firma que calculó el servicio de AWS.
+ El encabezado de la solicitud de API es incorrecto.

**nota**  
Actualice el protocolo de firmas de Signature Version 2 (SigV2) de AWS a Signature Version 4 (SigV4) de AWS antes de buscar otras soluciones de error. Servicios como Amazon S3 y Regions ya no admiten la firma SigV2.

**Topics**
+ [Errores de credencial](#signature-v4-troubleshooting-credential)
+ [Errores canónicos en la cadena de solicitud y firma](#signature-v4-troubleshooting-canonical-errors)
+ [Errores en el alcance de la credencial](#signature-v4-troubleshooting-credential-scope)
+ [Errores de firma de clave](#signature-v4-troubleshooting-key-signing)

## Errores de credencial
<a name="signature-v4-troubleshooting-credential"></a>

Asegúrese de que la solicitud de API esté firmada con SigV4. Si la solicitud de API no está firmada, es posible que reciba el siguiente error: `Missing Authentication Token`. [Agregue la firma que falta](https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-request.html#add-signature-to-request) y vuelva a enviar la solicitud.

Verifique que las credenciales de autenticación para la clave de acceso y la clave secreta sean correctas. Si la clave de acceso es incorrecta, es posible que reciba el siguiente error: `Unauthorized`. Asegúrese de que la entidad utilizada para firmar la solicitud esté autorizada para realizar la solicitud. Para obtener más información, consulte [Solucionar problemas de mensajes de error de acceso denegado](troubleshoot_access-denied.md). 

## Errores canónicos en la cadena de solicitud y firma
<a name="signature-v4-troubleshooting-canonical-errors"></a>

Si no calculó correctamente la solicitud canónica en [Crear un hash de la solicitud canónica](reference_sigv-create-signed-request.md#create-canonical-request-hash) o [Crear una cadena para firmar](reference_sigv-create-signed-request.md#create-string-to-sign), el paso de verificación de firmas que realiza el servicio falla con el siguiente mensaje de error:

```
The request signature we calculated does not match the signature you provided
```

Cuando el servicio de AWS recibe una solicitud firmada, vuelve a calcular la firma. Si hay diferencias en los valores, las firmas no coinciden. Compare la solicitud canónica y la cadena con la solicitud firmada con el valor en el mensaje de error. Modifique el proceso de firma si hay alguna diferencia.

**nota**  
También puede comprobar que no envió la solicitud a través de un proxy que modifique los encabezados o la solicitud.

**Example Ejemplo de solicitud canónica**  

```
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
```

Para comprobar que la clave secreta coincide con el ID de clave de acceso, puede probarla con una implementación funcional conocida. Por ejemplo, utilice un AWS SDK o la AWS CLI para realizar una solicitud a AWS.

### Encabezado de solicitud API
<a name="signature-v4-troubleshooting-credential-header"></a>

Si el encabezado de la autorización está vacío, falta o es incorrecta la clave o firma de la credencial, el encabezado no comienza con un nombre de algoritmo o los pares clave-valor no incluyen un signo igual, aparece uno de estos errores:
+ El encabezado de la autorización no puede estar vacío.
+ El encabezado de la autorización requiere el parámetro “Credential”.
+ El encabezado de la autorización requiere el parámetro “Signature”.
+ La firma contiene un par clave=valor no válido (falta el signo igual) en el encabezado de la autorización.

Asegúrese de que el encabezado de la autorización SigV4 que haya agregado a [Calcular la firma](reference_sigv-create-signed-request.md#calculate-signature) también incluya la clave de credencial correcta, además de la fecha de la solicitud utilizando “HTTP Date” o el encabezado `x-amz-date`.

Si aparece un error IncompleteSignatureException y la estructura de la firma es correcta, puede comprobar que el encabezado de la autorización no se haya modificado durante el tránsito hasta el Servicio de AWS calculando un hash SHA-256 y una codificación B64 del encabezado de la autorización en la solicitud del cliente.

1. Obtenga el [encabezado de la autorización](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) que haya enviado en la solicitud. El encabezado de la autorización es similar al siguiente ejemplo:

   ```
   Authorization: AWS4-HMAC-SHA256 
   Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, 
   SignedHeaders=host;range;x-amz-date,
   Signature=example-generated-signature
   ```

1. Calcule un hash SHA-256 del encabezado de la autorización.

   ```
   hashSHA256(rawAuthorizationHeader) = hashedAuthorizationHeader
   ```

1. Codifique el encabezado de la autorización con el hash en formato Base64. 

   ```
   base64(hashedAuthorizationHeader) = encodedHashedAuthorizationHeader
   ```

1. Compare la cadena con hash y codificada que acaba de calcular con la cadena que aparezca en el mensaje de error. El mensaje de error debe ser similar al siguiente ejemplo:

   ```
   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 los dos hashes son diferentes, significa que alguna parte del encabezado de la autorización ha cambiado durante el tránsito. Este cambio puede deberse a que los controladores de la red o el cliente han asociado encabezados firmados, o a que han cambiado el encabezado de la autorización de alguna manera. 
+ Si los dos hashes coinciden, el encabezado de la autorización enviado en la solicitud coincide con el recibido por AWS. Revise el mensaje de error para determinar si el problema se debe a que las credenciales o la firma son incorrectas. Estos errores se describen en las demás secciones de esta página. 

## Errores en el alcance de la credencial
<a name="signature-v4-troubleshooting-credential-scope"></a>

El alcance de la credencial que creó en [Crear una cadena para firmar](reference_sigv-create-signed-request.md#create-string-to-sign) restringe la firma a una fecha, región y servicio específicos. Esta cadena tiene el siguiente formato:

```
YYYYMMDD/region/service/aws4_request
```

**nota**  
Si utiliza SigV4a, la región no está incluida en el ámbito de las credenciales.

**Date**  
Si el alcance de la credencial no especifica la misma fecha que el encabezado x-amz-date, el paso de verificación de la firma falla y aparece el siguiente mensaje de error:

```
Date in Credential scope does not match YYYYMMDD from ISO-8601 version of date from HTTP
```

Si la solicitud especifica una fecha futura, el paso de verificación de la firma falla con el siguiente mensaje de error:

```
Signature not yet current: date is still later than date
```

Si la solicitud ha caducado, el paso de verificación de la firma falla con el siguiente mensaje de error:

```
Signature expired: date is now earlier than date
```

**Región**  
Si el alcance de la credencial no especifica la misma región que la solicitud, el paso de verificación de la firma falla con el siguiente mensaje de error:

```
Credential should be scoped to a valid Region, not region-code
```

**Servicio**  
Si el alcance de la credencial no especifica el mismo servicio que el encabezado host, el paso de verificación de la firma falla con el siguiente mensaje de error:

```
Credential should be scoped to correct service: 'service'
```

**Cadena de terminación**  
Si el alcance de la credencial no termina con aws4\$1request, el paso de verificación de la firma falla con el siguiente mensaje de error:

```
Credential should be scoped with a valid terminator: 'aws4_request'
```

## Errores de firma de clave
<a name="signature-v4-troubleshooting-key-signing"></a>

Los errores causados por la generación incorrecta de la clave de firma o por un uso indebido de la criptografía son más difíciles de solucionar. Luego de comprobar que la cadena canónica y la cadena para firmar son correctas, también puede comprobar si existe alguno de los siguientes problemas:
+ La clave de acceso secreta no coincide con el ID de clave de acceso que especificó.
+ Hay un problema con el código de generación de la clave.

Para comprobar que la clave secreta coincide con el ID de clave de acceso, puede probarla con una implementación funcional conocida. Por ejemplo, utilice un SDK de AWS o la AWS CLI para hacer una solicitud a AWS. Para ver ejemplos, consulte [Ejemplos de firmas de solicitudes](reference_sigv-examples.md)