esp-v2
esp-v2 copied to clipboard
GoogleCloudPlatform
Accessing JWT tokens in cookies
I am using a JS SPA frontend which talks to the API backend via Endpoints (ESPv2) hosted on Cloud Run. ESPv2 invokes the Cloud Run backend via native GCP IAM. All user requests go through a load balancer that routes according to path, so the domain is common to all components from the end user's perspective.
We would like to be able to store and transmit JWT tokens with cookies.
The frontend directs an unauthenticated user to login to Azure AD and receives a token back. For the frontend to allow the user to get a request through ESPv2, the token needs to be in an HTTP header ('Authorization: ' as usual).
But this requires that on the user end the token is stored in the browser's localStorage (or sessionStorage) which is generally considered bad practice. We want to store the token in cookies so that we can set httpOnly, secure and sameSite flags.
Is there a way (or could a way be created) for ESPv2 to instead parse the cookies to look for a token in particular cookie key? Our frontend framework allows this, but it doesn't work with our implementation of Endpoints.
EG I'm thinking extended x-google-jwt-locations to something like below
x-google-jwt-locations:
- header: "Cookie"
value_prefix: "Bearer "
cookie-key: "auth._token.aad"
Which would find the JWT token in amongst the below (shortened, redacted) sample cookies:
auth._token.aad=Bearer%20<JWT-TOKEN-HERE>; auth._token_expiration.aad=1646369191000; auth.strategy=aadAP
PS I noticed there's already some parsing of cookies for API keys - maybe that could be extended to extract other keys?
Hmm, it is a config issue. ESPv2 is using envoy jwt_authn filter, its config supports extracting token from cookie. But ESPv2 is using Google service config, or OpenAPI config, neither supports cookes.
Here is the OpenAPI externsion jwt_location
Here is Google service config Jwt_location.
I will keep this issue as enhancement.
When you guys are next prioritising the backlog, please consider if this could be done. It's necessary for all cases where ESPv2 mediates API calls from a browser.
