Alibaba Cloud Service Mesh:Configure JWT authentication on an ingress gateway

How JWT authentication works on the gateway

JWT authentication on an ingress gateway relies on two Istio security resources that work together:

The ASM console wizard configures both resources. Step 5 (JWT Config) defines the RequestAuthentication parameters. Step 6 (Matching Rules) defines the AuthorizationPolicy parameters.

For more information about JWT, see JWT.

Configure JWT authentication

1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

2. On the Mesh Management page, click the name of the target ASM instance. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.

3. On the Ingress Gateway page, click the name of the ingress gateway.

4. In the gateway navigation pane, choose Gateway Security > JWT certification.

5. In the JWT Config step of the wizard, turn on Enable gateway JWT authentication, configure the following parameters, and then click Next.

   Example JWKS value
   Advanced configuration options Click AdvancedConfig to open the JWT Rules Advanced Options dialog box. The following options are available: Click OK to save the advanced settings.

   Parameter	Description
   Issuer	The JWT issuer identifier. This value must match the iss claim in the tokens you want to accept. Example: testing@secure.istio.io
   JWKS Source	The source of the JWKS used to verify token signatures. Select jwks to provide the key set inline
   Key	The JWKS content. Paste the JSON key set that contains the public keys for signature verification. See the example below
   AdvancedConfig	Opens the JWT Rules Advanced Options dialog box for additional settings (see below)

   Option	Description
   JWTToken Position	Where the gateway extracts the JWT from incoming requests. The default location is the Authorization header with a Bearer prefix. You can specify a custom header or query parameter
   JWT Passthrough	When enabled, forwards the original token to upstream services. Use this when backend services need to read JWT claims directly
   Transmit Payload through Header	Extracts specific JWT claims and passes them as HTTP headers to backend services. Use this to share user identity or role information with upstream services without requiring them to parse the JWT

      {
        "keys": [
          {
            "e": "AQAB",
            "kid": "DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ",
            "kty": "RSA",
            "n": "xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"
          }
        ]
      }

6. In the Matching Rules step, configure the following parameters and click Submit. In this example, Auth If Matched is selected with path /productpage:

   • Requests to /productpage must carry a valid JWT.

   • Requests to other paths do not require a JWT.

   Note

   For non-matched paths, requests without a token are allowed, but requests with an invalid token are still rejected. The gateway validates any JWT it encounters, regardless of the path.

   Parameter	Description
   Match Mode	Determines how matching rules interact with authentication. Auth If Matched -- require JWT authentication for requests that match the rules. Bypass Auth If Matched -- skip JWT authentication for requests that match the rules
   Matching Rules	Specifies which requests the match mode applies to. Select Custom Matching Rules, turn on Path, and enter the path. Example: /productpage

7. A success message confirms that JWT authentication is configured. The console displays the generated Istio security resources. Click YAML to inspect the RequestAuthentication and AuthorizationPolicy configurations.

Verify the configuration

After you configure JWT authentication, run the following tests to confirm it works as expected.

Set a test token as an environment variable:

TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

Replace <gateway-ip> with the IP address of your ASM ingress gateway in all test commands below.

Test 1: Valid token to a protected path -- expect 200

curl -I http://<gateway-ip>/productpage -H "Authorization: Bearer $TOKEN"

Expected response:

HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 4294
server: istio-envoy

Test 2: No token to a protected path -- expect 403

curl -I http://<gateway-ip>/productpage

Expected response:

HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
server: istio-envoy

Test 3: Invalid token to a protected path -- expect 401

curl -I http://<gateway-ip>/productpage -H "Authorization: Bearer invalid token"

Expected response:

HTTP/1.1 401 Unauthorized
content-type: text/plain
server: istio-envoy

Test 4: No token to an unprotected path -- expect 200

curl -I http://<gateway-ip>/api/v1/products/1

Expected response:

HTTP/1.1 200 OK
content-type: application/json
content-length: 195
server: istio-envoy

See also

• Configure access log collection for an ASM gateway

• Use the KubeAPI operation audit feature in ASM

• Configure audit alerts for ASM resource operations

• Configure JWT authentication for an ingress gateway in ASM