envoyproxy/envoy

JWT Claim to Header extraction fails when claim is a URL-like string

Open

#33,603 opened on Apr 17, 2024

View on GitHub
 (11 comments) (0 reactions) (0 assignees)C++ (5,373 forks)batch import
area/jwt_authnhelp wantedquestion

Repository metrics

Stars
 (27,997 stars)
PR merge metrics
 (Avg merge 8d) (378 merged PRs in 30d)

Description

When attempting to perform a JWT Claim to Header extraction, envoy will fail to do the extraction if the claim is a URL-like string, for instance http://example.org/some_claim, and the fail is possibly silently, as I've been unable to locate logs with the failure.

Given a claim like

{
  "iss": "http://example.org/",
  "sub": "johndoe@example.org",
  "iat": 1712240289,
  "exp": 1743776289,
  "aud": "http://example.org/",
  "flavour": "chocolate",
  "parent_token": "abc",
  "some_url_value": "http://example.org/about",
  "http://example.org/parent_token": "xyz"
}

on the resulting request headers, the claim "http://example.org/parent_token": "xyz" will not have been extracted.

Here's the claim_to_headers block:

claim_to_headers:
- header_name: cookie
  claim_name: flavour
- header_name: x-subject
  claim_name: sub
- header_name: x-simple-claim
  claim_name: parent_token
- header_name: x-url-value-claim
  claim_name: some_url_value
- header_name: x-url-key-claim
  claim_name: http://example.org/parent_token
- header_name: x-quoted-claim
  claim_name: 'http://example.org/parent_token'
- header_name: x-regex-1-claim
  claim_name: http:\/\/example.org\/parent_token
- header_name: x-regex-2-claim
  claim_name: http:\\/\\/example\\.org\\/parent_token

In order to show this, I've created a docker compose based reproduction at CelsoSantos/envoy-jwt-claim-extraction, which contains a README.md detailing the steps to reproduce and showcase the issue.

Now, there are some open questions here, namely:

  1. Is this not expected functionality?
  2. If it IS expected functionality, where and why is it breaking? It's not clear from the jwt logs nor others inspected. Which log should expose the error message?
  3. If it needs to be treated as a regex, what is the correct way to escape the string? go-format? javascript? Could an example be provided?

Contributor guide