Dialogflow gRPC client won't authenticate with a service key

[chrylis]

Environment details

1. Dialogflow CX SessionsClient
2. OS type and version: Gentoo Linux
3. Java version: OpenJDK 11
4. Dialogflow version: 0.19.0

Steps to reproduce

1. Create a service account with permission to detectIntent on an agent.
2. Export a key as JSON.
3. Create a SessionSettings client using that JSON key and the default gRPC transport.
4. Execute a detectIntent call.
5. The call will throw with an UNAUTHENTICATED error.

Code example

var settings = SessionsSettings.newBuilder()
        .setCredentialsProvider(FixedCredentialsProvider.create(jsonKey))
        .setEndpoint('us-central1-dialogflow.googleapis.com:443')
        .build()
var client = SessionsClient.create(settings)

String session = SessionName.of(...).toString()
var request = DetectIntentRequest.newBuilder()...
client.detectIntent(request)

Stack trace

Caused by: io.grpc.StatusRuntimeException: UNAUTHENTICATED: Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.

Any additional information below

Changing the client-settings invocation from SessionsSettings.newBuilder() (gRPC) to SessionsSettings.newHttpJsonBuilder() (REST) causes the calls to start working, demonstrating that the problem is in the infrastructure (either client or server-side) and not in the configuration (e.g., credentials with insufficient permissions). Is is possible that gRPC fails to correctly translate a service-account key into gRPC-compatible credentials?

[lqiu96]

Taking a look. Let me try and reproduce this and I'll get back to you.

[lqiu96]

Hi @chrylis, would you be able to help us by trying two things:

1. Create an agent in the global region and try to run the code with both transport flows (gRPC and HttpJson). The endpoint would be dialogflow.googleapis.com for the global region instead of us-central1-dialogflow.googleapis.com:443.
2. If you could help trace the request's authorization header? We think it may be due to the header token value.

Our suspicion is that the token is a result of the authorization flow that gRPC is using.

[chrylis]

I have tried to determine the authorization header when using gRPC, but I couldn't figure out where to either log or inspect it. (This was the first direction I went when trying to debug the problem.)

[lqiu96]

@chrylis Apologies for having to re-direct you to another project, but I'm not super familiar with these auth related issues. I can slowly play around with this again.

For better guidance (and most likely a faster solution), would you mind re-opening this issue in https://github.com/googleapis/google-auth-library-java?