[Feature] Use OIDC discoveryURL to construct authURL

[Legion2]

Problem Statement

I want to integrate a OIDC provider for authentication. For its configuration I have the clientID, clientSecret and discoveryURL from the oidc provider. But currently to configure OIDC in kubecost I also need to specify a authURL with all required parameters hardcoded in the url.

Solution Description

The discoveryURL should be used to discover all other required information, such as the authURL. On login the user should be redirected to the authUrl with all required parameter automatically added. If required additional parameters should be configurable. The kubecost should also add a nonce (state) parameter automatically as defined by the oidc spec.

Alternatives

Use the hardcoded authUrl with all parameters (redundant) and nonce parameter state (insecure).

Additional Context

I'm setting up Auth0 as OIDC provider, but this feature request applies to all OIDC spec compliant OIDC providers.

Troubleshooting

• [X] I have read and followed the issue guidelines and this is a feature request only for the Kubecost application.
• [X] I have searched other issues in this repository and mine is not recorded.

[AjayTripathy]

Hi @Legion2 this feels like two separate issues, right?

1. Add a nonce parameter for additional security
2. Implement support for a discoveryURL.

Can we split these into two separate issues? I'd be supportive of prioritizing #1 since it adds additional security, but I suspect we're a little busy to get to #2 until we see a little more demand for it, since the alternative although redundant has been feasible for users so far.

[Legion2]

I would expect you are using a library which implements the OIDC spec. Because implementing a security protocol yourself is not secure. Any major oidc library should have support for both the nonce parameter and creating the authURL from the discovery document.

[AjayTripathy]

We do use a library that implements the OIDC spec. We're happy to implement the full OIDC spec, it's just a question of priority. I can't promise a timeline today for non security features.

[Legion2]

Ok then let's split the two requests, should I open two new issues?

[dwbrown2]

That would be great, @Legion2! Or just rename this request + create one new one.

[AjayTripathy]

This is still on our radar. @thomasvn I wonder if you can pick this up after the holidays?

[thomasvn]

This is something we can certainly do, and should do at some point! cc @kaelanspatel

Note, our initial design decision was to intentionally have the user configure params for the authURL because each identity provider has different requirements for these params. For example, this is what current values would look like for EntraID:

oidc:
  enabled: true
  useIDToken: true
  clientID: "REDACTED"
  clientSecret: "REDACTED"
  authURL: "https://login.microsoftonline.com/REDACTED/oauth2/v2.0/authorize?client_id=REDACTED&response_type=code&scope=openid&nonce=11092863"
  secretName: "kubecost-oidc-secret"
  loginRedirectURL: "https://kubecost.myexample.com/model/oidc/authorize"
  discoveryURL: "https://login.microsoftonline.com/REDACTED/v2.0/.well-known/openid-configuration"

[chipzoller]

Hello, in an effort to consolidate our bug and feature request tracking, we are deprecating using GitHub to track tickets. If this issue is still outstanding and you have not done so already, please raise a request at https://support.kubecost.com/.