frontendUrl propert doesnt work

1

Hi

My configurations is as follows:

angular frontend App (keycloak public client)
spring boot backend app (keycloak confidentail client)
keycloak server

these all run behind an nginx in cloud foundry

what id like to achieve that communication between backend app and keycloak server happens through an internal route.

I assigned 1 public 1 internal route to my keycloak server:
https://XXXX.YYYY.ZZZZ.com/auth (this is for user authenticaiton)
https://XXXX.YYYY-internal.ZZZZ.com/auth (this is for backendapp)

i assigned below in my backend app
keycloak.auth-server-url: https://XXXX.YYYY-internal.XXXX.com/auth

and property in my realm settings
frontendUrl = https://XXXX.YYYY.ZZZZ.com/auth
(i tried setting it also in standalone.xml)

with above config user authenticaiton succeeds but afterwards when rest requests are sent to retrieve data from backend i get “invalid token issuer” error. It says:

Expected ‘https://XXXX.YYYY-internal.ZZZZ.com/auth/realms/myrealmname’, but was ‘https://XXXX.YYYY.ZZZZ.com/auth/realms/myrealmname’

How can i make this work, what is missing or wrong here?

thanks a lot

Servet

2

ok i found out how
keycloak is assigned only internal route https://XXXX.YYYY-internal.ZZZZ.com/auth
frontendUrl property is set public route https://XXXX.YYYY.ZZZZ.com/auth

backends (microservices) keycloak.auth-server-url: https://XXXX.YYYY-internal.XXXX.com/auth

thats all for keycloak

now a reverse proxy must be placed in front and it should proxy the call
https://XXXX.YYYY.ZZZZ.com/auth to https://XXXX.YYYY-internal.ZZZZ.com/auth

while proxying, the headers must also be set

this way, all keycloak calls from microservices to keycloak for token validaiton stays in private network.

3

I always had the feeling that a Reverse Proxy is required, even though I haven’t tried the “frontendUrl” option yet.

However, I figured out that the “X-Forwarded-Host” header of the forwarded request has to be rewritten which is not the default behavior for reverse proxies.
The same is possible for the “X-Forwarded-Proto” header, if the reverse proxy is simple HTTP.

Have you experienced the same or similar?

4

Finally,

When back-end and front-end endpoints are different, which is quite sensible and expected
with back-end being private and front-end public

A reverse proxy is genuinely required, to forward the real client’s IP

see https://www.keycloak.org/docs/10.0/server_installation/#identifying-client-ip-addresses

This implies use of proxy-address-forwarding=true which is controlled by PROXY_ADDRESS_FORWARDING=true environment variable in official Docker image
see https://hub.docker.com/r/jboss/keycloak

frontendUrl property is also required, to correctly generate the page redirects

see https://www.keycloak.org/docs/10.0/server_installation/index.html#default-provider

This is controlled by the KEYCLOAK_FRONTEND_URLenvironment variable in official Docker image
see https://hub.docker.com/r/jboss/keycloak

Unfortunately, with both a reverse proxy and frontendUrl set Keycloak is still getting confused about the issuer.

Invalid token issuer. Expected "internal endpoint/auth/realms/realm’, but was “public endpoint/auth/realms/realm”

5

Correction, this works.

Both a reverse proxy and “frontendUrl” are required.

Forwarded reverse proxy request headers change is only required for the last proxy in a chain of reverse proxies with “X-Forwarded-Host”, “X-Forwarded-Proto” headers of the forwarded request having to match “frontendUrl”

6

yes, with reverse proxy, headers must be set then it works. Keycloak adapter version for backends must be higher than 8 i remember

7

Indeed, if I am not mistaken, these features were introduced during the life of Keycloak 8.x, so, any version later than 8 is expected to have them.

I am using 10.0.1 at the moment.

8

i think this is a crucial feature. Without this feature, all token confirmation calls from backends to keycloak are unnecessarily going thru public internet. with this feature, all token confirmation calls stay in private network which is way more secure

9

I cannot agree more.

Indeed, this is crucial.

Back-end token verification must be private.
Front-end token acquisition must be public.

I fear many people haven’t realized the importance.

But, I am glad it works.

Also, I believe, back-end has to use confidential clients and front-end has to use public, which is what I have done for my project.

HTTPS is very much necessary as well, for security and proper cookies decoration in JavaScript adapter and others.

Application cookies must also be decorated properly, with samesite=none and httponly=true for 3rd party front-end.

It is all demanding and requires special handling but it is worth the effort.

Ilias Balasis
Mob: 07702019628

1 Like