feat: add support for external_account credentials

[AprilNEA]

Summary

This PR adds support for the external_account credential type, enabling authentication via GCP Workload Identity Federation from external identity providers such as GitHub Actions OIDC, AWS, Azure AD, and other OIDC/SAML providers.

Motivation

Currently, gcp_auth only supports:

• service_account credentials
• authorized_user credentials
• GCE metadata server
• gcloud CLI

When using GOOGLE_APPLICATION_CREDENTIALS with an external_account type credential file (generated by tools like google-github-actions/auth), the library fails with:

failed to deserialize ApplicationCredentials: missing field private_key

This is because the library assumes all credential files are service account keys.

External Account Flow

sequenceDiagram
      participant ST as Subject Token<br/>(OIDC JWT)
      participant STS as GCP STS API<br/>/v1/token
      participant FT as Federated Token
      participant IAM as IAM Credentials<br/>:generateAccessToken
      participant AT as Access Token<br/>(SA Impersonated)

      ST->>STS: Exchange token
      STS->>FT: Return federated token

      alt Service Account Impersonation configured
          FT->>IAM: Request impersonation
          IAM->>AT: Return access token
      end

Loading

Related

• Closes Using GOOGLE_APPLICATION_CREDENTIALS to specify an authorized_user or impersonated_service_account JSON key file giving "missing field private_key" error #56 (partial - adds support for external_account type)
• https://google.aip.dev/auth/4117
• https://github.com/google-github-actions/auth

[djc]

Both the PR description and the code seems to be obviously LLM-generated. At the very least, edit your PR description down to a concise (that is, human) description of what you're trying to achieve and if/how this is supported by official Google SDKs. There's a lot of new code which, from a quick look, suffers from the typical verboseness exhibited by LLMs as well -- which means I don't want to maintain it.

[AprilNEA]

Both the PR description and the code seems to be obviously LLM-generated. At the very least, edit your PR description down to a concise (that is, human) description of what you're trying to achieve and if/how this is supported by official Google SDKs. There's a lot of new code which, from a quick look, suffers from the typical verboseness exhibited by LLMs as well -- which means I don't want to maintain it.

I am very sorry about this. But I did indeed carefully edit the description, and I believe that the parts retained are necessary for this PR.
For this code, I have already used it in internal business. If there is a possibility of simplification, I will continue to maintain it.
You can choose to close this PR. I will wait until the code is sufficiently streamlined and robust before submitting a PR at an appropriate time.

Thank you for your time.