search

mildsunrise / a4s

📝 AWS Signature v4 primitives and high-level utilities
MIT License
11 stars 1 forks source link

AWS session token / cognito temporary credentials. #2

Open andreialecu opened 4 years ago

andreialecu commented 4 years ago

This library looks promising, especially since it's written in TypeScript.

I found it while investigating a way to generate HTTP authorization headers for signing S3 GET requests.

However, I noticed that RelaxedCredentials does not accept sessionToken, which is used for Cognito temporary credentials.

This is important for the AWS Amplify ecosystem, eg: https://github.com/aws-amplify/amplify-js/issues/5296

mildsunrise commented 4 years ago

Hello! STS temporary credentials work just like long-term ones, except that you need to add an X-Amz-Security-Token header or query parameter.

Nothing changes when it comes to the signature process, and since adding the parameter is easy, I didn't feel a need to integrate it into the API. Do you think it would be better to do it?

andreialecu commented 4 years ago

The x-amz-security-token though needs to be signed.

Here's an example signature:

AWS4-HMAC-SHA256 Credential=ASIA3KVBTHSWCFSXAPFR/20200404/eu-west-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature=e825c1c763af70160bf437d44e05949d38eee0f0944928eb93604bc268f3d702

The CanonicalRequest also includes this header and its contents as part of the signature.

andreialecu commented 4 years ago

Ah I understand what you mean, it can be added manually to the list of headers to sign and it should work.

For discoverability though, it might make more sense to include it as part of the library.

mildsunrise commented 4 years ago

Ah I understand what you mean, it can be added manually to the list of headers to sign and it should work.

That's correct! It works like any other parameter, say X-Amz-Expires.

(However, I've barely used STS so I could be wrong. I recall reading that some services instead make you add the parameter after signing, not before)

For discoverability though, it might make more sense to include it as part of the library.

Given these kinds of parameters do not affect the signing process (and this library is specifically about signing), I usually avoid putting them in the API... but we could make an exception here :thinking:

At the very least, it should be mentioned in the documentation and added to the examples. PRs are welcome, otherwise I'll do it when I find some time