Fix Impersonation Under Access Token Method

[tgoodsell-tempus]

What: When using the current configurations to do a impersonated_user_email using a defined access_token, the call is using the under the hood signJwt method and improperly setting up the impersonated token. This switches to the better supported generateAccessToken API method.

Why: Even with the iam.serviceAccountTokenCreator role applied, the signJwt method is providing a 403 error when attempting this operation. However, using the generateAccessToken method succeeds as expected. Ultimately this produces the same access token required for the client.

[amontalban]

Thank you so much @tgoodsell-tempus this fixed my issues after loosing SEVERAL HOURS figuring out what was not working.

I have an AWS IAM Role that is impersonating a ServiceAccount using Workload Identity Federation which then impersonates a ServiceAccount that manages Google Workspace so figuring this out was kind of hard until Google pointed me to this PR 🙏 .

@SarahFrench @megan07 Can we have this merged, please?

[amontalban]

@sheneska do you think we can merge this? Thanks! 🙏

[LilithWittmann]

Just spent a few hours debugging exactly this issue (github wif -> gcp project sa -> workspace access) til I found this PR. Can we please please get this merged? Or is there any active fork fixing this?