JWT Authentication (proto)

This extension has the qualified name envoy.filters.http.jwt_authn

Note

This extension is intended to be robust against untrusted downstream traffic. It assumes that the upstream is trusted.

Tip

This extension extends and can be used with the following extension category:

envoy.filters.http

This extension must be configured with one of the following type URLs:

type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.PerRouteConfig

JWT Authentication configuration overview.

extensions.filters.http.jwt_authn.v3.JwtProvider

[extensions.filters.http.jwt_authn.v3.JwtProvider proto]

Please see following for JWT authentication flow:

A JwtProvider message specifies how a JSON Web Token (JWT) can be verified. It specifies:

issuer: the principal that issues the JWT. If specified, it has to match the iss field in JWT.
allowed audiences: the ones in the token have to be listed here.
how to fetch public key JWKS to verify the token signature.
how to extract JWT token in the request.
how to pass successfully verified token payload.

Example:

issuer: https://example.com
audiences:
- bookstore_android.apps.googleusercontent.com
- bookstore_web.apps.googleusercontent.com
remote_jwks:
  http_uri:
    uri: https://example.com/.well-known/jwks.json
    cluster: example_jwks_cluster
    timeout: 1s
  cache_duration:
    seconds: 300

{
  "issuer": ...,
  "audiences": [],
  "remote_jwks": {...},
  "local_jwks": {...},
  "forward": ...,
  "from_headers": [],
  "from_params": [],
  "from_cookies": [],
  "forward_payload_header": ...,
  "pad_forward_payload_header": ...,
  "payload_in_metadata": ...,
  "header_in_metadata": ...,
  "failed_status_in_metadata": ...,
  "clock_skew_seconds": ...,
  "jwt_cache_config": {...},
  "claim_to_headers": []
}

issuer

(string) Specify the principal that issued the JWT, usually a URL or an email address.

It is optional. If specified, it has to match the iss field in JWT, otherwise the JWT iss field is not checked.

Note: JwtRequirement allow_missing and allow_missing_or_failed are implemented differently than other JwtRequirements. Hence the usage of this field is different as follows if allow_missing or allow_missing_or_failed is used:

If a JWT has iss field, it needs to be specified by this field in one of JwtProviders.
If a JWT doesn’t have iss field, one of JwtProviders should fill this field empty.
Multiple JwtProviders should not have same value in this field.

Example: https://securetoken.google.com Example: 1234567-compute@developer.gserviceaccount.com

audiences

(repeated string) The list of JWT audiences are allowed to access. A JWT containing any of these audiences will be accepted. If not specified, will not check audiences in the token.

Example:

audiences:
- bookstore_android.apps.googleusercontent.com
- bookstore_web.apps.googleusercontent.com

remote_jwks

(extensions.filters.http.jwt_authn.v3.RemoteJwks) JWKS can be fetched from remote server via HTTP/HTTPS. This field specifies the remote HTTP URI and how the fetched JWKS should be cached.

Example:

remote_jwks:
  http_uri:
    uri: https://www.googleapis.com/oauth2/v1/certs
    cluster: jwt.www.googleapis.com|443
    timeout: 1s
  cache_duration:
    seconds: 300

JSON Web Key Set (JWKS) is needed to validate signature of a JWT. This field specifies where to fetch JWKS.

Precisely one of remote_jwks, local_jwks must be set.

local_jwks

(config.core.v3.DataSource) JWKS is in local data source. It could be either in a local file or embedded in the inline_string.

Example: local file

local_jwks:
  filename: /etc/envoy/jwks/jwks1.txt

Example: inline_string

local_jwks:
  inline_string: ACADADADADA

JSON Web Key Set (JWKS) is needed to validate signature of a JWT. This field specifies where to fetch JWKS.

Precisely one of remote_jwks, local_jwks must be set.

forward: (bool) If false, the JWT is removed in the request after a success verification. If true, the JWT is not removed in the request. Default value is false. caveat: only works for from_header & has no effect for JWTs extracted through from_params & from_cookies.

from_headers

(repeated extensions.filters.http.jwt_authn.v3.JwtHeader) Two fields below define where to extract the JWT from an HTTP request.

If no explicit location is specified, the following default locations are tried in order:

1. The Authorization header using the Bearer schema. Example:

Authorization: Bearer <token>.

access_token query parameter.

Multiple JWTs can be verified for a request. Each JWT has to be extracted from the locations its provider specified or from the default locations.

Specify the HTTP headers to extract JWT token. For examples, following config:

from_headers:
- name: x-goog-iap-jwt-assertion

can be used to extract token from header:

``x-goog-iap-jwt-assertion: <JWT>``.

