Skip to Content
Product Information
Author's profile photo Magdalena Strek

SAP BTP, Kyma runtime Istio based JWT handler – sneak peek

In my previous blog post, I explained the upcoming architectural changes in API Gateway. Today, I would like to show you a preview of the forthcoming changes related to API Exposure topics and invite you to try out the Istio-based JWT handler in API Gateway APIRule.

Istio JWT alpha feature

Because the Istio-based JWT handler in API Gateway APIRule CR is an alpha feature, we cannot guarantee its stability yet. Final changes and API will be released with version v1 of APIRule, which will also contain updates related to OAuth2 flows. Follow the epic issue to learn the details and keep up-to-date with the progress we make. If you have any feedback, feel free to reach out to us.

Configure the feature toggle

In order to play around with the Istio JWT handler in APIRule, you must configure API Gateway to start processing the JWT handler differently by switching it into Istio mode. Once you do it, all new and existing APIRules will be processed with new rules, and, as a consequence, the existing APIRules with JWT configuration will have the ERROR state. However, there’s no need to be concerned – the workloads exposed and secured with JWT will still work as intended. The feature toggle is implemented not to disrupt the existing configuration. It gives you both a chance to get to know the upcoming changes and the possibility of switching back to the previous solution if needed.

Run the following command to configure API Gateway in such a way that it can process the JWT handler in Istio mode:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
 name: api-gateway-config
 namespace: kyma-system
 api-gateway-config: |
   jwtHandler: "istio"

After applying the configuration, you must wait a few more minutes for API Gateway to retrieve it.

Expose and secure a workload with JWT

For the sake of simplicity, this tutorial uses Istio httpbin as a workload. Follow the instructions from the Create a workload tutorial to deploy it into your cluster. The Istio-based JWT handler introduces a hard requirement for a workload to be part of the Istio service mesh. Remember to make sure that your workload has the sidecar injection enabled. To learn about the differences between Ory Oathkeeper and Istio JWT access strategies, read this document
Configure the scope, client ID, client secret, and the token URL in your application. To do it, use SAP Cloud Identity Services or an OIDC-complaint provider of your choice. Follow this tutorial to obtain a JWT token.

Export the Namespace in which you deployed your workload, the name of the Kyma domain to expose workloads, the issuer, and the JWKS URI. You can retrieve the JWKS URI from /.well-known/openid-configuration. Run:


Run the following command to expose and secure your workload:

cat <<EOF | kubectl apply -f -
kind: APIRule
  name: istio-jwt
  namespace: $NAMESPACE
  gateway: kyma-system/kyma-gateway
    name: httpbin
    port: 8000
    - path: /headers
      methods: ["GET"]
        - handler: jwt
            - issuer: $ISSUER
              jwksUri: $JWKS_URI
            - requiredScopes: ["test"]

Having a JWT containing the scope test, you can access the httpbin headers endpoint:

curl -ik -X GET https://httpbin.$DOMAIN_TO_EXPOSE_WORKLOADS/headers -H "Authorization: Bearer $TOKEN"

If successful, the above command returns code 200 and a response containing the headers.


I want to encourage you to get acquainted with Istio JWT specification and the comparison of Ory Oathkeeper and Istio JWT access strategies as well as start experimenting with the new API. Subscribe to SAP BTP, Kyma runtime blogs to be up-to-date with the upcoming changes. In case you have any concerns or feedback, leave a comment under this blog post or ask a question on the SAP BTP, Kyma runtime community page.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.