Cloud Run + ESP Using Firebase Auth - JWT altering?

[Elliot Berman]

I'm trying to use an ESP to authenticate requests to a service hosted in Cloud Run. However, the Cloud run service also makes use of the JWT to get user info and authorize certain actions. In our DB, we have user permissions which also include a firebase auth ID from Firebase so we can map between the two. However, it seems that ESP will alter the JWT before forwarding it to the service, by changing the audience of the JWT from the project id to the host name of the backend it sits in front of (the JWT I logged serverside does not match the JWT sent if going through the ESP).

This creates a problem because the backend, when attempting to decode the JWT and get the firebase user's auth id, will throw an error because of mismatching audience. We don't load a config file in Cloud Run (can't ship credentials with the Docker container), so I'm not sure how to get the backend code to possibly expect something different in terms of JWT audience. This also seems like a problem for service-to-service calls, because a request that forwards headers from an external client will change audiences every time it goes through an ESP in this model.

My question essentially is, is there a way to either stop this behavior (changing the JWT audience) on ESP's part, or in the firebase_admin SDK is there a way to allow multiple audiences to get around this? My preference would be for the former solution but open to whatever plays most nicely with Cloud Run and Firebase auth.

[Wayne Zhang]

This is a known issue in ESP; it always attached its ID token in the request, overwrite the original one.   The fix is on the way, you can add "disable_auth" in the x-google-backend to disable it.   But the fix will be released Jan. 2020 due to holiday release frozen. 

Thanks

-Wayne

[Elliot Berman]

Thanks for the quick reply. I didn’t see any docs for disable_auth; do I use this in addition to the address field in the x-google-backend part of the yaml? Also, will this pass through any un-authenticated requests?

[Xuyang(Jason) Tao]

Hi Elliot,

We just checked with corresponding team and the fix change would be released soon(hopefully, next week). Once it is rollout, we will update the doc right away.

[Wayne Zhang]

Yes,  ESP will pass requests you specified in your OpenAPI spec.  Without "diable_auth" flag in x-google-backend,  ESP will add its own ID token in "Authorization" header.  With that flag, ESP will not do that.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/1790a783-e6f5-413e-a50b-e15178b6b1f7%40googlegroups.com.

[Elliot Berman]

Ok sounds good - thanks for the help. We’ll use disable_auth for now until the fix is shipped.

[Teju Nareddy]

Hi Elliot, sorry for the confusion.

What Wayne meant to say: the fix is to use disable_auth. This fix is not pushed to production yet, but it will be pushed later next week. Once it's in production, the documentation should also be updated and you can use it.

There is no known workaround for this issue right now, and you can't use disable_auth yet. The easiest course of action is to wait until next week for the fix.

Please let us know if this feature request is urgent, but keep in mind that we don't control the timeline for the production push.

Thanks

[Elliot Berman]

Got it. Are there plans to correct the behavior where the ESP changes the JWT, will disable_auth be the only option going forward?

[Wayne Zhang]

disable_auth is the only option going forward if you wan to keep your original JWT.   

[Elliot Berman]

Given that, what is the recommended flow for Firebase auth users of ESP/Cloud Run who are looking to access info from the auth headers of the original request? Pass them in a duplicate header that won't be touched by ESP, or write our own ESP-like service, or something else?

[Wayne Zhang]

Could you elaborate on what kind of JWT info your backend is expecting?  What kind of authentication  tasks you want ESP to perform?

[Elliot Berman]

We were initially expecting a JWT as issued from firebase. We mainly just wanted to use ESP to authenticate the request (make sure requests didn't come straight through from non-firebase authenticated). We found something that seems to mostly get around it in the docs here:

https://cloud.google.com/endpoints/docs/openapi/authenticating-users-firebase

What threw us off a bit on here was this statement: "ESP forwards all headers it receives, including the original authorization header, to the API." However, we think we'll be able to work with the X-Endpoint-UserInfo header to make something work with the ESP. Thanks for the clarification along the way.