What is the use case?

What is the use case?

My use-case is this that I am working on the Google Prometheus Operator for Kubernetes (which we call Managed Prometheus).

We want to provide OAuth2 support and there's essentially two flows: User provides the client secret in a Kubernetes secret or they don't. If they do not specify a Kubernetes secret, the only way to get an empty client secret is to create an empty file and use that, and that involves a lot of setup: create a new empty directory, then use bash script to create an empty file, then mount it to the Prometheus instances and finally update the Prometheus configuration. If the inline client secrets was consistent and allowed empty client secrets like the file option, that would simplify my use-case dramatically. It would essentially be 1 step which is to just not provide the field in the Prometheus configuration.

Why allow users to provide an empty client secret? Because the spec allows for it and some users might want it. For example, they may want to create a simple OAuth2 server which skips secret validation. If you Google-search for "oauth2 empty client string" you will see a plethora of users asking for the feature in various frameworks. It seems it's a common issue that applications do not implement the OAuth2 specification fully.

Hi @roidelapluie friendly ping :) do you have any thoughts on the motivating statements?

As an additional motivating factor, BasicAuth password and Authorization Header credentials both accept empty strings. As mentioned in my other posts, a workaround is to create a client_secret_file with empty contents but it involves extraneous setup in the Kubernetes world.