Support multiple clientID for token validation

[iaean]

The dns3ld daemon uses a single auth target to validate ID tokens:

auth:
  oidc_bindings:
    https://dns3l.example.com/auth:
      client_id: dns3l-api

The auth target (Dex in our case) provides static configured client ID to support different OAuth2 flows:

staticClients:
- id: dns3l-app
  # Web based usage with Authorization Code Grant
  #   https://tools.ietf.org/html/rfc6749#section-4.1
  redirectURIs:
  - ...
  name: 'DNS3L App'
- id: dns3l-cli
  # CLI/Console usage with Resource Owner Password Credentials Grant
  #   https://tools.ietf.org/html/rfc6749#section-4.3
  secret: secret
  name: 'DNS3L CLI'

This actual pattern doesn't support CLI and Web apps because they use different flows by client ID.
The dns3ld OIDC lib rejects clients that are not providing the correct client ID with:

{"code":500,"message":"oidc: expected audience \"dns3l-api\" got [\"dns3l-app\"]"}

Solution seems to support multiple client ID:

auth:
  oidc_bindings:
    https://dns3l.example.com/auth:
      # client_id: dns3l-api
      client_id:
      - dns3l-app
      - dns3l-cli
      - dns3l-api

We are figuring out if this issue can be workarounded by Dex config for now. In case of no luck, this stops DNS3L supporting CLI and Web clients for the moment, when they implemented different OAuth2 flows. What they usually do.

Thx for a first investigation and feedback.

[iaean]

Simple sharing one client ID for both flows doesn't work:

- id: dns3l-app
  # Web based usage with Authorization Code Grant
  #   https://tools.ietf.org/html/rfc6749#section-4.1
  name: 'DNS3L App'
  public: true
  # CLI/Console usage with Resource Owner Password Credentials Grant
  #   https://tools.ietf.org/html/rfc6749#section-4.3
  secret: secret

Results in level=info msg="missing client_secret on token request for client: dns3l-app"

[iaean]

Seems we can workaround the issue with Dex Cross-client trust and authorized party feature:

- id: dns3ld
  # dns3ld can only validate against a single client ID actually...
  secret: secret
  name: 'DNS3L daemon validator'
  trustedPeers:
  - dns3l-app # add scope: audience:server:client_id:dns3ld
  - dns3l-api # add scope: audience:server:client_id:dns3ld
  - dns3l-cli # add scope: audience:server:client_id:dns3ld

Big drawback is that clients needs knowledge about the client ID that dns3ld uses for token validation which is not the client ID the client usually uses...