Incorporate the new NGINX Plus OIDC module into Policies object

[pdabelf5]

Add support into NGINX Ingress Controller Policies to include the new NGINX Plus ngx_http_oidc_module for OIDC flows.

There are several ways to achieve this:

• replace the existing OIDC Policy which is based on the NGINX NJS OIDC reference implementation with the ngx_http_oidc_module and drop unsupported options until they become available in the module. This will likely mean a new version of the Policy CRD, for example,v2alpha. The original OIDC Policy will still be available in the v1 CRD.
• add a new Policy that drives configuration of the ngx_http_oidc_module module alongside the existing Policy.

The existing OIDC Policy spec is

spec:
  oidc:
    clientID: nginx-plus
    clientSecret: oidc-secret
    authEndpoint: https://idp.example.com/openid-connect/auth
    authExtraArgs: []
    tokenEndpoint: https://idp.example.com/openid-connect/token
    jwksURI: https://idp.example.com/openid-connect/certs
    endSessionEndpoint: https://idp.example.com/openid-connect/logout
    scope: oidc
    redirectURI: /_codexch
    postLogoutRedirectURI: /
    zoneSyncLeeway: 200
    accessTokenEnable: true
    pkceEnable: false

Thoughts welcome.

[vepatel]

should we consider having a flag like --enable-native-oidc which switches user from njs to native implementation and keeping the CRD version same as now?
or a new policy type?

spec:
  nginxOidc:

[brianehlert]

I recommend waiting until the new module is feature complete with the current OIDC based implementation.
Or, you should consider implementing a new Policy specifically for the module and keep the new Policy in-step with the new module capabilities.

The problem you WILL get into, is supporting OIDC and the Module at the same time. Unless all OIDC settings are fully backward compatible with Module capabilities.

Even then, the OIDC implementation allows customization. And some customers have historically taken advantage of that.