X-Endpoint-API-UserInfo does not include claims

[DazWilkin]

This isn't an issue for me but is an inconsistency.

Google's documentation here and here specifies that the metadata key X-Endpoint-API-Userinfo key added by ESP includes claims:

"If available in the JWT, ESP adds the values of the id, issuer, email, and audiences properties to the encoded JSON object. It also adds the claims property that includes the original payload of the JWT. The JSON object has the form: (see below)"

{
  "id": "from-sub",
  "issuer": "from-iss",
  "email": "from-email",
  "audiences": ["from-aud"],
  "claims": {
     original-jwt-payload
   }
}

ESPv2 does not appear to include claims and it does not reflect the documented structure which maps e.g. sub --> id, iss --> issuer.

I receive the following (pretty-printed) which is an accurately (!) decoded version of the Firebase JWT plus e.g. firebase provided by the service config:

{
    "name": "Daz Wilkin",
    "iss": "https://securetoken.google.com/${FIREBASE_PROJECT}",
    "aud": "${FIREBASE_PROJECT}",
    "auth_time": 1623860883,
    "user_id": "${USER_ID}",
    "sub": "${USER_ID}",
    "iat": 1623869859,
    "exp": 1623873459,
    "email": "my@email.com",
    "email_verified": true,
    "firebase": {
        "identities":{
            "microsoft.com": ["[[REDACTED]]"],
            "email":["my@email.com"]
        },
        "sign_in_provider":"microsoft.com"
    }
}

In summary:

• no claims
• no remapping

[nareddyt]

From the pages you linked to, there is a little bit of text at the bottom:

If you are using ESPv2, the format of the value in the header is different. See Migrate to Extensible Service Proxy V2 Beta for more information on the new format.

The format ESPv2 uses is documented here: https://cloud.google.com/endpoints/docs/grpc/migrate-to-esp-v2#handle-jwt

[nareddyt]

The text you quoted above

If available in the JWT, ESP adds the values of the id, issuer, email, and audiences properties to the encoded JSON object. It also adds the claims property that includes the original payload of the JWT. The JSON object has the form: (see below)

Is for ESP (https://github.com/cloudendpoints/esp). The new structure with ESPv2 is what you care about :)

[TAOXUY]

Just to be precious on that doc.

In ESPv2, the X-Endpoint-API-UserInfo header only contains the Base64Url encoded payload of the original JWT, without modification.

We pass through what it is.

[DazWilkin]

@nareddyt yes, I included both references but, you're correct, I'm only using ESPv2 and can only comment on it. I included the other reference because the X-Endpoint-API-UserInfo struct is similar for both ESP and ESPv2; I assumed (perhaps incorrectly) that if it wasn't mapping correctly for ESPv2, then it may not be doing so for ESP either.

@TAOXUY I didn't see that comment... that is indeed what I'm observing. So, why the preamble "The JSON object has the form: ...". It doesn't. It's simply "the Base64Url encoded payload of the original JWT, without modification". Isn't that what the document should (only) say?

i.e.

---

Handle JWTs in the backend service

When using JWTs to perform authentication, both proxies send the authentication result in the X-Endpoint-API-UserInfo header to the backend API. We recommend using this header instead of the original Authorization header, as the original Authorization header may be modified in serverless platforms. However, the format of the header has been changed for ESPv2.

In ESP, the X-Endpoint-API-UserInfo header contains a Base64Url encoded JSON object that contains the JWT payload and a few specific fields added by ESP.

If available in the JWT, ESP adds the values of the sub, iss, email, and aud properties to the encoded JSON object.

In ESPv2, the X-Endpoint-API-UserInfo header only contains the Base64Url encoded payload of the original JWT, without modification.

If your backend service expects the X-Endpoint-API-UserInfo header to use the ESP JSON format, you must update your service to handle the new, simplified format.

See Using a custom method to authenticate users and Authentication between services for more on using JWTs with authentication.

[TAOXUY]

I see. The context is distractive and confusing. I will update the doc.