ID tokens and the Credential trait

[fiadliel]

I understand from some of the discussion in #364 that ID tokens are possibly in scope for this library?

If so, I just wanted to provide some feedback on what I would like in that area, and some concerns about what is currently there:

Features I think are needed:

• recognition of the current credentials (ADC) and generation of ID tokens for the underlying identity
• customization of what the ID token contains, e.g. email address
• impersonation of an identity is an optional extra, user can also just use the API directly for this (I think) less common use case
• Some environments, like Cloud Run, have a quota on the rate of ID token generation, so caching would be nice
• Validating ID tokens is a nice to have, but I recognize the significant extra complexity in doing this correctly (how do you fetch JWKS, how do you cache/refresh/etc.). Definitely people can just use an OAuth implementation directly for this.

Using the IAM API for some aspects of this potentially cause a circular dependency, maybe makes ID token handling better suited as a separate library to access token auth?

---

Concerns:
I'm not personally convinced that this should be represented by the current Credentials type. I should be able to use the current credentials, as I would want to create access tokens and ID tokens for the same identity, without having to configure the library twice.

Some aspects of the Credentials trait are not well suited to ID tokens:

• I want to create ID tokens with different audience values, this is not a different identity, so should be an easy and lightweight operation. I should be able to talk to 10 different Cloud Run instances with .get_id_token(cloud_run_audience), without having to hold 10 different credential structures. For example, consider a reverse proxy to many different CR instances. Ideally, the caching (if it exists) works by audience.
• No way to customize whether this particular ID token has an email or not? (I guess you could configure the credential source here, but it's unfortunate that it's an all-or-nothing setting)
• Choosing the headers for ID tokens feels like forcing an arbitrary decision. I sometimes use x-serverless-authorization, and sometimes authorization. And as ID tokens support JWK validation, it's possible to use them in completely user-invented protocols.

I would also say that I would never want to replace a Google access token source with an ID token source - the target audiences are completely disjoint; one is validated by Google, the other can be validated using standard OAuth approaches. So forcing them to use the same trait doesn't offer much to benefit the user.

---

I recognize that some of this is different from what exists in other Google APIs, e.g. Java (in https://github.com/googleapis/google-auth-library-java/tree/main/oauth2_http/java/com/google/auth/oauth2) models IdToken as a subtype of AccessToken. I consider this a mistake (there is not an is a relationship here, ID tokens do not have scopes, etc.).

All the above is just my personal opinion; happy if any of it is of help.

[coryan]

/FYI @dbolduc @sai-sunder-s @westarle

[sai-sunder-s]

Thank you for the feedback!

Regarding the features:

• We will definitely support building credential from ADC for ID tokens
• We will be supporting impersonation for ID tokens
• There will be caching
• It is likely that we will add support for ID token validation, we need to evaluate on it more in the future. There might be existing standard libraries to do it, so we would have to evaluate before we take a call on this.
• Can you elaborate more on customizing the ID token and provide some use cases.

Regarding the concerns:

• We have not yet finalized on how to represent id tokens. One of the considerations is to add a get_id_token() to the credential trait. We will look into supporting a get_id_token(audience) when designing id tokens. Thank you for this feedback.
• If you would like to use custom headers, you can do so by getting the token alone through get_token() method and build your own header.

[fiadliel]

Customizing the ID token

The main feature here that is supported across both the metadata server and IAM is the ability to add the email (and email_verified) claims. This allows a consumer of the ID token to verify the service account email by verifying the JWT signature (this is useful for verifying a workload's identity in GCP).
Without the email, it is possible to verify the SA using the sub field, but this requires handling the SA's unique ID, which is not so friendly, or going to Google's tokeninfo, which is not something one would want to do at scale.

MDS also supports a few other flags (format and licenses); I can imagine somebody might find these useful, but they're not something I have a use case for. Since they're only available in certain scenarios (compute instance, no impersonation), it seems like it'd be harder to have in a library (it's surprising if the flags fail in some contexts). So I wouldn't expect these to be included.