from_params

(repeated string) JWT is sent in a query parameter. jwt_params represents the query parameter names.

For example, if config is:

from_params:
- jwt_token

The JWT format in query parameter is:

/path?jwt_token=<JWT>

from_cookies

(repeated string) JWT is sent in a cookie. from_cookies represents the cookie names to extract from.

For example, if config is:

from_cookies:
- auth-token

Then JWT will be extracted from auth-token cookie in the request.

forward_payload_header

(string) This field specifies the header name to forward a successfully verified JWT payload to the backend. The forwarded data is:

base64url_encoded(jwt_payload_in_JSON)

If it is not specified, the payload will not be forwarded.

pad_forward_payload_header

(bool) When forward_payload_header is specified, the base64 encoded payload will be added to the headers. Normally JWT based64 encode doesn’t add padding. If this field is true, the header will be padded.

This field is only relevant if forward_payload_header is specified.

payload_in_metadata

(string) If non empty, successfully verified JWT payloads will be written to StreamInfo DynamicMetadata in the format as: namespace is the jwt_authn filter name as ``envoy.filters.http.jwt_authn`` The value is the protobuf::Struct. The value of this field will be the key for its fields and the value is the protobuf::Struct converted from JWT JSON payload.

For example, if payload_in_metadata is my_payload:

envoy.filters.http.jwt_authn:
  my_payload:
    iss: https://example.com
    sub: test@example.com
    aud: https://example.com
    exp: 1501281058

header_in_metadata

(string) If not empty, similar to payload_in_metadata, a successfully verified JWT header will be written to Dynamic State as an entry (protobuf::Struct) in envoy.filters.http.jwt_authn namespace with the value of this field as the key.

For example, if header_in_metadata is my_header:

envoy.filters.http.jwt_authn:
  my_header:
    alg: JWT
    kid: EF71iSaosbC5C4tC6Syq1Gm647M
    alg: PS256

When the metadata has envoy.filters.http.jwt_authn entry already (for example if payload_in_metadata is not empty), it will be inserted as a new entry in the same namespace as shown below:

envoy.filters.http.jwt_authn:
  my_payload:
    iss: https://example.com
    sub: test@example.com
    aud: https://example.com
    exp: 1501281058
  my_header:
    alg: JWT
    kid: EF71iSaosbC5C4tC6Syq1Gm647M
    alg: PS256

Warning

Using the same key name for header_in_metadata and payload_in_metadata is not suggested due to potential override of existing entry, while it is not enforced during config validation.

failed_status_in_metadata

(string) If non empty, the failure status ::google::jwt_verify::Status for a non verified JWT will be written to StreamInfo DynamicMetadata in the format as: namespace is the jwt_authn filter name as envoy.filters.http.jwt_authn The value is the protobuf::Struct. The values of this field will be code and message and they will contain the JWT authentication failure status code and a message describing the failure.

For example, if failed_status_in_metadata is my_auth_failure_status:

envoy.filters.http.jwt_authn:
  my_auth_failure_status:
    code: 3
    message: Jwt expired

clock_skew_seconds: (uint32) Specify the clock skew in seconds when verifying JWT time constraint, such as exp, and nbf. If not specified, default is 60 seconds.

jwt_cache_config: (extensions.filters.http.jwt_authn.v3.JwtCacheConfig) Enables JWT cache, its size is specified by jwt_cache_size. Only valid JWT tokens are cached.

claim_to_headers

(repeated extensions.filters.http.jwt_authn.v3.JwtClaimToHeader) Add JWT claim to HTTP Header Specify the claim name you want to copy in which HTTP header. For examples, following config: The claim must be of type; string, int, double, bool. Array type claims are not supported .. code-block:: yaml

claim_to_headers:

name: x-jwt-claim-nested-claim claim: claim.nested.key

This header is only reserved for jwt claim; any other value will be overwrite.

extensions.filters.http.jwt_authn.v3.JwtCacheConfig

[extensions.filters.http.jwt_authn.v3.JwtCacheConfig proto]

This message specifies JWT Cache configuration.

{
  "jwt_cache_size": ...
}

jwt_cache_size: (uint32) The unit is number of JWT tokens, default to 100.

extensions.filters.http.jwt_authn.v3.RemoteJwks

[extensions.filters.http.jwt_authn.v3.RemoteJwks proto]

This message specifies how to fetch JWKS from remote and how to cache it.

{
  "http_uri": {...},
  "cache_duration": {...},
  "async_fetch": {...},
  "retry_policy": {...}
}

http_uri

(config.core.v3.HttpUri) The HTTP URI to fetch the JWKS. For example:

