Forum Discussion
Hello,
You confirm that the JWT and JWK objects are different for each provider ?
Yoann
- Jad_Tabbara__J1Jul 15, 2022Cirrostratus
Dear Yoann ๐
Hope you are doing well.
Yes each provider has its own JWK & JWT objects that are auto-generated using the "Discovery" job.- Yoann_Le_Corvi1Jul 15, 2022Cumulonimbus
Yes fine ๐
Would be interesting to see what is autodiscovered. I made a quick test with :
- 2 OAUTH Server configured in JWT + Openid connect + autodiscovery on F5 with different Issuers
- 1 OAUTH Resource with the same policy as yours (with a provide list that include the 2 OAUTH Servers) and it seems to work ๐Can you provide the 2 autodiscovery URLs used for Microsoft ?
Thanks
- Yoann_Le_Corvi1Jul 15, 2022Cumulonimbus
Hi
I had a bit of time, so I reproduced this in a lab. This behaviour is mainly related to
- the 2 oAuth servers from Microsoft using the same jwt keys (same kid)
- F5 APM using the kid ot in the JWT Header to locate the JWK in the configuration, then the JWT including the issuer.The scenario you are hitting is :
- you get your JWT from issuer https://sts.windows.net/.
- the header of this JWT contains kid : 123456
- APM locates amongs the JWKs the kid : 123456
- but somehow selects the JWK gathered from the Discovery of https://login.microsoftonline.com/v2.0
- the JWK is linked the the JWT in APM from issuer https://login.microsoftonline.com/v2.0
- this triggers the error as issuer of the received JWT does not match the one configured in the JWT object selected by APM during the matching ๐If someone from F5 reads this : wouldn't it make sense to change the JWK matching to include criterias kid AND issuer ?
In the mean time :
- your workaround is great I think
- another one woud be to create a with 2 cascaded OAUTH Scopes, with on provider in each. The secon OAUTH scope being in the "fallback" branch of the first one.
Otherwise you might have to open a ticket, who knows, there might be a EngHF for that ๐Yoann