Summary: an enhancement to allow the jwt_authn filter to extract the JWT from a configurable field in the Authorization or similar header

Description: Where I work, we use a variation of the bearer-token Authorization header,
with the JWT as one of several fields, and not usually the final one. This isn't supported by the current jwt_authn filter.

In the current version of ExtractorImpl::extract(...) in jwt_authn/extractor.cc, (from January 2019, commit 58329ac), the processing is very simple, allowing for a fixed prefix before the JWT (similar to "Bearer "):

        if (!absl::StartsWith(value_str, location_spec->value_prefix_)) {
          // prefix doesn't match, skip it.
          continue;
        }
        value_str = value_str.substr(location_spec->value_prefix_.size());

This doesn't allow for any characters to follow the JWT in the header.

Proposed solution (enhancement): This proposal offers a simple enhancement that would allow for much more flexibility in the syntax of the header (which is canonically "Authorization", but is specified in from_headers).

In essence, the value_prefix would be interpreted more broadly, while maintaining backwards compatibility for existing configurations (in the case where the request is properly formatted).

Instead of requiring that the header value (value_str in the code snippet) start with the value_prefix, and the JWT begin immediately following that, this enhancement

1. searches for the value_prefix anywhere in the header value
2. skips any non-JWT-legal characters (white-space, '=', '"', etc.)
3. takes the JWT as being all subsequent characters up to the first non-JWT-legal character or the end

This will allow for flexible syntax such as any of these:

1. Authorization TagName field1=abc,jwt-value=eyJraWQ...EjBrg,realm=9192
2. special-auth-header token="eyJraWQ...EjBrg",comment="fish tag"
3. Authorization creds={"authLevel": "20", "JWT": "eyJraWQ...EjBrg"}

These are fanciful (and the "..." are ellipses), but a similar header is used where I work.

For the above cases, from_headers would have values:

    from_headers:
    - name: Authorization
      value_prefix: "jwt-value"
    - name: special-auth-header
      value_prefix: token
    - name: Authorization
      value_prefix: JWT

Note on skipping '=' looking for Base64url-encoded characters

As a reminder, Base64url encoding normally permits trailing '=' for padding, but as referenced in RFC-7519 "JSON Web Token (JWT)" § 2, and defined in RFC-7515 "JSON Web Signature (JWS)" § 2, "...all trailing '=' characters [are] omitted...". In any case, these are trailing '=' characters.

See the table in RFC-4648 "Base-N Encodings" § 5.