http_uri:
  uri: https://www.googleapis.com/oauth2/v1/certs
  cluster: jwt.www.googleapis.com|443
  timeout: 1s

cache_duration: (Duration) Duration after which the cached JWKS should be expired. If not specified, default cache duration is 10 minutes.

async_fetch

(extensions.filters.http.jwt_authn.v3.JwksAsyncFetch) Fetch Jwks asynchronously in the main thread before the listener is activated. Fetched Jwks can be used by all worker threads.

If this feature is not enabled:

The Jwks is fetched on-demand when the requests come. During the fetching, first few requests are paused until the Jwks is fetched.
Each worker thread fetches its own Jwks since Jwks cache is per worker thread.

If this feature is enabled:

Fetched Jwks is done in the main thread before the listener is activated. Its fetched Jwks can be used by all worker threads. Each worker thread doesn’t need to fetch its own.
Jwks is ready when the requests come, not need to wait for the Jwks fetching.

retry_policy

(config.core.v3.RetryPolicy) Retry policy for fetching Jwks. optional. turned off by default.

For example:

retry_policy:
  retry_back_off:
    base_interval: 0.01s
    max_interval: 20s
  num_retries: 10

will yield a randomized truncated exponential backoff policy with an initial delay of 10ms 10 maximum attempts spaced at most 20s seconds.

retry_policy:
  num_retries:1

uses the default retry backoff strategy. with the default base interval is 1000 milliseconds. and the default maximum interval of 10 times the base interval.

if num_retries is omitted, the default is to allow only one retry.

If enabled, the retry policy will apply to all Jwks fetching approaches, e.g. on demand or asynchronously in background.

extensions.filters.http.jwt_authn.v3.JwksAsyncFetch

[extensions.filters.http.jwt_authn.v3.JwksAsyncFetch proto]

Fetch Jwks asynchronously in the main thread when the filter config is parsed. The listener is activated only after the Jwks is fetched. When the Jwks is expired in the cache, it is fetched again in the main thread. The fetched Jwks from the main thread can be used by all worker threads.

{
  "fast_listener": ...,
  "failed_refetch_duration": {...}
}

fast_listener: (bool) If false, the listener is activated after the initial fetch is completed. The initial fetch result can be either successful or failed. If true, it is activated without waiting for the initial fetch to complete. Default is false.

failed_refetch_duration: (Duration) The duration to refetch after a failed fetch. If not specified, default is 1 second.

extensions.filters.http.jwt_authn.v3.JwtHeader

[extensions.filters.http.jwt_authn.v3.JwtHeader proto]

This message specifies a header location to extract JWT token.

{
  "name": ...,
  "value_prefix": ...
}

name: (string, REQUIRED) The HTTP header name.

value_prefix: (string) The value prefix. The value format is “value_prefix<token>” For example, for “Authorization: Bearer <token>”, value_prefix=”Bearer “ with a space at the end.

extensions.filters.http.jwt_authn.v3.ProviderWithAudiences

[extensions.filters.http.jwt_authn.v3.ProviderWithAudiences proto]

Specify a required provider with audiences.

{
  "provider_name": ...,
  "audiences": []
}

provider_name: (string) Specify a required provider name.

audiences: (repeated string) This field overrides the one specified in the JwtProvider.

extensions.filters.http.jwt_authn.v3.JwtRequirement

[extensions.filters.http.jwt_authn.v3.JwtRequirement proto]

This message specifies a Jwt requirement. An empty message means JWT verification is not required. Here are some config examples:

# Example 1: not required with an empty message

# Example 2: require A
provider_name: provider-A

# Example 3: require A or B
requires_any:
  requirements:
    - provider_name: provider-A
    - provider_name: provider-B

# Example 4: require A and B
requires_all:
  requirements:
    - provider_name: provider-A
    - provider_name: provider-B

# Example 5: require A and (B or C)
requires_all:
  requirements:
    - provider_name: provider-A
    - requires_any:
      requirements:
        - provider_name: provider-B
        - provider_name: provider-C

# Example 6: require A or (B and C)
requires_any:
  requirements:
    - provider_name: provider-A
    - requires_all:
      requirements:
        - provider_name: provider-B
        - provider_name: provider-C

# Example 7: A is optional (if token from A is provided, it must be valid, but also allows
missing token.)
requires_any:
  requirements:
  - provider_name: provider-A
  - allow_missing: {}

# Example 8: A is optional and B is required.
requires_all:
  requirements:
  - requires_any:
      requirements:
      - provider_name: provider-A
      - allow_missing: {}
  - provider_name: provider-B

