Vulnerability in the adl4j dependency

[NikolayMetchev]

Describe the bug
It appears you are using an archived version of adl4j which has a vulnerability: AzureAD/azure-activedirectory-library-for-java#309
It seems you need to upgrade to this library:
https://mvnrepository.com/artifact/com.nimbusds/oauth2-oidc-sdk

The downstream vulnerabilities:
https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748
https://security.snyk.io/vuln/SNYK-JAVA-COMNIMBUSDS-6247633

Client Version
20.0.0

Kubernetes Version
N/A

Java Version
17

To Reproduce
Run a vulnerability scan

Expected behavior
A clean vulnerability scan

KubeConfig
N/A

Server (please complete the following information):
N/A

Additional context
N/A

[brendandburns]

Looks like we need to upgrade to a different library (MSAL4J).

We'd be happy to take PRs for that, or we'll get to it eventually.

[hritikchaudhary]

/assign

[nielsreijers]

/assign

[nielsreijers]

I have some spare time and would be happy to look into this. But as a first contributor it may take a bit more time than for someone already familiar with the code.

[nielsreijers]

@brendandburns quick question:

I noticed a similar issue for the python client (kubernetes-client/python#1983) where you mention in-tree providers are being deprecated in favour of exec providers, and that for the Python client it might be better to remove the code altogether since Azure now has kubelogin.

If I read KubeConfig.java:239 right, the Java client also supports exec providers, so would it be better to simply remove the native code in the Java client as well?

(and a small side question: it seems all three native providers get registered twice, once via the static constructor in KubeConfig, and then again via the static constructors in each class. I suppose it doesn't do any harm since the authenticators map would just keep the last one added, but I was curious if there's any reason for this?)