yes we are indeed using the OIDC discovery.
If I'm not mistaking the CA bundle used here is just needed to connect to the keycloak endpoint. So like you said, it has nothing to do with the signing cert for tokens.
In our case, we have our keycloak running behind a virtual server on F5 with a public signed digicert certificate. So for the autodiscovery CA bundle I've imported the digicert bundle so F5 can validate this.
Regarding the flows, we had the password flow working more or less out of the box. The codeflow did have an issue. We kept receiving a 401 on the userinfo requests. Is this what you see? The keycloak logs will mention something like invalid_credentials.
In our case: After some tracing and the help of F5 support (big thanks to @Stanislaw Tsiarnouski) we noticed the issue is that keycloak adds the portnumber to the host header when calling introspect / userinfo. But the issuer in the token does not contain this portnumber.. This makes keycloak fail the check. (I still have a case open at RedHat for this but no solution on their part yet..)
So what I did to work around the issue is to remove the portnumber from the Host header if specific requests are passed to the VS of our server.
As a quick and dirty example:
if {[HTTP::method] eq "POST" && [HTTP::host] eq "keycloak.company.com:443"}{
HTTP::header replace Host "keycloak.company.com"
}
This then works for both the code flow and password flow.
Do note: All requests have been custom made for keycloak (Access > Federation : OAuth Client / Resource Server : Request). Based on the info from their doc and curl-command used to obtain tokens etc. I found this the least well documented part of the entire setup actually.. 😥
HTH
Joren