Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert

SAP software is renowned for its stringent security standards.

As explained in Kyma 2.0 release notes, Open Source Kyma 2.0 brings a number of security changes to SAP BTP, Kyma Runtime (SKR).

In a nutshell, what has changed is the user/cluster authentication (with OIDC) and authorisations (with RBAC).

As a result, DEX and a few other authentication and authorisation components were deprecated and removed.

This blog post focuses on the latter, as the removal of DEX as a static OIDC IDP (OpenID Connect Identity Provider) has a direct impact on API Rules managed and protected with the JWT strategy.

Good to know:

Putting it all together

The API rules in Kyma support a number of security strategies, for instance JWT and OAuth2.

As aforementioned, with Open Source Kyma 2.0 release, the DEX component has been deprecated and removed altogether:
Ory Oathkeeper without Dex
With Kyma 2.0, the Dex component becomes deprecated. Therefore, Ory Oathkeeper will no longer use Dex to verify JWT tokens. Existing API Rules that have a JWT access strategy defined must be enriched with an individual jwks_url parameter pointing to a custom OpenID Connect-compliant identity provider.

The API Rules with JWT handlers hardwired to DEX IDP will need to be changed to a custom OpenID Connect (OIDC) Identity Provider as follows:

DEX IDP - (Kyma 1.x built-in OIDC service)

OIDC-compliant IDP provider
DEX OIDC metadata

custom OIDC metadata URL.

  • Typically this will be the OIDC provider host URL with the .well-known/openid-configuration suffix.

DEX Issuer URL

custom OIDC Issuer URL

  • this is the OIDC provider host URL



  • JWKS URI URL is a pointer to a json array that will be used to validate the JWT digital signature by the callee.

A JWT token fetched from DEX is  a so-called user JWT token representing a OIDC user identity present in the cluster kubeconfig

Here goes an example of DEX fetched JWT token:

The issuer's token endpoint will be called [by a custom OAuth2 client] to generate the JWT token.

Here goes an example of a user-agnostic JWT token, the client id is used as the technical user name (sub claim — subject):

An example of how to configure a function API rule combining several access strategies is in the appendix.


The below table attempts to address the most common questions you may have in the aftermath of DEX removal:

Questions Answers
What are the DEX replacement options ?

Pretty much any OIDC-compliant provider can do.

But the choice will depend very much on the answer to the next question.
What authorisation grant type to choose from?

  • client credentials grant type (basic authentication, technical user)

  • authorization code  grant type (3-legged authentication, business user)

  • saml bearer assertion grant type (2-legged authentication, business user)

How to retrieve a (user) JWT token ? To start with, you may refer to the following blog post that describes the BTP XSUAA as a simple, affordable OIDC Identity Provider used to implement a JWT strategy.
How to call a JWT protected API Rule endpoint?

Simply put the retrieved JWT (bearer access token) in the Authorization header and make the API call.

Please consider if you are using this endpoint from javascript in a browser, the Authorization header will trigger the CORS flow.

If you have further questions around Kyma and security topics in particular, feel free to post them in the comments area of this blog or ask the broader SAP Community.

To stay up to date with everything on Kyma, you may want to visit our Kyma topic page. 




An example of an API rule for a kyma function endpoints with multiple access strategies, namely jwt with several handlers and allow.


gateway: kyma-gateway.kyma-system.svc.cluster.local
- accessStrategies:
- config:
- >-<env>/as/jwks
- >-<env>/v1/keys
- >-
- >-
handler: jwt
path: /getecptoken
- accessStrategies:
- config: {}
handler: allow
path: /.*