feat: Update io.jsonwebtoken to 0.12.6

[pgmarc]

Migrate from 0.9.1 to 0.12.6 API. Now Pricing4Java uses io.jsonwebtoken:jjwt-api instead of io.jsonwebtoken:jjwt to compile the library. io.jsonwebtoken:jjwt-impl and io.jsonwebtoken:jjwt-jackson depedencies are only needed for the test suite thats is why they have test scope.

Removed depedencies were:

• io.jsonwebtoken:jakarta.xml-bind-api
• org.json:json
• org.glassfish.jaxb:jaxb-runtime

Now if a user wants to use Pricing4Java api they will have to add the following dependencies with runtime scope:

<dependency>
	<groupId>io.jsonwebtoken</groupId>
	<artifactId>jjwt-impl</artifactId>
	<version>0.12.6</version>
	<scope>runtime</scope>
</dependency>
<dependency>
	<groupId>io.jsonwebtoken</groupId>
	<artifactId>jjwt-jackson</artifactId>
	<version>0.12.6</version>
	<scope>runtime</scope>
</dependency>

There are two changes in PricingContext API:

• When specifying a secret for the pricing token the given password has to be encoded as Base 64
• If the secret is too weak for the chosen algorithm it throws a WeakKeyException. This behaviour is covered in detailed in Signature Algorithm Keys section of README of repo jjwt

Some other changes involves code that is in no way used particulary in JwtUtils.

I have also bumped pom.xml version to 5.6.0-SNAPSHOT to further make some changes before making a realease in Maven repository.

[Alex-GF]

Thank you so much for the contribution. I would like to give two suggestions before merging the PR. Please add some discussion if you have another point of view.

1. Forcing to provide a key for JWT in base64 is not very "developer friendly". If the new version of the package forces the secret to have this structure, I would propose to create an interface between the developer configuring the PricingContext and the use of the getJwtSecret() method by the library. In particular, you can create a hidden method within the PricingContext (e.g. getBase64JwtSecret()) that retrieves the value returned by the original getJwtSecret method, and encode it in base64. After that, substitute all the calls to getJwtSecret of the library by the new method.
2. I love the built-in function for detecting weak secrets! However, I think that throwing an exception limits the "freedom" of the developers, I mean, maybe you're just testing the library and don't want to generate a complicate secret. With this in mind (and considering of course that having a strong secret is fundamental), I would suggest to wrap the exception with a try/catch block and just print a WARNING.

I'm looking forward to your response!

[pgmarc]

First point

You should note that when giving a password you have to take in account the key bit length requirement.
Deciding and computing/predicting the length of a String in Java is not trivial and harder than base64 . Section SecretKey Formats warns about that unencoded strings are never used. I am olso inlined with the reasons discussed by the mantainer of the library here and here

Regarding the developer friendly statement I think that developers are accostumed to dealing with that format (JWT, base64url, secrets, etc...) plus there are a lot of tools (web, CLIs, etc...) to generate base64 secrets

Options:

openssl rand -base64 32

Base64 secret key generator

Second point

I think that your aproach is not ideal due to the facts exposed in Signature Algorithms Keys. Furthermore, RFC 7518 Section 3.2 clearly states that A key of the same size as the hash output or larger MUST be used with this algorithm and throwing an exception is needed to fullfill the specification. I think is not wise to interfere in that behaviour and I don't see any benefit in doing your proposal.