spring-cloud-gateway | Spring Cloud Gateway with Keycloak for Access | Microservice library

You can start gateway in the same project, but this is a webflux based project. From documentation

Spring Cloud Gateway is built on Spring Boot 2.x, Spring WebFlux, and Project Reactor. As a consequence, many of the familiar synchronous libraries (Spring Data and Spring Security, for example) and patterns you know may not apply when you use Spring Cloud Gateway. If you are unfamiliar with these projects, we suggest you begin by reading their documentation to familiarize yourself with some of the new concepts before working with Spring Cloud Gateway.

and

Spring Cloud Gateway requires the Netty runtime provided by Spring Boot and Spring Webflux. It does not work in a traditional Servlet Container or when built as a WAR.

so you should have used spring-boot-starter-webflux instead of spring-boot-starter-web.

Alternatively, if you need to use traditional Spring MVC, consider using Spring Netflix Zuul. This project is currently in maintenance mode and Spring Gateway is the successor of it, but it should work.

Turns out that I misunderstood some basic OAuth2 concepts. The Authorization itself is working correctly when I send a JWT in the Authorization header (Implicit Flow). What did not work is the case when I tried to access a resource via the browser. I got redirected to the login page of Keycloak (Authorization Code Flow). After you sign in through the login page of Keycloak you do not receive the JWT but a Keycloak Session ID. Spring Cloud Gateway cannot perform Authorization on the basis of a Keycloak Session ID (do not know how that would work if I wanted to use Authorization Code Flow but I am using Implicit flow, so I am fine for now).

I think the problem is because you have 2 constructors, 1 is empty, 1 is autowired. Try to remove the empty constructor and move the super method inside the 2nd constructor like this.

So for anyone having a similar problem. The problem was in the spring-boot-starter-oauth2-client dependency. This made my gateway stateful, by sending back a SESSION-Cookie instead of an Access-Token from the authorization server.

Unfortunately i couldn't use the official Spring-Boot-Adapter, provided by Keycloak (https://www.keycloak.org/docs/latest/securing_apps/#_spring_boot_adapter) because this Adapter has some web dependencies, and as the spring-cloud-gateway is built on webflux, the web dependencies required by keycloak cannot be used in conjunction.

My solution is, to not use the spring-cloud-gateway anymore, but the spring-cloud-starter-netflix-zuul gateway. This is built on web, and not on webflux, so i was able to use the official Spring-Boot-Adapter by keycloak with it.

Basically never trust the JWT.

Finally, the Resource Server needs to know where it can find the public keys to validate the authenticity of the access token which it has been given. The UAA provides an endpoint which both the Resource Server and the Gateway rely upon at runtime to do this check. The endpoint is configured in the application.yml for each application

The resource server can never be 100% sure that the access-token was created by the Identity-Provider, or even came from the gateway. So at least, you should make sure that the access-token was signed by the Identity-Provider by using the public key, exposed by a configured endpoint.

Thanks to @DavidMaze for making me notice this.

Seems like I was being a bit of a fool. My apps are sending network requests to localhost. This works fine when they are all running outside of a container. When in a container they need to be sending requests to the names of the other containers. For example:

app_1 runs on port 8080 app_2 runs on port 5000

When running outside of docker, app_1 could send a network request to app_2 via http://localhost:5000. This does not work inside of a container as nothing is running on localhost:5000 in that container. Instead, it will need to reference the other container eg: http://app_2:5000.

The problem had nothing to do with the spring-cloud-gateway configuration. On Insomnia I had to specify

You could fix it from the Spring Boot side. I mean, you could:

1. Enable the Vue Router history mode like explained in the documentation here
2. Build a Spring Boot forwarding controller like this:

The problem was, the greenwich version of those apis was beta. Now the object expected in CACHED_REQUEST_BODY_ATTR is required to be a PooledDataBuffer. So I changed my code accordinly now. Which looks like as following now: