From c6ba4cada2fc62028f8dd99ea128107ba588cca8 Mon Sep 17 00:00:00 2001 From: shaun-nx Date: Thu, 3 Sep 2026 11:38:23 +0100 Subject: [PATCH 1/8] Add documentation for JWT Claim Validation --- .../traffic-security/jwt-claim-validation.md | 508 ++++++++++++++++++ 1 file changed, 508 insertions(+) create mode 100644 content/ngf/traffic-security/jwt-claim-validation.md diff --git a/content/ngf/traffic-security/jwt-claim-validation.md b/content/ngf/traffic-security/jwt-claim-validation.md new file mode 100644 index 000000000..37d824e6f --- /dev/null +++ b/content/ngf/traffic-security/jwt-claim-validation.md @@ -0,0 +1,508 @@ +--- +title: Configure JWT claim validation +weight: 650 +toc: true +f5-content-type: how-to +f5-product: NGINX Gateway Fabric +f5-description: How to configure JWT claim validation in NGINX Gateway Fabric using the `AuthenticationFilter` custom resource definition (CRD). +f5-summary: > + NGINX Gateway Fabric supports JWT claim validation via the AuthenticationFilter CRD, allowing you to enforce authorization rules based on the claims present in a JSON Web Token. + Claim validation adds an authorization layer on top of JWT authentication, ensuring that only tokens containing specific claim values are granted access. + JWT claim validation requires NGINX Plus and is not supported with open-source NGINX. +--- + +This guide describes how to configure JWT claim validation in NGINX Gateway Fabric using the AuthenticationFilter custom resource definition (CRD). + +JWT claim validation adds an authorization layer on top of [JWT authentication]({{< ref "/ngf/traffic-security/jwt-authentication.md" >}}) and [OIDC authentication]({{< ref "/ngf/traffic-security/oidc-authentication.md" >}}). While authentication verifies that a token is valid and properly signed, claim validation goes further by inspecting the claims (fields) inside the token payload. This lets you enforce rules such as requiring a specific issuer, audience, or custom claim value before granting access to your application. + +By following these instructions, you will configure an AuthenticationFilter with claim validation rules and verify that only tokens containing the expected claims are allowed through. + +For demonstration purposes, in this document you will deploy and configure a `type: JWT` AuthenticationFilter using `mode: File`. + +{{< call-out class="note" >}} JWT claim validation requires NGINX Plus. {{< /call-out >}} + +## Overview + +JWT claim validation is configured through the `authorization` field on the AuthenticationFilter spec. It uses a two-level `require` model that controls how rules and claims are evaluated. + +**Top-level require** + +The top-level `require` field (`authorization.require`) controls how **rules** relate to each other: + +- **Any** (default) — A request is authorized if **any one** of the rules are satisfied. +- **All** — A request is authorized only if **every** rule is satisfied. + +**Per-rule require** + +Each rule has its own `require` field (`rules[].require`) that controls how the **claims within that rule** relate to each other: + +- **Any** (default) — The rule is satisfied if **any one** of its claims matches. +- **All** — The rule is satisfied only if **every** claim in the rule matches. + +**How the two levels work together** + +Consider an AuthenticationFilter with `authorization.require: Any` and two rules, each with `require: All`: + +- Rule 0 requires **all** of: `iss=issuer-1` **and** `aud=api` +- Rule 1 requires **all** of: `iss=issuer-2` **and** `aud=admin` + +Because the top-level require is `Any`, a request is authorized if the token satisfies **either** rule 0 **or** rule 1. A token that only partially matches both rules would be rejected as it does not fully satisfy either rule. + +**Additional fields** + +Claim validation also supports the following options: + +- **`match`**: Controls how claim values are compared. Set to `Exact` (default) for literal string matching, or `Regex` to allow regular expression patterns in claim values. +- **`proxySetHeader`**: Forwards the value of a matched claim as a request header to the upstream application. For example, setting `proxySetHeader: X-Tenant` on a `tenant` claim sends `X-Tenant: ` to the backend. +- **Nested claims**: Use a slash (`/`) separator to reference claims nested within other claims. For example, `realm_access/roles` refers to the `roles` field inside the `realm_access` object. + +--- + +## Before you begin + +- [Install]({{< ref "/ngf/install/" >}}) NGINX Gateway Fabric with NGINX Plus. + +## Setup + +### Deploy sample applications + +To deploy the `coffee` and `tea` applications, run the following YAML with `kubectl apply`: + +```yaml +kubectl apply -f - < +``` + +### Generate a JWKS and create a Secret + +For testing purposes, the following example shows a simple JWKS with a single RSA key. In production, use properly generated keys from your identity provider or key management system. + +Save the JWKS to a file called `auth` and create a Secret: + +```shell +cat < auth +{ + "keys": [ + { + "kty": "RSA", + "kid": "test-key", + "use": "sig", + "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", + "e": "AQAB" + } + ] +} +EOF +kubectl create secret generic jwks-secret --from-file=auth +``` + +{{< call-out class="note" >}} This example JWKS is for demonstration only. In production, use keys from your identity provider or key management system. {{< /call-out >}} + +--- + +## Configure JWT claim validation + +This example creates an AuthenticationFilter with two rules that enforce different issuer and audience combinations. The top-level `require` is set to `Any`, and each rule's `require` is set to `All`. + +This means a request is authorized if its JWT satisfies **all** claims in rule 0 **or** all claims in rule 1. + +### Create the AuthenticationFilter + +Deploy the AuthenticationFilter with claim validation rules by running the following YAML with `kubectl apply`: + +```yaml +kubectl apply -f - < +``` + +### Understanding the configuration + +- **`authorization.require: Any`** — The request passes if **any** rule is satisfied. +- **Rule 0** (`require: All`) — The JWT must contain **both** `iss` equal to `https://issuer-1.example.com` **and** `aud` equal to `api`. +- **Rule 1** (`require: All`) — The JWT must contain **both** `iss` equal to `https://issuer-2.example.com` **and** `aud` equal to `admin`. + +The following table summarizes which tokens are authorized: + +| Token claims | Rule 0 | Rule 1 | Result | +|---|---|---|---| +| `iss=issuer-1`, `aud=api` | ✅ All matched | ❌ | ✅ Authorized | +| `iss=issuer-2`, `aud=admin` | ❌ | ✅ All matched | ✅ Authorized | +| `iss=issuer-1`, `aud=admin` | ❌ Partial | ❌ Partial | ❌ Rejected | +| `iss=issuer-2`, `aud=api` | ❌ Partial | ❌ Partial | ❌ Rejected | + +### Deploy an HTTPRoute referencing the AuthenticationFilter + +Deploy an HTTPRoute that applies the AuthenticationFilter to the `/coffee` path. The `/tea` path has no authentication and responds normally. Run the following YAML with `kubectl apply`: + +```yaml +kubectl apply -f - < +``` + +### Verify JWT claim validation + +{{< call-out class="note" >}} + +Your clients should be able to resolve "cafe.example.com" to the public IP of the NGINX Service. + +This guide simulates that using curl's `--resolve` option. + +{{< /call-out >}} + +To test claim validation, you need JWTs signed with the private key corresponding to the public key in your JWKS. You can use [jwt.io](https://jwt.io) or other JWT tools to generate tokens with different claim payloads. Store each token in a shell variable. + +**Token matching rule 0** (`iss=https://issuer-1.example.com`, `aud=api`): + +```shell +JWT_RULE0="" +``` + +**Token matching rule 1** (`iss=https://issuer-2.example.com`, `aud=admin`): + +```shell +JWT_RULE1="" +``` + +**Token matching neither rule** (`iss=https://issuer-1.example.com`, `aud=admin`): + +```shell +JWT_NEITHER="" +``` + +Access `/coffee` with a token matching rule 0 + +```shell +curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/coffee -H "Authorization: Bearer $JWT_RULE0" +``` + +```text +Server address: 10.244.0.7:8080 +Server name: coffee-654ddf664b-nhhvr +Date: 10/Mar/2026:15:20:15 +0000 +URI: /coffee +Request ID: 13a925b2514b62c45ea4a79800248d5c +``` + +The request succeeds as the token satisfies all claims in rule 0. + +Access `/coffee` with a token matching rule 1 + +```shell +curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/coffee -H "Authorization: Bearer $JWT_RULE1" +``` + +```text +Server address: 10.244.0.7:8080 +Server name: coffee-654ddf664b-nhhvr +Date: 02/Sep/2026:15:21:30 +0000 +URI: /coffee +Request ID: 7b2e4a1c9f0d3e5a8c6b4d2f1a0e9c8b +``` + +The request succeeds as the token satisfies all claims in rule 1. + +Access `/coffee` with a token matching neither rule + +```shell +curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/coffee -H "Authorization: Bearer $JWT_NEITHER" +``` + +```text + +401 Authorization Required + +

