fix: #2139

[benkoska]

Description

Given that the AWS API (called https://github.com/googleapis/google-auth-library-nodejs/blob/main/src/auth/defaultawssecuritycredentialssupplier.ts#L250) returns a JSON body with the correct tokens, but with a Content-Type of text/plain instead of application/json and given that the gaxios call no longer specifies a responseType (https://github.com/googleapis/google-auth-library-nodejs/blob/main/src/auth/defaultawssecuritycredentialssupplier.ts#L245), gaxios tries to infer the return type from the header (text/plain), therefore simply returning a string instead of a object.

The function calling this method to get the credential, assumes that the response is an object though, accessing fields such as awsCreds.AccessKeyId (https://github.com/googleapis/google-auth-library-nodejs/blob/main/src/auth/defaultawssecuritycredentialssupplier.ts#L178), which evaluate to undefined, as the properties do not exist on a String.

The rest of the code seems to assume that if an object is returned and no error is thrown, that the fields are correctly set and do not further validate anything. This leads to further API calls that rely on these values to simply use them, without validating if they are set, resulting in downstream errors.

This patch fixes this, by setting the responseType back to json (which it used to be set to) meaning that gaxios will try to parse it as a json object, even if the Content-Type header is text/plain and adding an explicit validation that the corresponding fields exist, throwing an error if they do not.

Impact

If the response from the AWS Security Credentials API is invalid, it will throw an error.

Testing

No tests were added or changed. A test would need to be run on an AWS EC2 instance that is configured for Workload Identity Federation with a Google Cloud Project to run and cannot be run using the current setup (to my knowledge).

Additional Information

None

Checklist

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease
• Appropriate docs were updated
• Appropriate comments were added, particularly in complex areas or places that require background
• No new warnings or issues will be generated from this change

Fixes #2139 🦕

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[leahecole]

@benkoska apologies for the delay, we have been triaging issues while on rotation and I've finally made it to this one in the backlog. Could you please add a test for this?

[benkoska]

@benkoska apologies for the delay, we have been triaging issues while on rotation and I've finally made it to this one in the backlog. Could you please add a test for this?

There are already tests for the AWS client and the only new branch is the validation throwing an exception, which is already tested by an existing test (https://github.com/googleapis/google-auth-library-nodejs/blob/main/test/test.awsclient.ts#L1134C1). The only test I could think of is to verify if stubbing in and returning null for awsCreds causes the if (awsCreds == null) to trigger, which is kind of unnecessary in my opinion. Feel free to correct me if there is a specific test you are looking for.