feat: add AWS credential source

[bshaffer]

Depends on #473

• Successfully used to retrieve a token on AWS!
• Verify implementation using test cases used by the other languages
• Add Quota Project support

[vishwarajanand]

The PR looks great! I've reviewed the changes and tested them on an Amazon EC2 machine to ensure they work correctly without failures. And an access token is generated successfully which can be used to make other calls.

However, I'd like to bring up a potential improvement and concern:

Improvement:

It might be a good idea for later into the PHP Client Library to better handle the project_id field. Currently, the AWS JSON key doesn't seem to include include project_id or projectId by default, unlike other authentication flows (e.g., service accounts) that do contain this key. While the audience URL does include a project number, there may be cases where having the project_id explicitly in the JSON key could be beneficial.

Concern:

I've noticed that the StorageClient may encounter issues in situations where users rely on automatic detection of the project_id. Other clients may also typically expect this field to be provided explicitly or get derived automatically from the JSON key. In the absence of the project_id, these cases could potentially lead to failures in user's application.

How I generated the token:

use Google\Auth\Credentials\ExternalAccountCredentials;

putenv(sprintf('GOOGLE_APPLICATION_CREDENTIALS=%s/%s', __DIR__, 'key.json'));
$creds = ApplicationDefaultCredentials::getCredentials('https://www.googleapis.com/auth/cloud-platform');
print_r($creds->fetchAuthToken())

[bshaffer]

@vishwarajanand

the AWS JSON key doesn't seem to include include project_id or projectId by default, unlike other authentication flows (e.g., service accounts) that do contain this key

Credentials return the "quota project ID", which is something different. However, it may be a good idea to have ExternalAccountCredentials support quota_project_id, which it currently doesn't support.

I've noticed that the StorageClient may encounter issues in situations where users rely on automatic detection of the project_id

We've gone through a few iterations of "project ID detection", but it's a complex problem because the various client libraries do it a little differently (env var, client option, credential field, etc). However, this is a separate issue that is out of scope of this PR.

[bshaffer]

@vishwarajanand I stand corrected, it IS supported (via ProjectIdProviderInterface). It doesn't seem like this is supported in the NodeJS implementation or the python implementation, at least not from JSON credentials

https://github.com/googleapis/google-auth-library-nodejs/blob/bf23bad915cae8994b2953b406d04112848c5224/src/auth/baseexternalclient.ts#L68-L83

https://github.com/googleapis/google-auth-library-python/blob/117e3253d27ca4519dabe169825a3a0473aff482/google/auth/external_account.py#L350-L353

I'll do some more research here...

[bshaffer]

Okay it looks like there IS a way you can potentially get the project ID from the audience or from the workload identity pool, but after speaking with @aeitzman, this is a part of Workforce credentials, and can be a follow-up PR.

I've created this bug to track it: #483