UI Scope needs to be refined:
Option 1: <wgordon> It's my understanding, for an initial deliverable, we won't need a UI. We'll definitely still need some amount of UI work...with the BYO Auth, our existing Identity Provider stuff doesn't work, so we should hide/disable that page (and I think the groups page too)

Option 2: whether we need "full" integration is unclear...it might be "good enough" to have this available in the planned "code view" instead of making input fields for this advanced configuration (if we go with this option, we need to assess UX and UI impact and scope this epic. Currently this is committed to based on Option 1)

Context on feature
A customer can configure OIDC providers to support the current capability: https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens and the future capability: https://github.com/kubernetes/kubernetes/blob/2b5d2cf910fd376a42ba9de5e4b52a53b58f9397/staging/src/k8s.io/apiserver/pkg/apis/apiserver/types.go#L164 with a mechanism that 

1. allows fixing mistakes
2. makes cluster recovery possible in cases where the external token issuer is permanently gone
3. allow (might not require, not sure yet) removal of the existing oauth server

Given likely re-use, it might be useful to allow configuration of not-commonly changing information distinct from commonly changing.  For instance, most kube cluster should have unique audiences, but the issuer-url and username-claim is probably the same for all clusters.