Restore two JWT decoding methods in OidcUtils

[sberyozkin]

Fixes #45948.

Adding a couple of methods related to decoding JWT back to OidcUtils, it is not a big problem to have them in OidcUtils and delegating to OidcCommonUtils

[sberyozkin]

Guillaume, if you think having them in OidcCommonUtils is enough then please don't hesitate to close this PR, I guess it is OK in this case to have these couple of methods restored in OidcUtils.
May be we can create quarkus.oidc,JwtUtils to have static utility methods that can be of help in general ? I can do later or now...

[sberyozkin]

We should probably keep them at the OidcUtils level for now since all this method does it used a StringTokenizer to split the parts and use Base64.urlDecoder to decode it and get JsonObject, just a few lines of code really

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit b07f165.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[michalvavrik]

adding methods we don't use without deprecations doesn't make sense to me; so we will have these unused methods there forever?

[michalvavrik]

We should probably keep them at the OidcUtils level for now since all this method does it used a StringTokenizer to split the parts and use Base64.urlDecoder to decode it and get JsonObject, just a few lines of code really

I don't think it makes sense to discuss this much, code duplication is fine, I just wanted to mention I don't think this argument is sound. I thought all the methods I moved was because I needed them at places that doesn't have dependency on OIDC utils, so why to duplicate it. If you prefer to have it in OIDC utils, no problem from my side.

[michalvavrik]

Fixes #45948.

I just read #45948 (comment) and it says I've moved over to the com.auth0:java-jwt package for decoding the token as its actually better and what I would use anyway. Is this PR going to help the user?

[michalvavrik]

Anyway, I apologize for the volume of comments, especially as I don't mind if this gets in. I just could not help thinking that this is not well argued.

[sberyozkin]

Hi @michalvavrik, np at all, I don't really mind much myself, FYI, this PR does not duplicate the code, only makes some of those users who may have found this rather handy, even if simple, utility method useful, not to change their code.

By the way, I think comparing what this method does to some libraries makes no sense IMHO, I'd rather type a few lines of code myself then bringing a lib to split a string by . and call Base64.urlDecoder() to decode one of its parts. So the related argument in the linked issue is not a good enough reason to have this PR closed :-).

In any case, I think I may have suggested a few users over the years to use it, sometimes they need to preprocess the token in filters...

May be we can have io.quarkus.oidc.JwtUtils to have a couple of methods like JsonObject decodeClaims(String jwt), JsonObject decodeHeaders(String jwt) (which would just call down to OidcCommonUtils) ?

[michalvavrik]

Thanks Sergey, just in short:

In any case, I think I may have suggested a few users over the years to use it, sometimes they need to preprocess the token in filters...

That is valid argument. But I think we need to mark it somewhere. TBH I have removed at least one method that delegated to the common utils exactly like these and normally I'd do it again. Hopefully I'll remember this.

May be we can have io.quarkus.oidc.JwtUtils to have a couple of methods like JsonObject decodeClaims(String jwt), JsonObject decodeHeaders(String jwt) (which would just call down to OidcCommonUtils) ?

I think that sounds good.