{
  "provider_name": ...,
  "provider_and_audiences": {...},
  "requires_any": {...},
  "requires_all": {...},
  "allow_missing_or_failed": {...},
  "allow_missing": {...}
}

provider_name

(string) Specify a required provider name.

Only one of provider_name, provider_and_audiences, requires_any, requires_all, allow_missing_or_failed, allow_missing may be set.

provider_and_audiences

(extensions.filters.http.jwt_authn.v3.ProviderWithAudiences) Specify a required provider with audiences.

Only one of provider_name, provider_and_audiences, requires_any, requires_all, allow_missing_or_failed, allow_missing may be set.

requires_any

(extensions.filters.http.jwt_authn.v3.JwtRequirementOrList) Specify list of JwtRequirement. Their results are OR-ed. If any one of them passes, the result is passed.

Only one of provider_name, provider_and_audiences, requires_any, requires_all, allow_missing_or_failed, allow_missing may be set.

requires_all

(extensions.filters.http.jwt_authn.v3.JwtRequirementAndList) Specify list of JwtRequirement. Their results are AND-ed. All of them must pass, if one of them fails or missing, it fails.

Only one of provider_name, provider_and_audiences, requires_any, requires_all, allow_missing_or_failed, allow_missing may be set.

allow_missing_or_failed

(Empty) The requirement is always satisfied even if JWT is missing or the JWT verification fails. A typical usage is: this filter is used to only verify JWTs and pass the verified JWT payloads to another filter, the other filter will make decision. In this mode, all JWT tokens will be verified.

Only one of provider_name, provider_and_audiences, requires_any, requires_all, allow_missing_or_failed, allow_missing may be set.

allow_missing

(Empty) The requirement is satisfied if JWT is missing, but failed if JWT is presented but invalid. Similar to allow_missing_or_failed, this is used to only verify JWTs and pass the verified payload to another filter. The different is this mode will reject requests with invalid tokens.

Only one of provider_name, provider_and_audiences, requires_any, requires_all, allow_missing_or_failed, allow_missing may be set.

extensions.filters.http.jwt_authn.v3.JwtRequirementOrList

[extensions.filters.http.jwt_authn.v3.JwtRequirementOrList proto]

This message specifies a list of RequiredProvider. Their results are OR-ed; if any one of them passes, the result is passed

{
  "requirements": []
}

requirements: (repeated extensions.filters.http.jwt_authn.v3.JwtRequirement, REQUIRED) Specify a list of JwtRequirement.

extensions.filters.http.jwt_authn.v3.JwtRequirementAndList

[extensions.filters.http.jwt_authn.v3.JwtRequirementAndList proto]

This message specifies a list of RequiredProvider. Their results are AND-ed; all of them must pass, if one of them fails or missing, it fails.

{
  "requirements": []
}

requirements: (repeated extensions.filters.http.jwt_authn.v3.JwtRequirement, REQUIRED) Specify a list of JwtRequirement.

extensions.filters.http.jwt_authn.v3.RequirementRule

[extensions.filters.http.jwt_authn.v3.RequirementRule proto]

This message specifies a Jwt requirement for a specific Route condition. Example 1:

- match:
    prefix: /healthz

In above example, “requires” field is empty for /healthz prefix match, it means that requests matching the path prefix don’t require JWT authentication.

Example 2:

- match:
    prefix: /
  requires: { provider_name: provider-A }

In above example, all requests matched the path prefix require jwt authentication from “provider-A”.

{
  "match": {...},
  "requires": {...},
  "requirement_name": ...
}

match

(config.route.v3.RouteMatch, REQUIRED) The route matching parameter. Only when the match is satisfied, the “requires” field will apply.

For example: following match will match all requests.

match:
  prefix: /

requires

(extensions.filters.http.jwt_authn.v3.JwtRequirement) Specify a Jwt requirement. Please see detail comment in message JwtRequirement.

Specify a Jwt requirement. If not specified, Jwt verification is disabled.

Only one of requires, requirement_name may be set.

requirement_name

(string) Use requirement_name to specify a Jwt requirement. This requirement_name MUST be specified at the requirement_map in JwtAuthentication.

Specify a Jwt requirement. If not specified, Jwt verification is disabled.

Only one of requires, requirement_name may be set.

extensions.filters.http.jwt_authn.v3.FilterStateRule

[extensions.filters.http.jwt_authn.v3.FilterStateRule proto]

This message specifies Jwt requirements based on stream_info.filterState. This FilterState should use Router::StringAccessor object to set a string value. Other HTTP filters can use it to specify Jwt requirements dynamically.

Example:

