Closed joao-wso2 closed 2 weeks ago
We too were able to observe a similar issue with some IS 5.7.0 wum level. In those wum levels, there is a mismatch between the kid value obtained from JWKS endpoint and the JWT token.
We already identified this issue and fixed this in the latest Identity server 5.7.0 WUM update. If you take a wum update in your environment, you can resolve this issue.
We did an improvement[1] related to the kid value in a wum update. Before this improvement, when signing with the same key but using different algorithms like RS256, RS348 and RS512 we had the generated the same kid for all the keysets. Hence in order to differentiate them, we had appended the algorithm to the kid and generated as a new kid. So after this fix[1], the kid will have the algorithm appended in the kid value.
Eg: if RS256 is used, then kid value will be "ZmE4OGM5ZWEyNmZlNjg2ZGUwY2M5OGMyMDhlNjA0MDQ4YTZkOTExMQ_RS256"
With the latest wum updated pack, you will get the 'kid' value in the JWT token and JWKS endpoint will have the algorithm appended to it. Please update your environment also with by taking a 5.7.0 wum update.
This fix is available with the IS5.10.0-beta2 also.
I will try it tomorrow and let you know.
Hi Team, I have downloaded updates but the problem persists:
JWKS {"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ","alg":"RS256","n":"luZFdW1ynitztkWLC6xKegbRWxky-5P0p4ShYEOkHs30QI2VCuR6Qo4Bz5rTgLBrky03W1GAVrZxuvKRGj9V9-PmjdGtau4CTXu9pLLcqnruaczoSdvBYA3lS9a7zgFU0-s6kMl2EhB-rk7gXluEep7lIOenzfl2f6IoTKa2fVgVd3YKiSGsyL4tztS70vmmX121qm0sTJdKWP4HxXyqK9neolXI9fYyHOYILVNZ69z_73OOVhkh_mvTmWZLM7GM6sApmyLX6OXUp8z0pkY-vT_9-zRxxQs7GurC4_C1nK3rI_0ySUgGEafO1atNjYmlFN-M3tZX6nEcA6g94IavyQ"},{"kty":"RSA","e":"AQAB","use":"sig","kid":"NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ_RS256","alg":"RS256","n":"luZFdW1ynitztkWLC6xKegbRWxky-5P0p4ShYEOkHs30QI2VCuR6Qo4Bz5rTgLBrky03W1GAVrZxuvKRGj9V9-PmjdGtau4CTXu9pLLcqnruaczoSdvBYA3lS9a7zgFU0-s6kMl2EhB-rk7gXluEep7lIOenzfl2f6IoTKa2fVgVd3YKiSGsyL4tztS70vmmX121qm0sTJdKWP4HxXyqK9neolXI9fYyHOYILVNZ69z_73OOVhkh_mvTmWZLM7GM6sApmyLX6OXUp8z0pkY-vT_9-zRxxQs7GurC4_C1nK3rI_0ySUgGEafO1atNjYmlFN-M3tZX6nEcA6g94IavyQ"}]}
ID TOKEN - HEADER { "x5t": "NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ", "kid": "NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ_RS256", "alg": "RS256" }
MacBook-Joao:summary joaoemilio$ grep 5244 * Binary file update-summary-wso2is-km-5.7.0+1548762622360.full.pdf matches Binary file update-summary-wso2is-km-5.7.0+1562045447740.full.pdf matches
ID TOKEN
eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVFfUlMyNTYiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiUXRZUnhMdDRHTk9jV0hSLTN0VGxtUSIsImF1ZCI6IjRoZmRNR1BPbHFrMDFQQ0NKelAxOG8ydGE2SWEiLCJzdWIiOiJhZG1pbiIsIm5iZiI6MTU4MTk1NDIwNSwiYXpwIjoiNGhmZE1HUE9scWswMVBDQ0p6UDE4bzJ0YTZJYSIsImFtciI6WyJwYXNzd29yZCJdLCJpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0Ojk0NDNcL29hdXRoMlwvdG9rZW4iLCJleHAiOjE1ODE5NTc4MDUsImlhdCI6MTU4MTk1NDIwNX0.hFm0UCmj478GInjOAnU4moB6adqI86-NPUT64LPyAwykjNX8Yg-jWJDzP8Tl9WSrkJLPw_pLu4Skjp33geJzSfdGT5mZtIbxikX2mhbJi2uw7r81McoFkAB443Uv6bed_FgnXdGhgHIyvbG8ebjjgqV1dknwoEniq0yEeJ9rKAQ_P-DUaIiM74rklmV9Cyhhj9qLpNjFxmKNtjIo3f4uPixSXCYnNV7ol1pavqgJAx6jLgQPzDaZdNvfVUTj8zO24XlawP67VW7b5YIMin-ctN4xOcMjIS4-PnfmfitsLPjRQZogzTRa7LINMu6zTV-4GlQq3G-RhPhInpW1vozbng
Hi jao,
In the JWKS endpoint, you pointed above have the key set with the kid that comes in your ID token.
{ "keys":[ { "kty":"RSA", "e":"AQAB", "use":"sig", "kid":"NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ", "alg":"RS256", "n":"luZFdW1ynitztkWLC6xKegbRWxky-5P0p4ShYEOkHs30QI2VCuR6Qo4Bz5rTgLBrky03W1GAVrZxuvKRGj9V9-PmjdGtau4CTXu9pLLcqnruaczoSdvBYA3lS9a7zgFU0-s6kMl2EhB-rk7gXluEep7lIOenzfl2f6IoTKa2fVgVd3YKiSGsyL4tztS70vmmX121qm0sTJdKWP4HxXyqK9neolXI9fYyHOYILVNZ69z_73OOVhkh_mvTmWZLM7GM6sApmyLX6OXUp8z0pkY-vT_9-zRxxQs7GurC4_C1nK3rI_0ySUgGEafO1atNjYmlFN-M3tZX6nEcA6g94IavyQ" }, { "kty":"RSA", "e":"AQAB", "use":"sig", "kid":"NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ_RS256", "alg":"RS256", "n":"luZFdW1ynitztkWLC6xKegbRWxky-5P0p4ShYEOkHs30QI2VCuR6Qo4Bz5rTgLBrky03W1GAVrZxuvKRGj9V9-PmjdGtau4CTXu9pLLcqnruaczoSdvBYA3lS9a7zgFU0-s6kMl2EhB-rk7gXluEep7lIOenzfl2f6IoTKa2fVgVd3YKiSGsyL4tztS70vmmX121qm0sTJdKWP4HxXyqK9neolXI9fYyHOYILVNZ69z_73OOVhkh_mvTmWZLM7GM6sApmyLX6OXUp8z0pkY-vT_9-zRxxQs7GurC4_C1nK3rI_0ySUgGEafO1atNjYmlFN-M3tZX6nEcA6g94IavyQ" } ] }
Normally JWKS endpoint can have multiple keysets and we have to identify the suitable keyset with the KID. As long as the spec there is no restriction about how to create the KID, the only thing is it has to be unique.
In the default pack, you will get two keysets. The first one with KID without "_256" is for backward compatibility for the old issued tokens. But the new tokens are expected to use the second key set which deals with the new KID model.
This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!
Description: The id_token header must contain a kid claim with an ID to be validated against the jwks URL. The ID Token kid claim generated, contains an additional "_RS256" at the end which is conflicting with the response from the jwks URL, therefore the client application can't validate the token properly.
Suggested Labels:
Suggested Assignees:
Affected Product Version: 5.7
OS, DB, other environment details and versions:
any
Steps to reproduce: generate an ID token
Related Issues: