Auth provider extensibility: stop requiring a core code change for every new SSO/OAuth/OIDC vendor

[Damans227]

PR #13499 adds ForgeRock as a second OIDC provider on top of the existing Keycloak one. Both run the exact same authorize-code exchange, JWT parse, and email-claim flow, no vendor-specific logic, just a new Java class per name. The author flagged this themselves and the PR is on hold while #13854 (a generic OIDC provider type, one bean instead of N vendor subclasses) gets discussed.

That's a narrow fix, scoped to OIDC. The bigger question: should auth providers be an extension point rather than a fixed set of compiled classes, so a new SSO/OAuth/OIDC vendor can be registered without a core code change at all? Right now, onboarding any new vendor means a PR to core, a wait on review, and a release cycle, even when the protocol underneath (OAuth2, OIDC) is one we already fully support.

Would like input from the architects and from @bddvlpr, since PR #13499/#13854 already started this conversation, on scope: is solving #13854 for OIDC alone enough for now, or is it worth designing a general auth extension point up front so this doesn't get solved piecemeal per protocol later?

cc @DaanHoogland @weizhouapache @harikrishna-patnala @bddvlpr

[DaanHoogland]

+1 for the new extension type from me.