Replace OpenID Connect backend library

[michael-doubez]

What feature do you want to see added?

The backend library currently used is Google OAuth Client library which brings many issues:

• the library is in maintenance mode
• the code is primarily design to work for google API - features are hard to implement or checks prevents usage of library (see Login not working if alg field is missing in jwks_uri response #304 )
• the library is pulling dependencies which are not needed or desirable for Jenkins plugin - in particular some transistive dependencies are hard to specify right

Moving to a more generic library would allow restoring advanced checked bypassed in #308.

Spring security seems to have a decent support of openid connect and is more in line with Jenkins' dependencies.

[jtnord]

the library is pulling dependencies which are not needed or desirable for Jenkins plugin - in particular some transistive dependencies are hard to specify right

spring security-oauth when I looked quickly also pulls in some undersirables (at least in terms of FIPS support). Currently the google library is in a better shape in this regard.

Anyway irrespective I would leave a note about using spring-security-oauth2-client the version ties to the version of spring which ties to the version of Jenkins (although Jenkins does not ship the oauth-client jar) . Thus an upgrade of Jenkins does bring the possibility that it could break the plugin. It may never (or rarely) happen due to backward compatibility of the Spring project, but if the client uses internal APIs then this becomes more likely.

[jtnord]

I lack permissions on this repo to assign it to myself, but I am actively working on this.

[jtnord]

#62 (comment) / #185 are problematic

I don't think we want to hold back the plugin to workaround non conformant OpenId Providers so long as we are conformant (passing the conformance tests) and we work with any conformant OpenId Providers.

Whilst we may want to add (and retain) some options for non compliant providers, I would say if we can not, it should not stop the plugin form moving on. Users with non conformant OPs can stay on the existing (working) version of the plugin, and file issues with the implementor of the OP to become conformant.

@michael-doubez WDYT?