Controlling what JCE security provider is used for signing about jwt-scala HOT 4 CLOSED

That's a good idea. Would you consider doing a PR for that? I'm not doing much Scala lately and don't really have time for this project.

from jwt-scala.

Can't we just remove the need to rely on BouncyCastle and have the library rely on what is already installed? That way, the library leaves the decision of which provider to use completely up to the user's app.

If this is an acceptable solution, I don't mind submitting a PR for this issue.

from jwt-scala.

How would you do that? Not sure how you can just import something you're not even sure is present. Also, ensure the API is the correct one.

I'm also concerned about the migration path for existing users.

from jwt-scala.

See: #126 for an initial pass. I've already tested it for my use case and it works well.

Essentially, we place the onus on the user to give a provider that meets their use case. If the user does not provide a sufficient provider for the algorithm they choose, then it will fail as expected. Otherwise, they can provide BouncyCastle or some other provider on their own if needed.

Edit: I should add, for most algorithms in the library (except two), the stock JCE provider worked perfectly fine.

In my case, I needed a FIPS-complaint provider which I provided at application boot time via config. However, this library decided to ignore the recommendation of my application, inserting its own provider and thereby weakening the security of the entire app.

I agree there is essentially a contract change which will require a user decision, but IMO the tradeoff is worth it in the long term. Would love to hear your thoughts.

from jwt-scala.