Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting audience in ServiceAccountCredentials #755

Closed
jpharaoh-google opened this issue Oct 1, 2021 · 4 comments
Closed

Allow setting audience in ServiceAccountCredentials #755

jpharaoh-google opened this issue Oct 1, 2021 · 4 comments
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@jpharaoh-google
Copy link

Problem:

Trying to use service account credentials to access a Google API from a restricted network. The only external access available is via a reverse proxy configured by the network security team.

There is an endpoint configured to connect to the OAuth2 endpoint, and this can be configured using ServiceAccountCredentials.Builder.setTokenServerUri. However, this also changes the audience in the JWT, causing the request to be rejected by the upstream server.

Proposed solution:

The simplest solution, I think, is to add extra configuration options to the ServiceAccountCredentials and its Builder to allow the audience and token server URI to be set to different values. Then it would be possible to create this in the normal way, then use toBuilder() to create a new object with the overidden settings.

I think it would make sense to default to still using the same value for audience and URI if the user only sets the URI. This keeps the current behaviour and makes things less confusing in the normal case. If there was an extra option, something like setOverrideTokenAudience, and the audience would only be different from the URI if both were set, then this would be fairly simple to achieve.

Alternatives:

It is already possible to make this work, by keeping the default token URI, and providing a custom HttpTransportFactory which modifies the URI in the request. The problem is that this requires creating many custom classes. Also, I think the intention is much clearer to do this in the credentials layer, rather than messing around in the transport layer.

Perhaps there's another way to do this with subclassing or something clever, but many things are not accessible. For example, ServiceAccountCredentials has no public or protected constructors, so I don't think this is possible.

@suztomo suztomo added the priority: p3 Desirable enhancement or fix. May not be included in next release. label Oct 4, 2021
@suztomo
Copy link
Member

suztomo commented Oct 4, 2021

@arithmetic1728 (I'm doing J-team rotation today but I lack the knowledge of google-auth-library-java) It seems that you're familiar with ServiceAccountCredentials.Builder. What do you think about this feature request?

@arithmetic1728
Copy link
Contributor

@jpharaoh-google I think probably you can subclass SeviceAccountCredentials, provide audience to this new class, and override public Map<String, List<String>> getRequestMetadata(URI uri) to ignore the uri and use your audience.

https://github.com/googleapis/google-auth-library-java/blob/main/oauth2_http/java/com/google/auth/oauth2/ServiceAccountCredentials.java#L1011

@silvolu
Copy link

silvolu commented Oct 20, 2021

This should be the same as googleapis/google-auth-library-python#784, when exchanging a self-signed JWT for a google access token, the audience should not change based on the URI and should always be https://oauth2.googleapis.com/token

@westarle
Copy link

See #833 -- feel free to reopen if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

7 participants
@suztomo @silvolu @TimurSadykov @westarle @jpharaoh-google @arithmetic1728 and others