Router <> Subgraph signature (HMAC & AWS Sigv4)

Subgraph Authentication allows to secure the connection between your subgraphs and the gateway.
Today we've seen two ways of doing this.

## HMAC Signature

HMAC (Hash-based Message Authentication Code) is a mechanism for calculating a message authentication code involving a hash function in combination with a secret key. It can be used to verify the integrity and authenticity of a message.

You create a secret which will only be known by the subgraphs and the gateway. So every time gateway sends a request to those subgraphs, a signature is created with the secret and the hash of the request then the subgraph server will validate it.

In Hive Gateway JS, HMAC Signature is added to the extensions of the GraphQL request which makes it transport-agnostic. So it doesn't use HTTP headers and so on but the extensions so any transport that gets extensions in the GraphQL request payload.
Then the subgraph server can receive and validate it on its own;

```json
{
"query": "query { comments { id author { id name } } ",
"variables": {},
"extensions": {
"hmac-signature": "AbC123"
}
}
```

[Reference implementation in Hive Gateway]()

Hive Gateway accepts an option to define the name of the extension, and the algorithm of the hashing then the secret.
And it also provides ready-to-use recipes and plugins for subgraph server implementations like Yoga and Apollo Servers in JavaScript.

## AWS SigV4

If you have subgraphs deployed in AWS, you can use AWS signature v4 to secure the connection in between subgraphs and the gateway. But this is specific to HTTP compared to HMAC Signature's platform agnostic approach. First gateway creates a signature, then it uses AWS algorithm to create necessary headers for each HTTP request sent to specified AWS subgraphs.

But first the gateway should gather the required information which is called AWS Credentials(access key and id) to generate that signature,

**Apollo Router** by default checks for default chain auth configuration by checking the environment variables, local configuration files and so on. [See here]() So it finds a way to gather access key and id to generate the AWS Signature.

**Hive Gateway** requires to be more specific if you don't provide some environment variables.
The supported environment variables for credentials as same as Apollo Router are;
`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_REGION`. Then Hive Gateway uses AWS's official libraries to generate the signature. If you rely on `Assume Role IAM` which is a higher-level credentials that generates access ids and keys dynamically instead of using the static values, you have to provide `roleArn` and `roleSessionName` explicitly.
[Reference]()

### My take

But anyways the router should be smart enough to detect the credentials by following the rules as in Apollo Router's docs but also the rules defined here [Credentials providers]()
So users deploying in AWS don't need to embed hardcoded values in the configuration file.

> Of course these two approaches can be defined globally for all subgraphs but also for a specific subgraph.

The issue names no files, tests, or code entry points. Start by locating the router's subgraph request and authentication configuration, then determine how HMAC extensions, AWS SigV4 headers, credential-provider discovery, and global or per-subgraph settings would fit together. Done should include both authentication approaches and the credential behavior described in the issue, with tests covering the supported configuration paths.

Written by the indexing model from the issue text.