SPA and BFF with no sessions

[ASarco]

I'm designing a solution for authentication with Keycloak for an existing set of microservices.
My PoC works fine using Spring Gateway and BFF in the same box, using session cookie to maintain the session. But since our architecture requires more than a single instance of the Gateway/BFF for resilience and performance, that means that we need to do some persistent and distributed session keeping (which I successfully tried using Redis and Spring HTTP Session).
Now, is there a realistic way to avoid using sessions? I read somewhere they mentioned sending the encrypted token in a cookie (instead of the session cookie), so the token would already present in the request and there's no need to keep session that need to be exchanged for the token in the BFF).
What do you think about this, know of any implementation, or any pointers to be able to make my own?
Thanks!

[ch4mpy]

@ASarco this is an interesting question (and you obviously have thought about it already).

sending the encrypted token in a cookie

Actually it would be sending the encrypted tokens in a cookie (access, refresh and ID tokens). That's:

• More data with each and every request.
• More processing: serious encryption & decryption cost time and CPU.

What do you think about this?

To me, it is:

• Over complicated. It requires to provide with:
  • A custom authorized-client repository / service @Bean based on cookies instead of session.
  • Some encryption keys rotation.
• Risky: sending tokens over the network, even encrypted, is more dangerous than keeping it in server memory.
• Not necessarily a huge gain of resources (network & CPU) and latency (encryption / decryption time).
• Ruining the chances to instantly revoke an access to resources. Access JWTs remain valid until it expire. If you keep it on the server, you can delete it when you want to stop an access (logout or other sessions invalidation), but if you send it over the network, all you can do is waiting for it to expire.

Sure, keeping state on the server is not ideal. I know at least two options for an impl, but both have drawbacks:

• Spring Session (as you are using apparently) introduces some latency: restoring a session from Redis takes some ms (but, again, what about serious encryption / decryption of tokens?).
• "Smart" proxies routing all requests from a given device to the same BFF instance: when an existing instance is replaced, all the sessions it contained have to be re-build on next requests. This requires a loop to the authorization server to get new tokens, which increase latency for this first requests and puts extra load on the authorization server.

At the end of the day, I prefer to keep tokens on the server because neither of this drawbacks seems to be a real show-stopper: the latences we are talking about are really low and the server memory needed to store tokens in session is acceptable.

Please note that I haven't run any benchmark to mesure the actual impact of each solution (latency with Spring Session, latency after an instance crash with smart proxy, latency and network cost with encrypted tokens stored in cookies).

[ASarco]

@ch4mpy Thank you very much for taking the time to write such a detailed answer. It's very clear and really helpful.

One more question, not directly related to this: In your Baeldung article about BFF and Spring Gateway, you show 2 separate boxes, the BFF with Spring-oauth2-client, and a reverse proxy with Spring gateway. Why are you using 2 boxes for this, instead of one with both things?

[ch4mpy]

There is no need for the SPA assets to be served through the BFF, there is just a need for the two to share the same origin. Separating the reverse-proxy and the OAuth2 BFF has several advantages:

• Educational: splitting them better demos that.
• Depending on the execution environment, there are probably more natural choices than Spring Cloud Gateway for a reverse-proxy (Nginx on docker, an Ingress in K8s, ...). If the two are separated, one can easily keep using what he's used to for the reverse-proxy.
• A simple reverse-proxy can be stateless but an OAuth2 BFF can't (at least, not if it keeps tokens in session). Removing responsibilities from the only stateful process in the system can save resources in a scalable environment.