Remove Google credentials from the core gRPC libraries

[ejona86]

Taken from #1914 to avoid throwing that issue off-topic.

@saturnism wrote:

Would it be possible not to have Google credentials in the core gRPC libraries? gRPC as a core RPC framework probably don't need Google credentials.

@ejona86 wrote:

@saturnism, only grpc-auth depends on google-auth-library-credentials. Also, "Google credentials" isn't in google-auth-library-credentials, but in google-auth-library-oauth2-http. CallCredentials is in grpc-core, so there should be no unnecessary dependencies.

@saturnism wrote:

it seems grpc-auth is only dealing w/ google credentials. @garrettjonesgoogle do you actually need this from gcloud-java? It was a discussion point of dependency conflicts.

grpc-auth feels very much core, as the core auth supplement library; is there a plan to add additional auth providers to grpc-auth?

would it make sense to have submodule e.g. grpc-auth-google? The point is that... if you need auth in gRPC, you don't necessarily need Google credentials.

[ejona86]

it seems grpc-auth is only dealing w/ google credentials

Really, it is delegating all work to google-auth-library-java. We chose to do that instead of making google-auth-library-java part of gRPC (which was done for C core). While google-auth-library-java is Google-centric, its UserCredentials works with any OAuth provider and its ServiceAccountJwtAccessCredentials works with any JWT-enabled service.

is there a plan to add additional auth providers to grpc-auth

No, because nobody's asked for any. Do you have any in mind? There are dependency concerns here (don't want lots of creep), but it's at least worth proposing. (FWIW, google-auth-library-credentials is very small and lacks any implementations.)

would it make sense to have submodule e.g. grpc-auth-google? The point is that... if you need auth in gRPC, you don't necessarily need Google credentials.

I don't see why that would make sense, given that then grpc-auth would just disappear. I also don't quite understand what you mean by "submodule". Are you just talking about renaming the artifact?

Today, you could implement a Credentials from google-auth-library-java and use it with gRPC. It has no Google baggage and would not bring in any Google-specifics. google-auth-library-credentials has two interfaces and one abstract class (which behaves mostly like an interface, but can be added to over time).

Note that some of this is strange because it was very late when we added the grpc-specific CallCredentials. Before that point, google-auth-library-java's Credentials was gRPC's credential API, to be used with the Auth interceptor. Also, FWIW, the only reason google-auth-library-java is not included in the gRPC repo is because it has users outside of gRPC. Having it split out actually caused some problems, because a piece of JWT creation is transport-specific.

Also, the practical problem currently isn't really "Google" in my mind. The problem is that google-auth-library-oauth2-http depends on https://github.com/google/google-http-java-client , which is caused by the fragmented state of HTTP in Java, not so much Google-isms.

[larry-safran]

@ejona86 It seems from the discussion that we are happy with the current state and could close this.