Determine how to deal with multiple audiences for jwt.Credentials

[theacodes]

JWT bearer credentials require an audience that matches the service URL to work.

Right now, JWT credentials don't require an audience when constructing, but instead can generate a one-time token during before_request. This works, but unfortunately this is pretty awful performance-wise.

My best as to why we did this is because within one client we may actually be talking to two different audiences. Consider pubusb - there is the publisher audience (https://pubsub.googleapis.com/google.pubsub.v1.Publisher) and the subscriber audience (https://pubsub.googleapis.com/google.pubsub.v1.Subscriber).

I see two options for making this better:

1. Store a cache of tokens for every given audience. This has lots of problems.
2. Make our clients pass in credentials.with_claims(audience='...') (example here) instead of just credentials. This means that we'll essentially be using a copy of the credentials for each audience (pubsub will have two), so they will likely refresh at different times (which I don't consider a problem).

@dhermes @lukesneeringer thoughts?

[dhermes]

1. I don't understand the "pretty awful performance-wise" piece you are referring to
2. I don't see much wrong with asking the caller to be aware of the audience. Libraries like google-cloud-python can handle this without being a burden on users.

[theacodes]

I don't understand the "pretty awful performance-wise" piece you are referring to

Generating a new JWT for every request adds a lot of overhead. It's much better to only generate that once.

I don't see much wrong with asking the caller to be aware of the audience.

Great, I'll do what I described in (2) above. I'll remove the per-request one-time JWT logic. We can always add that back as a new credential type later if needed, but if we hit 1.0 with that behavior we're married to it.