amichair commented on PR #2744: URL: https://github.com/apache/james-project/pull/2744#issuecomment-3005064107
The old code without that commit won't work with the newer jjwt releases, that's how I got to this seemingly unrelated change in the first place. Specifically, getClaimWithoutSignatureVerification doesn't work - there's no simple way to get a claim without also doing the verification itself (which will fail, because we haven't found what key to use yet... chicken and egg). In the new API there is only the KeyLocator, but that happens at a later stage in the verifier... our previous logic was a bit twisted, and straightening it out so it will be simpler and also work with the newer jjwt apis got me to this commit. If I understand correctly, the only thing that doesn't feel right is tha actual kid calculation, which is a bit low-level, though it is currently encapsulated in one place to make it easy to swap or fix or use an external lib should it be necessary someday. We could have gone with some trivial kid, such as a certificate serial number or such where the code might look a bit shorter... but if we already need to calculate a kid, why not use what afaict is an emerging standard? As for just trying them one by one - that's the fallback that still works if there is no kid in the jwt. I suppose we can just drop support for kid in the default provider and always use this fallback. It does remove functionality and consistency between providers, and the option of future enhancements (like key lookup per db per user or whatnot). So I see several options: 1. Find another way to make the new api work, and remain without the kid support in the default provider. 2. Leave a nop kid lookup and use the scan-all-keys fallback, and remain without the kid support in the default provider. 3. Pick a different, possibly simpler, less standard kid calculation (remember, whomever creates the jwt also needs to run this calculation when creating the jwt - so it should be either very simple or very standard). 4. Leave it as is with the new design and full support. 5. If it's just the kid calculation we don't like, try to find some external library that provides a java PublickKey to JWK thumbprint calculation. 6. Other options? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
