Audiences not being passed as part of claims (when more than 1 present as a list)

[maroux]

1. Deploy to app engine flex with following config in app.yaml:

endpoints_api_service:
  name: hello.example.com
  rollout_strategy: managed

2. Deploy service config as such:

host: hello.example.com
securityDefinitions:
  auth0_jwk:
    authorizationUrl: ''
    flow: implicit
    type: oauth2
    x-google-issuer: https://<TENANT>.auth0.com/
    x-google-jwks_uri: https://<TENANT>.auth0.com/.well-known/jwks.json
    x-google-audiences: https://hello.example.com
x-google-endpoints:
- name: hello.example.com
  allowCors: true
security:
- auth0_jwk: []

3. Hit the app engine endpoint with a token that looks like this:

{
  "header": {...},
  "payload": {
    "iss": "https://<TENANT>.auth0.com/",
    "sub": "<ID>",
    "aud": [
      "https://hello.example.com",
      "https://<TENANT>.auth0.com/userinfo"
    ],
    "iat": <>,
    "exp": <>,
    "azp": <>,
    "scope": "openid email",
    "permissions": []
  },
  "signature": <>
}

4. Look at X-Endpoint-API-UserInfo header received by the app engine app:

{
    "claims": "{\"iss\":\"https://<TENANT>.auth0.com/\",\"sub\":\"<ID>\",\"aud\":\"\",\"iat\":<>\"exp\":<>,\"azp\":\"<>\",\"scope\":\"openid email\",\"permissions\":[]}","issuer":"https://<TENANT>.auth0.com/","id":"<ID>"}

Bug: aud is empty here
Expected: aud = https://hello.example.com

The same workflow when deployed using Cloud Run (except x-google-backend is included in service swagger yaml), creates a user info header that includes the audience field correctly.

[qiwzhang]

Need to debug it. It is possible that something is wrong with this code

Especially when aud is a list, instead of a single string.

[maroux]

Correction - this doesn't work with Cloud Run either.

[maroux]

Yeah looks like it - multiple audiences are removed for validation with grpc library (which doesn't support it). And since claims are serialized by grpc library as well, it's never serialized. Perhaps it's easier to just put audiences at the top level rather than in claims ?

Alternatively, perhaps audiences list should be serialized into a string with space separator - this may be off-spec however.

[qiwzhang]

Could you try new new ESPv2 for Cloud Run? The doc is here

[maroux]

@qiwzhang looks like it works fine with v2 (with the caveat that there is no outer wrapper object within which claims dict resides).

Looks like v2 is based on Envoy - do you know if it supports multiple backends? That's how we're using it right now, and I'd rather not deploy one proxy Cloud Run for every microservice..

[nareddyt]

ESPv2 can be used as a Serverless API Gateway, a "one proxy to many backends" deployment mode. Take a look at the x-google-backend open API extension.

https://cloud.google.com/endpoints/docs/openapi/openapi-extensions#x-google-backend

You may find the quick start helpful. It's updated with instructions for ESPv2 (mostly the same as v1).

https://cloud.google.com/endpoints/docs/openapi/get-started-cloud-run

[TAOXUY]

@maroux for ESPv2 we will have feature of supporting mutli grpc server listening on same host soon, which has been implemented in V1. We won't support multi backends on different host in the near future.

[maroux]

@nareddyt I don't think so. Unless I'm missing something, v2 serverless requires ENDPOINTS_SERVICE_NAME env var and that value can only be a single service name.

[nareddyt]

@maroux let me clear up some of the confusion:

1. If you follow all steps of the Cloud Run tutorial linked above, this condition will always be true. So it will never look for ENDPOINTS_SERVICE_NAME.
2. ENDPOINTS_SERVICE_NAME is different from the backend URL. ENDPOINTS_SERVICE_NAME refers to the name of the OpenAPI spec that you deployed. This OpenAPI spec can have x-google-backend for different methods. So that one spec can redirect requests to multiple backends.

ESPv2 Beta for Cloud Run is designed to be backwards compatible with ESP for Cloud Run with minimal changes to the service config. x-google-backend definitely works, I have manually tested this in the past. We also have a lot of integration tests for backend routing that follow the same format as ESP.

Also, you may find this example useful. You can see that a different x-google-backend is defined for each method in the OpenAPI spec. Take a look at the other files in that directory, this x-google-backend address is propagated to all the configs.

[maroux]

@nareddyt Ah I see what you mean. This is still different from how I'm using it (which isn't supported out of the box):

1. We have several microservices which are fronted by ESP
2. Each service has it's own swagger spec and deploys an endpoint configuration
3. ESP config:
   1. experimental_enable_multiple_api_configs
   2. custom nginx template that has a different server block for each service so that a different endpoints config can be loaded based on domain name
   3. ENDPOINTS_SERVICE_NAME = list of services

This allows us to deploy microservices independently from each other and also have just one ESP for all of them.

So, I suppose my question is - would esp v2 support multiple endpoints configurations in the future?

[qiwzhang]

@maroux you are really an advance user of ESPv1. Unfortunately, ESPv2 will not support "experimental_enable_multiple_api_configs" feature in the near future.

[qiwzhang]

@maroux we will try to add "audiences" at the top level of UserInfo as list of strings.