401 Authorization Required

+
nginx
+ + +``` + +The request is rejected. Although the token has valid claims, it only partially matches each rule (`iss` from rule 0 and `aud` from rule 1). Since each rule requires **all** claims to match and the token does not fully satisfy either rule, authorization fails. + +Access `/coffee` without a token + +```shell +curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/coffee +``` + +```text + +401 Authorization Required + +

401 Authorization Required

+
nginx
+ + +``` + +Without a JWT, the request fails authentication before claim validation is evaluated. + +Access `/tea` without authentication + +```shell +curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/tea +``` + +```text +Server address: 10.244.0.10:8080 +Server name: tea-75bc9f4b6d-ms2n8 +Date: 03/Sep/2026:15:36:26 +0000 +URI: /tea +Request ID: c7eb0509303de1c160cb7e7d2ac1d99f +``` + +The `/tea` path has no AuthenticationFilter attached and responds normally. + +--- + +## Troubleshooting + +- Ensure NGINX Gateway Fabric is deployed with NGINX Plus. JWT claim validation is not supported in the open source version. +- Ensure the AuthenticationFilter is accepted by checking its status with `kubectl describe`. +- Ensure the HTTPRoute references the correct AuthenticationFilter name and group. +- Confirm the Secret key is named `auth` and contains valid JWKS JSON. The Secret must be in the same namespace as the AuthenticationFilter. +- Verify your JWT includes the `kid` (key ID) claim that matches one of the keys in your JWKS. +- Check that the JWT is not expired by verifying the `exp` claim. +- Ensure the JWT signature algorithm (typically RS256) matches the key type in your JWKS. +- If claim validation rejects a token you expect to pass, decode the token at [jwt.io](https://jwt.io) and verify that the claim names and values exactly match what is configured in the AuthenticationFilter. + +## Further reading + +- [AuthenticationFilter API reference]({{< ref "/ngf/reference/api.md#gateway.nginx.org/v1alpha1.AuthenticationFilter" >}}) +- [Configure JWT authentication]({{< ref "/ngf/traffic-security/jwt-authentication.md" >}}) +- [Configure OIDC authentication]({{< ref "/ngf/traffic-security/oidc-authentication.md" >}}) +- [NGINX JWT Authentication Module](https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html) +- [NGINX auth_jwt_require directive](https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html#auth_jwt_require) +- [RFC 7519 - JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519) + From 7f7bab0c7192bfdda8830d261934807a8bc38355 Mon Sep 17 00:00:00 2001 From: shaun-nx Date: Thu, 3 Sep 2026 14:19:17 +0100 Subject: [PATCH 2/8] Add more detail to optional fields --- .../traffic-security/jwt-claim-validation.md | 73 ++++++++++++++++--- 1 file changed, 64 insertions(+), 9 deletions(-) diff --git a/content/ngf/traffic-security/jwt-claim-validation.md b/content/ngf/traffic-security/jwt-claim-validation.md index 37d824e6f..d15617fc0 100644 --- a/content/ngf/traffic-security/jwt-claim-validation.md +++ b/content/ngf/traffic-security/jwt-claim-validation.md @@ -46,15 +46,7 @@ Consider an AuthenticationFilter with `authorization.require: Any` and two rules - Rule 0 requires **all** of: `iss=issuer-1` **and** `aud=api` - Rule 1 requires **all** of: `iss=issuer-2` **and** `aud=admin` -Because the top-level require is `Any`, a request is authorized if the token satisfies **either** rule 0 **or** rule 1. A token that only partially matches both rules would be rejected as it does not fully satisfy either rule. - -**Additional fields** - -Claim validation also supports the following options: - -- **`match`**: Controls how claim values are compared. Set to `Exact` (default) for literal string matching, or `Regex` to allow regular expression patterns in claim values. -- **`proxySetHeader`**: Forwards the value of a matched claim as a request header to the upstream application. For example, setting `proxySetHeader: X-Tenant` on a `tenant` claim sends `X-Tenant: ` to the backend. -- **Nested claims**: Use a slash (`/`) separator to reference claims nested within other claims. For example, `realm_access/roles` refers to the `roles` field inside the `realm_access` object. +Since the top-level require is `Any`, a request is authorized if the token satisfies **either** rule 0 **or** rule 1. A token that only partially matches both rules would be rejected as it does not fully satisfy either rule. --- @@ -484,6 +476,69 @@ Request ID: c7eb0509303de1c160cb7e7d2ac1d99f The `/tea` path has no AuthenticationFilter attached and responds normally. +## Additional configuration + +### Nested claims + +JWT Claims can often be nested at multiple level. Using the slash (`/`) separator, you can define the level of nesting to access to required claim value. +In this example, we set up the rule to access the values of the `roles` claim, which is nested under `real_access` + +Example JSON payload + +```json +{ + "realm_access": { + "roles": ["reader", "admin"] + }, +} +``` + +```yaml +authorization: + require: Any + rules: + - require: All + claims: + - name: "realm_access/roles" + values: + - "reader" + - "admin" +``` + +### Clam match type + +By default, clam values are evaluated against their exact value. This can also be set to `Regex` allowing for a more complex and expressive matching configuration. +This example allows an `email` claim that contains `@example.com`. This would match on `foo@example.com`, `user@example.com` etc... + +```yaml +authorization: + require: Any + rules: + - require: Any + claims: + - name: email + match: Regex + values: + - ".*@example\\.com" +``` + +### Header forwarding + +By defining the `proxySetHeader` for a specific claim, you can forward the value of a matched claim as a request header to the upstream application. +This example show defining a header called `X-Aud` on the `aud` claim. + +```yaml +authorization: + require: Any + rules: + - require: All + claims: + - name: "aud" + proxySetHeader: X-Aud + values: + - "api" +``` + --- ## Troubleshooting From 95490783d5dbc28e401ef9953f3debcf4c6016ef Mon Sep 17 00:00:00 2001 From: shaun-nx Date: Thu, 3 Sep 2026 14:31:09 +0100 Subject: [PATCH 3/8] Correct typos --- content/ngf/traffic-security/jwt-claim-validation.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ngf/traffic-security/jwt-claim-validation.md b/content/ngf/traffic-security/jwt-claim-validation.md index d15617fc0..c4cd3bab2 100644 --- a/content/ngf/traffic-security/jwt-claim-validation.md +++ b/content/ngf/traffic-security/jwt-claim-validation.md @@ -480,8 +480,8 @@ The `/tea` path has no AuthenticationFilter attached and responds normally. ### Nested claims -JWT Claims can often be nested at multiple level. Using the slash (`/`) separator, you can define the level of nesting to access to required claim value. -In this example, we set up the rule to access the values of the `roles` claim, which is nested under `real_access` +JWT Claims can often be nested at multiple levels. Using the slash (`/`) separator, you can define the level of nesting to access the required claim value. +In this example, we set up the rule to access the values of the `roles` claim, which is nested under `realm_access` Example JSON payload @@ -505,9 +505,9 @@ authorization: - "admin" ``` -### Clam match type +### Claim match type -By default, clam values are evaluated against their exact value. This can also be set to `Regex` allowing for a more complex and expressive matching configuration. +By default, claim values are evaluated against their exact value. This can also be set to `Regex` allowing for a more complex and expressive matching configuration. This example allows an `email` claim that contains `@example.com`. This would match on `foo@example.com`, `user@example.com` etc... ```yaml @@ -525,7 +525,7 @@ authorization: ### Header forwarding By defining the `proxySetHeader` for a specific claim, you can forward the value of a matched claim as a request header to the upstream application. -This example show defining a header called `X-Aud` on the `aud` claim. +This example shows defining a header called `X-Aud` on the `aud` claim. ```yaml authorization: From cd369c3f261878b186d6b13df9b65e5a27e11a7f Mon Sep 17 00:00:00 2001 From: Shaun Date: Thu, 3 Sep 2026 16:19:14 +0100 Subject: [PATCH 4/8] Update content/ngf/traffic-security/jwt-claim-validation.md Co-authored-by: Jon Torre <78599298+JTorreG@users.noreply.github.com> --- content/ngf/traffic-security/jwt-claim-validation.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/ngf/traffic-security/jwt-claim-validation.md b/content/ngf/traffic-security/jwt-claim-validation.md index c4cd3bab2..e22e5e07c 100644 --- a/content/ngf/traffic-security/jwt-claim-validation.md +++ b/content/ngf/traffic-security/jwt-claim-validation.md @@ -1,14 +1,15 @@ --- -title: Configure JWT claim validation +description: "Configure JWT claim validation in NGINX Gateway Fabric to enforce authorization rules based on JSON Web Token claims." weight: 650 toc: true f5-content-type: how-to f5-product: NGINX Gateway Fabric -f5-description: How to configure JWT claim validation in NGINX Gateway Fabric using the `AuthenticationFilter` custom resource definition (CRD). +f5-keywords: "JWT, JSON Web Token, claim validation, authentication, authorization, NGINX Gateway Fabric" f5-summary: > NGINX Gateway Fabric supports JWT claim validation via the AuthenticationFilter CRD, allowing you to enforce authorization rules based on the claims present in a JSON Web Token. Claim validation adds an authorization layer on top of JWT authentication, ensuring that only tokens containing specific claim values are granted access. JWT claim validation requires NGINX Plus and is not supported with open-source NGINX. +f5-audience: any --- This guide describes how to configure JWT claim validation in NGINX Gateway Fabric using the AuthenticationFilter custom resource definition (CRD). From 658a3f5f940d97cbf64deaa7c0ce45424cac3ef7 Mon Sep 17 00:00:00 2001 From: Shaun Date: Thu, 3 Sep 2026 16:20:25 +0100 Subject: [PATCH 5/8] Update content/ngf/traffic-security/jwt-claim-validation.md Co-authored-by: Jon Torre <78599298+JTorreG@users.noreply.github.com> --- content/ngf/traffic-security/jwt-claim-validation.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/ngf/traffic-security/jwt-claim-validation.md b/content/ngf/traffic-security/jwt-claim-validation.md index e22e5e07c..55dc2da91 100644 --- a/content/ngf/traffic-security/jwt-claim-validation.md +++ b/content/ngf/traffic-security/jwt-claim-validation.md @@ -49,8 +49,6 @@ Consider an AuthenticationFilter with `authorization.require: Any` and two rules Since the top-level require is `Any`, a request is authorized if the token satisfies **either** rule 0 **or** rule 1. A token that only partially matches both rules would be rejected as it does not fully satisfy either rule. ---- - ## Before you begin - [Install]({{< ref "/ngf/install/" >}}) NGINX Gateway Fabric with NGINX Plus. From a0d05874f8bb6a8683cb1ccd234cdc748d3634dc Mon Sep 17 00:00:00 2001 From: Shaun Date: Thu, 3 Sep 2026 16:37:46 +0100 Subject: [PATCH 6/8] Apply batched suggestions from code review Co-authored-by: Jon Torre <78599298+JTorreG@users.noreply.github.com> --- .../traffic-security/jwt-claim-validation.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/ngf/traffic-security/jwt-claim-validation.md b/content/ngf/traffic-security/jwt-claim-validation.md index 55dc2da91..e40d410db 100644 --- a/content/ngf/traffic-security/jwt-claim-validation.md +++ b/content/ngf/traffic-security/jwt-claim-validation.md @@ -1,5 +1,5 @@ --- -description: "Configure JWT claim validation in NGINX Gateway Fabric to enforce authorization rules based on JSON Web Token claims." +description: "How to configure JSON Web Token (JWT) claim validation in F5 NGINX Gateway Fabric using the `AuthenticationFilter` custom resource definition (CRD)." weight: 650 toc: true f5-content-type: how-to @@ -12,9 +12,9 @@ f5-summary: > f5-audience: any --- -This guide describes how to configure JWT claim validation in NGINX Gateway Fabric using the AuthenticationFilter custom resource definition (CRD). +This guide describes how to configure JWT claim validation in F5 NGINX Gateway Fabric using the AuthenticationFilter custom resource definition (CRD). -JWT claim validation adds an authorization layer on top of [JWT authentication]({{< ref "/ngf/traffic-security/jwt-authentication.md" >}}) and [OIDC authentication]({{< ref "/ngf/traffic-security/oidc-authentication.md" >}}). While authentication verifies that a token is valid and properly signed, claim validation goes further by inspecting the claims (fields) inside the token payload. This lets you enforce rules such as requiring a specific issuer, audience, or custom claim value before granting access to your application. +JWT claim validation adds authorization after [JWT authentication]({{< ref "/ngf/traffic-security/jwt-authentication.md" >}}) and [OIDC authentication]({{< ref "/ngf/traffic-security/oidc-authentication.md" >}}). Authentication checks whether a token is valid and signed correctly. Claim validation checks claims in the token payload. You can require a specific issuer, audience, or custom claim before users access your application. By following these instructions, you will configure an AuthenticationFilter with claim validation rules and verify that only tokens containing the expected claims are allowed through. @@ -173,11 +173,11 @@ Addresses: Value: 192.0.2.1 ``` -Save the public IP address and port of the Gateway into shell variables: +Set the Gateway IP address and port in shell variables: ```shell -GW_IP=XXX.YYY.ZZZ.III -GW_PORT= +GW_IP= +GW_PORT= ``` ### Generate a JWKS and create a Secret @@ -376,19 +376,19 @@ To test claim validation, you need JWTs signed with the private key correspondin **Token matching rule 0** (`iss=https://issuer-1.example.com`, `aud=api`): ```shell -JWT_RULE0="" +JWT_RULE0="" ``` **Token matching rule 1** (`iss=https://issuer-2.example.com`, `aud=admin`): ```shell -JWT_RULE1="" +JWT_RULE1="" ``` **Token matching neither rule** (`iss=https://issuer-1.example.com`, `aud=admin`): ```shell -JWT_NEITHER="" +JWT_NEITHER="" ``` Access `/coffee` with a token matching rule 0 @@ -398,7 +398,7 @@ curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT ``` ```text -Server address: 10.244.0.7:8080 +Server address: 192.0.2.7:8080 Server name: coffee-654ddf664b-nhhvr Date: 10/Mar/2026:15:20:15 +0000 URI: /coffee @@ -414,7 +414,7 @@ curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT ``` ```text -Server address: 10.244.0.7:8080 +Server address: 192.0.2.7:8080 Server name: coffee-654ddf664b-nhhvr Date: 02/Sep/2026:15:21:30 +0000 URI: /coffee @@ -479,7 +479,7 @@ The `/tea` path has no AuthenticationFilter attached and responds normally. ### Nested claims -JWT Claims can often be nested at multiple levels. Using the slash (`/`) separator, you can define the level of nesting to access the required claim value. +JWT claims can be nested at multiple levels. Use the slash (`/`) separator to identify the required claim value. In this example, we set up the rule to access the values of the `roles` claim, which is nested under `realm_access` Example JSON payload @@ -488,7 +488,7 @@ Example JSON payload { "realm_access": { "roles": ["reader", "admin"] - }, + } } ``` From cd8cba15f90d938c15615ff7727cbac53b03419d Mon Sep 17 00:00:00 2001 From: shaun-nx Date: Thu, 3 Sep 2026 17:03:46 +0100 Subject: [PATCH 7/8] Add description to Setup section --- content/ngf/traffic-security/jwt-claim-validation.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/ngf/traffic-security/jwt-claim-validation.md b/content/ngf/traffic-security/jwt-claim-validation.md index e40d410db..0f49d1552 100644 --- a/content/ngf/traffic-security/jwt-claim-validation.md +++ b/content/ngf/traffic-security/jwt-claim-validation.md @@ -55,6 +55,8 @@ Since the top-level require is `Any`, a request is authorized if the token satis ## Setup +In this part of the document, we will set up several resources in your cluster to demonstrate the authorization field of the AuthenticationFilter CRD. + ### Deploy sample applications To deploy the `coffee` and `tea` applications, run the following YAML with `kubectl apply`: From 972ceaa9224950a64c3fbbccac456ba86022fd73 Mon Sep 17 00:00:00 2001 From: shaun-nx Date: Thu, 3 Sep 2026 17:08:30 +0100 Subject: [PATCH 8/8] Fix setup header --- content/ngf/traffic-security/jwt-claim-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ngf/traffic-security/jwt-claim-validation.md b/content/ngf/traffic-security/jwt-claim-validation.md index 0f49d1552..e59bb0158 100644 --- a/content/ngf/traffic-security/jwt-claim-validation.md +++ b/content/ngf/traffic-security/jwt-claim-validation.md @@ -53,7 +53,7 @@ Since the top-level require is `Any`, a request is authorized if the token satis - [Install]({{< ref "/ngf/install/" >}}) NGINX Gateway Fabric with NGINX Plus. -## Setup +## Set up In this part of the document, we will set up several resources in your cluster to demonstrate the authorization field of the AuthenticationFilter CRD.