[keycloak-dev] Client and Service Account Session

[Thomas Darimont]

Hello Jörg,

I built an example app that demonstrates this spring-boot-admin / Keycloak
setup.

Would it help to use offline_tokens for the spring-boot-admin service
account instead of normal refresh-tokens?

Unfortunately the Keycloak Admin client library currently does not support
custom scopes like scope=offline_access.

I just pushed a PoC with patched offline_access support via a custom
TokenManager. Would you mind giving it a try?
https://github.com/thomasdarimont/spring-boot-admin-keycloak-example/tree/poc/keycloak-offline-access


Cheers,
Thomas

Am Mi., 13. Feb. 2019 um 10:43 Uhr schrieb Zaunegger, Jörg <
Joerg.Zaunegger at kvbawue.de>:

> Hi Pedro,
>
> In our application we are securing spring-actuator endpoints with a
> keycloak role. These endpoints are requested repeatedly (every 5 s) by an
> application called spring-boot-admin<
> https://github.com/codecentric/spring-boot-admin>. For the request
> spring-boot-admin obtains an AccessToken. Because there is a session for
> each request, we have thousands of open sessions for the service account of
> spring-boot-admin.
> Any news, suggestions or solutions on avoiding these open sessions?
>
> Thanks.
> Jörg Zaunegger
>
> -----Ursprüngliche Nachricht-----
> Von: keycloak-user-bounces at lists.jboss.org<mailto:
> keycloak-user-bounces at lists.jboss.org> <
> keycloak-user-bounces at lists.jboss.org<mailto:
> keycloak-user-bounces at lists.jboss.org>> Im Auftrag von Pedro Igor Silva
> Gesendet: Montag, 13. November 2017 09:52
> An: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> Betreff: RE: [keycloak-dev] Client and Service Account Session
>
>
> Hi,
>
> Currently, every time a confidential client tries to get a new access token
> from the token endpoint a new session is created on the server. This can
> lead to multiple active sessions for a single client/service account when
> doing multiple requests to token endpoint.
>
> To avoid that the client should store the access token/refresh token and
> use a refresh token when appropriate in case the access token has expired.
> That is fine.
>
> Now, suppose a confidential client is deployed and wants an access token. A
> new session will be created on the server. In case the application goes
> down for some reason (e.g.: container moved to a different node in
> kubernetes and without a persistent volume) and tries to get a new access
> token, we may end-up with two active sessions when asking for a new token
> after a re-deploy.
>
> What are your thoughts about re-using existing sessions when doing client
> credentials ? What could be the impact on clustering if we need (and we'll
> probably need) to update the session ?
>
> Another question would be ... Does make sense to also enable clients to
> obtain tokens without necessarily creating a session on the server ? I
> think that in most cases, you don't really want to keep track of sessions
> when doing client credentials.
>
> Regards.
> Pedro Igor
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>