name: jwt_selector
requires:
  issuer_1:
    provider_name: issuer1
  issuer_2:
    provider_name: issuer2

If a filter set “jwt_selector” with “issuer_1” to FilterState for a request, jwt_authn filter will use JwtRequirement{“provider_name”: “issuer1”} to verify.

{
  "name": ...,
  "requires": {...}
}

name: (string, REQUIRED) The filter state name to retrieve the Router::StringAccessor object.

requires: (repeated map<string, extensions.filters.http.jwt_authn.v3.JwtRequirement>) A map of string keys to requirements. The string key is the string value in the FilterState with the name specified in the name field above.

extensions.filters.http.jwt_authn.v3.JwtAuthentication

[extensions.filters.http.jwt_authn.v3.JwtAuthentication proto]

This is the Envoy HTTP filter config for JWT authentication.

For example:

providers:
   provider1:
     issuer: issuer1
     audiences:
     - audience1
     - audience2
     remote_jwks:
       http_uri:
         uri: https://example.com/.well-known/jwks.json
         cluster: example_jwks_cluster
         timeout: 1s
   provider2:
     issuer: issuer2
     local_jwks:
       inline_string: jwks_string

rules:
   # Not jwt verification is required for /health path
   - match:
       prefix: /health

   # Jwt verification for provider1 is required for path prefixed with "prefix"
   - match:
       prefix: /prefix
     requires:
       provider_name: provider1

   # Jwt verification for either provider1 or provider2 is required for all other requests.
   - match:
       prefix: /
     requires:
       requires_any:
         requirements:
           - provider_name: provider1
           - provider_name: provider2

{
  "providers": {...},
  "rules": [],
  "filter_state_rules": {...},
  "bypass_cors_preflight": ...,
  "requirement_map": {...}
}

providers

(repeated map<string, extensions.filters.http.jwt_authn.v3.JwtProvider>) Map of provider names to JwtProviders.

providers:
  provider1:
     issuer: issuer1
     audiences:
     - audience1
     - audience2
     remote_jwks:
       http_uri:
         uri: https://example.com/.well-known/jwks.json
         cluster: example_jwks_cluster
         timeout: 1s
   provider2:
     issuer: provider2
     local_jwks:
       inline_string: jwks_string

rules

(repeated extensions.filters.http.jwt_authn.v3.RequirementRule) Specifies requirements based on the route matches. The first matched requirement will be applied. If there are overlapped match conditions, please put the most specific match first.

Examples

rules:
  - match:
      prefix: /healthz
  - match:
      prefix: /baz
    requires:
      provider_name: provider1
  - match:
      prefix: /foo
    requires:
      requires_any:
        requirements:
          - provider_name: provider1
          - provider_name: provider2
  - match:
      prefix: /bar
    requires:
      requires_all:
        requirements:
          - provider_name: provider1
          - provider_name: provider2

filter_state_rules: (extensions.filters.http.jwt_authn.v3.FilterStateRule) This message specifies Jwt requirements based on stream_info.filterState. Other HTTP filters can use it to specify Jwt requirements dynamically. The rules field above is checked first, if it could not find any matches, check this one.

bypass_cors_preflight: (bool) When set to true, bypass the CORS preflight request regardless of JWT requirements specified in the rules.

requirement_map: (repeated map<string, extensions.filters.http.jwt_authn.v3.JwtRequirement>) A map of unique requirement_names to JwtRequirements. requirement_name in PerRouteConfig uses this map to specify a JwtRequirement.

extensions.filters.http.jwt_authn.v3.PerRouteConfig

[extensions.filters.http.jwt_authn.v3.PerRouteConfig proto]

Specify per-route config.

{
  "disabled": ...,
  "requirement_name": ...
}

disabled

(bool) Disable Jwt Authentication for this route.

Precisely one of disabled, requirement_name must be set.

requirement_name

(string) Use requirement_name to specify a JwtRequirement. This requirement_name MUST be specified at the requirement_map in JwtAuthentication. If no, the requests using this route will be rejected with 403.

Precisely one of disabled, requirement_name must be set.

extensions.filters.http.jwt_authn.v3.JwtClaimToHeader

[extensions.filters.http.jwt_authn.v3.JwtClaimToHeader proto]

This message specifies a combination of header name and claim name.

{
  "header_name": ...,
  "claim_name": ...
}

header_name: (string, REQUIRED) The HTTP header name to copy the claim to. The header name will be sanitized and replaced.

claim_name: (string, REQUIRED) The field name for the JWT Claim : it can be a nested claim of type (eg. “claim.nested.key”, “sub”) String separated with “.” in case of nested claims. The nested claim name must use dot “.” to separate the JSON name path.