5:04 a.m.
Hello guys!
I find Keycloak is a great product but I'd like to share with you some
thoughts about the Spring adapters.
First one is about token storage: by default all Spring adapters
(SpringBoot and Spring security) store all three tokens in the HTTP
session. JWT is great because it allows to propagate a trusted identity at
scale in a micro-service architecture: every service is able to verify the
token autonomously only by checking its signature; but if the store is the
HTTP session, it works only for single instance applications or you may be
back in the session replication hell for multiple instances...
Any way, the adapter offers the opportunity to store the tokens on the
client itself by concatenating the access token, the id token and the
refresh token in a single cookie separated by '__'. And it works... but the
size of the cookie is very closed to 4KB. This may seem small but at scale,
it may represent a huge bandwidth cost: imagine the overhead for a simple
'GET /api/any_resource/id + standard headers + 4KB'. It may be complicated
to use for some businesses like online gaming or retail for example.
In addition, if the Keycloak host name is something else than localhost
(i.e. longer, a real FQHN) and/or you add a few claims in the token, the
cookie weights more than 4KB, it is more than the limit allowed by the RFC
(https://tools.ietf.org/html/rfc6265#section-6.1) and the browser ignores
the cookie... thus there's no client storage (and I don't talk about
https://issues.jboss.org/browse/KEYCLOAK-4342 , but its fix is in
progress)!
I'm far from being a security expert, but it seems some people are totally
opposed to drop refresh token on the client because if it is stolen by an
attacker, it may be used for a while to generate access tokens.
So, all that points lead me to ask if we can think about a more flexible
way to store the client state? It would be great to have distinct stores
for refresh token and access token: it would give the opportunity to
release access token on the client and to store server side the refresh
token. The server side store might be implemented in many ways like the
current session store or let the developper provide its own: you can
imagine store the refresh token in a Redis cluster for example.
Another point is about the fact that the spring boot adapter isn't based on
Spring Security. It's surprising because it implies one implementation per
servlet container (instead of one for all) and may not work with Spring
5/Netty; but after discussing with @sebi2706 IRL at Devoxx France, he
explained that many users expect to user SpringBoot without Spring Security.
One more thing... 😜 The Spring Boot adapter doesn't support multi tenancy!
The need for which I'm currently working on mixes all this points : multi
tenancy, client side storage, scaling, etc. So I had to unweave half of the
components provided by the adapters to comply the requirements, but of
course it doesn't perform all checks like adapters do.
So guys, WDYT about all that stuff?
Best regards and thanks for your work!
Brice