2

I am unable to create an OpenID Connect identity token to send as bearer token for a cloud run request. From the apps script I cannot make a token using (ScriptApp.getIdentityToken()) which has an audience the Google front end will allow through. When I arrange for the script to send a token instead that I've made with gcloud print-identity-token--identical except for the audience--that invocation succeeds.

Note I believe this may the same issue as seen here: Securely calling a Google Cloud Function via a Google Apps Script.

Also google cloud authentication with bearer token via nodejs.

One workaround suggests restructuring the GCP/Apps Script projects. Others mostly use service accounts, and use service account keys. I believe it's possible using IAM and use of google auth for one to produce a usable SA identity token (short term service account credentials) but I can't demonstrate it.

I am working around this currently, but I'd like to understand the essential problem. I think it has something to do with the cloud run service's hosting project's Oauth consent screen, and the inability to add the associated web application client-id as a scope.

mohawkTrail
  • 606
  • 1
  • 7
  • 19

2 Answers2

2

In the Cloud Run docs, there is a section about performing authenticated calls to Cloud Run from other services outside GCP. The process would be the following:

  1. Self-sign a service account JWT with the target_audience claim set to the URL of the receiving service.

  2. Exchange the self-signed JWT for a Google-signed ID token, which should have the aud claim set to the above URL.

  3. Include the ID token in an Authorization: Bearer ID_TOKEN header in the request to the service.

Step 1 could be performed as described here while setting the aud claim to the URL of the receiving service. I believe ScriptApp.getIdentityToken() does not set the proper audience to the JWT

For step 2, I believe you should perform a POST request to https://oauth2.googleapis.com/token with the appropriate parameters grant_type and assertion. This is explained in the "Making the access token request" section here

The resulting token should be used in step 3

Community
  • 1
  • 1
Jose V
  • 1,356
  • 1
  • 4
  • 12
  • Thank you Jose. I hope to try this out when I circle back to this issue later on. – mohawkTrail Jun 25 '20 at 01:56
  • The examples showed use of a service account as identity provider, which is something I wished to avoid (and have avoided with my workaround). – mohawkTrail Jun 25 '20 at 02:02
  • Could you please share the workaround that you are using at the moment? It may be helpful for other users facing a similar issue and will be helpful to understand the situation a bit more – Jose V Jun 26 '20 at 13:36
  • It seems that what you want is what's described [here](https://cloud.google.com/iap/docs/authentication-howto#authenticating_a_user_account). However, it's stated in the [docs](https://cloud.google.com/run/docs/authenticating/service-to-service#calling_from_outside_gcp) that IAP is not yet supported for Cloud Run Fully managed – Jose V Jun 26 '20 at 14:11
  • There are two chief alternatives to work around this that I see. 1. Give up on getting a valid id token for the user (who's already logged in) and create a service account id token with the requisite scopes. 2. Move the deployment of the cloud run service to the apps script project GCP project. Which I did and it works. Access to the service is via IAM to the user (not to the ghost of the spreadsheet), and I have the user's ID and the token, too. – mohawkTrail Jun 26 '20 at 17:31
1

I just wrote an article on that topic and I provide an easy way based on the service account credential API. Let's have a look on it and we can discuss further if required.

guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • This is a good explanation of the whole rigamarole, Guillaume. I do think that very few folks will be discovering your bread crumbs and following. In addition, it requires linking your apps script project with the cloud run project. Not so composable. Partly that's why I was so dissatisfied with my own work-around. – mohawkTrail Nov 03 '21 at 19:12