7:07 a.m.
Hi Brice !
Thanks for your email ;)
I really hope the rest of the community will reply as well since most of
the questions you raise go beyond the scope of just the Spring Adapters,
Some answers inline
On Thu, Apr 20, 2017 at 12:04 PM, Brice <bleporini(a)gmail.com> wrote:
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...
Isn't this where sticky/replicated sessions solve this use case ?
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)!
So, on this one I really need opinions from the rest of the teams and that
could be affecting all our adapters.
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.
For sure, we can discuss on how to make it more flexible. At Devoxx, I
think you mentioned that you had already started something on that, you
could open a ticket + PR to boostrap the discussion around this.
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.
Yes, these are not official numbers but I think that around 40% of the
users uses SB adapter without Spring Security.
But I'm currently discussing with the Pivotal guys to make it easier
regarding the servlet container stuff. One option (that I still must
discuss with my team ;) ) is to provide a web-constainer-adapter , which is
in fact a shadded package of the tomcat/jetty/undertow adapters. This way
you would just to add this dep regardless of the servlet container being
used. (
https://github.com/sebastienblanc/keycloak/tree/spring_starter/misc/keycl...
)
One more thing... 😜 The Spring Boot adapter doesn't support multi tenancy!
True ! Is that for instance something on which you could contribute by
sharing your solution ?
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!
Thanks !
Brice
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user