With the latest update, we activated subaccount-specific JSON Web Token (JWT) keys on all our Cloud Foundry landscapes. This means that from now, XSUAA uses unique keys for signing JWTs for subaccounts that are created. For this reason, the JWT verification must also use subaccount specific keys.
In addition, the issuer of the JWT will be standard compliant in these new subaccounts.
General Recommendation
We highly recommend that you always use the latest version of the official container security APIs for your programming language. The following container security APIs are the minimal versions for full compatibility after the update:
Java:
java-container-security: 2.9.0
spring-xsuaa: 1.6.0
node.js:
@sap/xssec 2.2.2
Python:
sap_xssec: 2.0.6
- If you use these container security APIs at least with the minimal version, you don't need to take further steps.
- If you aren't using any of the container security APIs, you need to make sure that the verification key that is currently contained in the XSUAA binding isn't used anymore. Instead you should always retrieve the key directly from the XSUAA during token verification (see https://docs.cloudfoundry.org/api/uaa/version/4.31.0/index.html#token-keys).
Technical Background
After this update, each new subaccount will get a unique set of keys by default. Further, subaccount owners will soon have the possibility to set their own JWT key on a subaccount level. Note that this feature will be rolled out separately in a future release. For this reason, the verification keys for all subaccounts must be retrieved during token verification from the XSUAA. The XSUAA will always return the correct verification key for each subaccount - for existing subaccounts also. The latest container security API versions are fully compatible with both old and new subaccounts.
Further, they implement the required online key retrieval and also include caching for the keys.
Impact
If you do not update your container security APIs to at least the minimal versions, the token validation will fail.
Note
The issuer ("iss" claim in the JWT) used to be a URL containing "localhost" as the host. This changes with the update to subaccount-specific keys so that the value will be standard compliant as mentioned above.
