Complain if the env set in SecretEnv cannot be found

[SuperSandro2000]

Overview

I generated a config which contained a secretEnv with a - which is not possible and possibly the clientSecret was set to empty string instead of the value I wanted.

What this PR does / why we need it

In such cases in the future the config check should just fail.

Special notes for your reviewer

Does this PR introduce a user-facing change?

[nabokihms]

One more thing. If a warning is required, we need to add it to all os.Getenv calls, e.g., for IDEnv also.

[nabokihms]

I prefer a warning message instead of returning an error here because it may be a breaking change with the current implementation.

[SuperSandro2000]

Yeah, it should be breaking because if the env is undefined then the config is broken and not working anyway.

[nabokihms]

1. Client secret can be empty if this is a public client.
2. If there is a single invalid client in the config, it will break all the working clients.

I insist on at least making this behavior opt-in.

[SuperSandro2000]

Client secret can be empty if this is a public client.

That is unchanged. Only if the env used in secretEnv is empty or does not exist the config would break. I consider this a hard configuration error.

For example the following config is invalid because envs cannot contain dashes:

- id: oauth2_proxy
  name: example
  redirectURIs:
  - https://example.de/oauth2/callback
  secretEnv: DEX_CLIENT_oauth2-proxy

also if secretEnv is set to a variable which wasn't provided, the config would fail. Before it just silently continued.

If there is a single invalid client in the config, it will break all the working clients.

It would probably require more refactoring of the client loading logic, to skip invalid clients.

I insist on at least making this behavior opt-in.

Should we allow end users to run with known broken configs? I am not sure what the security implications are when you run with a public client but intended to run with a secret. It probably breaks the security expectations and all clients being broken by this where broken anyway and didn't work correct.

[SuperSandro2000]

If a warning is required, we need to add it to all os.Getenv calls, e.g., for IDEnv also.

I've added it to all dynamic os.Getenv calls except for k8s because I wasn't sure if those are standard env variables.