[keycloak-user] Spring adapters

[Sebastien Blanc]

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 at 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/keycloak-container-adapters
)

>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user