Keycloak is stripping the port from my redirect_uri in the Location header. Why?

Question

I have the following allowed redirect uri set for my client: exp://192.168.2.212:19000

After a code exchange using the following URL:

GET /auth/realms/xxxxx/protocol/openid-connect/auth?code_challenge=m71Cl...D4hw&redirect_uri=exp%3A%2F%2F192.168.2.212%3A19000&client_id=3B03...

X-Forwarded-For: 178.84.x.x
X-Forwarded-Host: oidc.production.my.domain.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: 09918a799a23
X-Real-Ip: 178.84.x.x

I get a HTTP/1.1 302 Found with the following Location field:

Location: exp://192.168.2.212?state=T0pvzPyHF6&session_state=b1cf16ad-b.....

The port is missing. My (Expo) client in android emulator then barfs about not being able to connect to 192.168.2.212 port 80. Naturally.

I am using the docker hub images 11.0.0

How can I prevent this? Is it a bug?

(The iOS version of my app uses a different redirect_uri (exp://127.0.0.1:19000), but although Keycloak strips the port there as well and it receives a Location: exp://127.0.0.1?state=T0p... it does connect to port 19000 and works fine for some reason.)

EDIT: Note that authentication works fine on iOS, and I run exactly the same Keycloak settings in iOS as Android (It's a React Native application).

Keycloak logs no error, and the following debug message:

13:24:33,365 DEBUG [org.keycloak.events] (default task-47) type=LOGIN, realmId=neemop, clientId=3B03FD35, userId=28619cd3-c51d-4756-9d06-fb47********, ipAddress=178.84.x.x, auth_method=openid-connect, auth_type=code, response_type=code, redirect_uri=exp://192.168.2.212:19000, consent=no_consent_required, code_id=a0faa4d4-6826-4c2f-9243-*******, response_mode=query, [email protected], authSessionParentId=a0faa4d4-6826-4c2f-9243-*******, authSessionTabId=-Pn******

shows the redirect_uri is parsed correctly. It's just that in the actual HTTP response the Location: header omits the port. Which imho should not happen.

Answer 1

Seems like a bug: https://issues.redhat.com/browse/KEYCLOAK-9405?_sscc=t

Tested on 12.0.4 and it still occurs. It appears to be an issue with any non-http(s) protocol