OpenId endpoints are http and https

Getting advice
1

Hello everyone.

I just updated from v22 to v25.0.1.
When I look at ./realms/master/.well-known/openid-configuration on both master and custom realm, I see that my urls are sometimes https and sometimes http.

Didn’t have that in the previous version.

{
  "issuer": "https://mydomain.com/auth/realms/myrealm",
  "authorization_endpoint": "https://mydomain.com/auth/realms/myrealm/protocol/openid-connect/auth",
  "token_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/token",
  "introspection_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/token/introspect",
  "userinfo_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/userinfo",
  "end_session_endpoint": "https://mydomain.com/auth/realms/myrealm/protocol/openid-connect/logout",
  "frontchannel_logout_session_supported": true,
  "frontchannel_logout_supported": true,
  "jwks_uri": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/certs",
  "check_session_iframe": "https://mydomain.com/auth/realms/myrealm/protocol/openid-connect/login-status-iframe.html",

....


  "require_pushed_authorization_requests": false,
  "pushed_authorization_request_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/ext/par/request",
  "mtls_endpoint_aliases": {
    "token_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/token",
    "revocation_endpoint": "https://mydomain.com/auth/realms/myrealm/protocol/openid-connect/revoke",
    "introspection_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/token/introspect",
    "device_authorization_endpoint": "https://mydomain.com/auth/realms/myrealm/protocol/openid-connect/auth/device",
    "registration_endpoint": "http://mydomain.com/auth/realms/myrealm/clients-registrations/openid-connect",
    "userinfo_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/userinfo",
    "pushed_authorization_request_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/ext/par/request",
    "backchannel_authentication_endpoint": "http://mydomain.com/auth/realms/myrealm/protocol/openid-connect/ext/ciba/auth"
  },
  "authorization_response_iss_parameter_supported": true
}

Is this config related or could it be a bug introduced in v25 and hostname v2 changes?
The ones concerned seems to be the same as the one impacted by admin url ( OpenID Endpoint Configuration wrong urls after updating - Configuring the server - Keycloak)

Thanks in advance!

2

Hi, with which protocol did you request the Well-known endpoint when you received the response shown in your post?

Its just a guess based on similar observations I had with internal and external domain names, but I think it could potentially be caused by the dynamic backchannel resolution setting (hostname-backchannel-dynamic), which resolves the URLs for all backend endpoints based on the hostname used to request Keycloak. See the documentation for details on the different channels: Configuring the hostname (v2) - Keycloak

So in your case, I thinkt you might have requested the Well-Known-Endpoint with HTTP and hence received HTTP URLs for all backchannel endpoints as the response, since the authorization endpoint URL, which is part of the frontend channel from my understanding, is using HTTPs.

Not sure if this is a new feature of hostname:v2 however, so I might be wrong.

3

Hello Janek,

I was using https to get the configuration.

But as you suggested, backchannel-dynamic option is set to true in my configuration.
I enabled it otherwise other service in kubernetes were unable to contact keycloak as “keycloak-service” (inside kubernetes) was redirected to the public url. And health checks were failing due to that.

In my CRD, i set hostname, hostname-admin and hostname-backchannel-dynamic parameters.
In my case hostname and hostname-admin url are the same.

I enabled the hostname-debug option, and I see that the BACKEND value is
http://mydomain.com/auth/ [FAILED] where the FRONTEND one is https://mydomain.com/auth/ [OK]

I removed the backchannel-dynamic parameter, and now https on all routes and no more “FAILED” in hostname-debug page.

4

Small precision, it’s not my healthchek which are failing but my reverse proxy which is unable to retrieve certificate based on keycloak-service:8080 url which is switched to mydomain.com.

Seems like enabling dynamic back channel allows the communication inside the K8s cluster, but has an impact on OIDC endpoints.

5

Is your proxy forwarding the XFF headers? In 25, it is mandatory and the new way to indicate a proxy is in front of your Keycloak.

Do a test by deploying an HTTP echo container (i.e. mendhak/http-https-echo) and call it behind your proxy. See what headers come out.

Basically, if x-forwarded-port/proto are not 443/https, this may be your issue.

1 Like
6

We’re seeing the exact same behavior after moving to 26.0.5. XFF headers are set. It seems like a bug