gRPC auth information

[ale...@gmail.com]

The docs for gRPC auth say that no auth information is provided to the client. Moreover, there is no way to validate scope in an API configuration, only the issuer and audience. This significantly limits the ability to usefully make complex auth systems, and thereby limits the service in general.

Is it possible, as a workaround, to take the Authorization header as a system parameter and check the scopes in my application, relying on the ESP to have validated the JWT?

The only other workaround I can think of is to use the audience claim as a makeshift scope claim, but that's awful.

In the longer term, is there support for scope checking in the works, and/or passing the appropriate info to the gRPC server?

[Brad Friedman]

Limin or Yang, any thoughts here? Thanks!

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endpoints+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/318d750d-d662-4bd0-8d5d-15a417f332da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[limi...@google.com]

Hi,

By "no auth information is provided to the client", do you mean "no auth information is provided to the server"?

"audience" is the standard JWT claim that identifies the recipient that the JWT is intended for (https://tools.ietf.org/html/rfc7519#section-4.1.3). "scope" is not a standard JWT claim, so ESP is not validating it. Cloud you explain what you use scope for? 

And what is the client protocol? HTTP or gRPC? 

[Alexis Hunt]

On Mon, Feb 27, 2017 at 8:35 PM <limi...@google.com> wrote:

Hi,

By "no auth information is provided to the client", do you mean "no auth information is provided to the server"?

Yes, sorry, I mean my backend server which is being wrapped by ESP. 

"audience" is the standard JWT claim that identifies the recipient that the JWT is intended for (https://tools.ietf.org/html/rfc7519#section-4.1.3). "scope" is not a standard JWT claim, so ESP is not validating it. Cloud you explain what you use scope for? 

Ah, hmm, looks like I was confusing myself between OAuth and JWT here! I'd like to be able to incorporate authorization and not just authentication, though, so I guess I'd need to make different audiences depending on which API method was authorized? Or am I misunderstanding how to use JWTs for auth here completely?

And what is the client protocol? HTTP or gRPC?

It could be either, but I am much more concerned about HTTP. Both use bearer tokens, though, right?

Alexis

[Alexis Hunt]

On Mon, Feb 27, 2017 at 9:11 PM Alexis Hunt <ale...@gmail.com> wrote:

On Mon, Feb 27, 2017 at 8:35 PM <limi...@google.com> wrote:

Hi,

By "no auth information is provided to the client", do you mean "no auth information is provided to the server"?

Yes, sorry, I mean my backend server which is being wrapped by ESP. 

"audience" is the standard JWT claim that identifies the recipient that the JWT is intended for (https://tools.ietf.org/html/rfc7519#section-4.1.3). "scope" is not a standard JWT claim, so ESP is not validating it. Cloud you explain what you use scope for? 

Ah, hmm, looks like I was confusing myself between OAuth and JWT here! I'd like to be able to incorporate authorization and not just authentication, though, so I guess I'd need to make different audiences depending on which API method was authorized? Or am I misunderstanding how to use JWTs for auth here completely?

I dug into this a bit more, and it looks like this is a feature of auth0, though I need to investigate more to figure out how it actually works and how to use it. It certainly doesn't seem well-supported.

But I did a little bit more investigation on my end, and even with an HTTP request, the ESP is putting the bearer token into the authorization metadata field. It would be useful to update https://cloud.google.com/endpoints/docs/authenticating-users-grpc to indicate that this is the case, as that is what got me confused in the first place into thinking I had no way to learn about what user I have, since I can just check the sub claim on the bearer token. It could be a tad cleaner, but it'll do for now.

Alexis

[limi...@google.com]

ESP only accepts JWT. The audience of the JWT should be the URL of the backend service name. On the other hand, Google APIs accept opaque OAuth tokens, which contain "scope" fields. 

Thanks for the feedback! You are right that regardless your client uses HTTP or gRPC protocol, the authentication header (containing the JWT) is always passed to the backend server. The current description on gRPC authentication doc is misleading. We will update the doc to make the description more accurate. 

[Yang Guan]

+Lizan Zhou are we passing anything via grpc metadata? If yes, can we do that to carry verified JWT claims?

Thanks,

Yang

On Mon, Feb 27, 2017 at 3:40 PM Brad Friedman <frie...@google.com> wrote:

Limin or Yang, any thoughts here? Thanks!

On Mon, Feb 27, 2017 at 3:37 PM, <ale...@gmail.com> wrote:

The docs for gRPC auth say that no auth information is provided to the client. Moreover, there is no way to validate scope in an API configuration, only the issuer and audience. This significantly limits the ability to usefully make complex auth systems, and thereby limits the service in general.

Is it possible, as a workaround, to take the Authorization header as a system parameter and check the scopes in my application, relying on the ESP to have validated the JWT?

The only other workaround I can think of is to use the audience claim as a makeshift scope claim, but that's awful.

In the longer term, is there support for scope checking in the works, and/or passing the appropriate info to the gRPC server?

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.

[Lizan Zhou]

The gRPC Guide is out-dated, we will update it soon.

gRPC server will receive a metadata 'x-endpoint-api-userinfo' (Note: all lowercase since gRPC metadata key is lowercase only) when authentication was successful. The format of that is described in https://cloud.google.com/endpoints/docs/authenticating-users#receiving_auth_results_in_your_api

On Mon, Feb 27, 2017 at 11:10 PM, Yang Guan <yang...@google.com> wrote:

+Lizan Zhou are we passing anything via grpc metadata? If yes, can we do that to carry verified JWT claims?

Thanks,

Yang

On Mon, Feb 27, 2017 at 3:40 PM Brad Friedman <frie...@google.com> wrote:

Limin or Yang, any thoughts here? Thanks!

On Mon, Feb 27, 2017 at 3:37 PM, <ale...@gmail.com> wrote:

The docs for gRPC auth say that no auth information is provided to the client. Moreover, there is no way to validate scope in an API configuration, only the issuer and audience. This significantly limits the ability to usefully make complex auth systems, and thereby limits the service in general.

Is it possible, as a workaround, to take the Authorization header as a system parameter and check the scopes in my application, relying on the ESP to have validated the JWT?

The only other workaround I can think of is to use the audience claim as a makeshift scope claim, but that's awful.

In the longer term, is there support for scope checking in the works, and/or passing the appropriate info to the gRPC server?

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endpoints+unsubscri...@googlegroups.com.