We've discovered that the configuration of our auth.redhat.com Keycloak client does not give us the client name as an id in the decoded JWT token's aud claim, which was causing the server to reject apparently valid tokens.
This appears to violate the OIDC specification, but for flexibility (and expediency) this PR separates the configuration of "OIDC client name" and "expected aud claim" so that we can accommodate either behavior without further code changes. (That is, the openid client and audience values could be identical if we know the OIDC server follows the specification.)
PBENCH-1296
We've discovered that the configuration of our
auth.redhat.comKeycloak client does not give us theclientname as an id in the decoded JWT token'saudclaim, which was causing the server to reject apparently valid tokens.This appears to violate the OIDC specification, but for flexibility (and expediency) this PR separates the configuration of "OIDC client name" and "expected
audclaim" so that we can accommodate either behavior without further code changes. (That is, the openidclientandaudiencevalues could be identical if we know the OIDC server follows the specification.)