Closed ejona86 closed 1 year ago
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.
@ejona86 It seems from the discussion that we are happy with the current state and could close this.
Taken from #1914 to avoid throwing that issue off-topic.
@saturnism wrote:
@ejona86 wrote:
@saturnism wrote: