This would be very relevant both for mobile and IoT. It would be something we'd be interested in having a contribution around. A few points from me: * Add a new session type for the realms which is longer duration. It should still have some timeouts as otherwise it will never be cleared up. * Configurable session type per client? * Request longer duration session type with scope? On Mon, 20 May 2019 at 11:32, Federico Michele Facca < federico.facca(a)martel-innovate.com&gt; wrote: > Dear All, > to better support IoT devices, we are looking to support longer expiration > for specific tokens > (when using a specific scope - in a similar way to offline_access scope). > We have been looking into: > https://github.com/looorent/keycloak-configurable-token-api > > The issue is that, while using this plugin it is possible to extend the > life of a token, > the underlying session will anyhow expire based on the max duration of > token lifespan, > so if you validate the token after the session expiration, the validation > will say that the token > is not active. > > What could be a non intrusive way to support extending the life of > specific > sessions associated > to such tokens? (i.e. without making changes to the core code). > > We thought about changing the started value in the session an put it in > the > future, but this is not actually possible. Only getStarted is available on > UserSessions. An other alternative would be to set a very long token > lifespan for the client , but the all tokens will have such long life > (which is not what we aim for). > > Any feedback / idea is welcome :) > > Cheers, > Federico > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

Hi Stian, ideally (as for offline refresh tokens) you should be able to invalidate the session manually (e.g. in case the iot device is compromised).

My understanding, is that basically you would be happy to have this in the core code, right?

At the time being, using the approach of loorent, what we have been thinking to test is attaching to the access token an offline session instead of a normal session. I will let you know if this easy experiment works out :)

Cheers, Federico On Tue, 21 May 2019 at 10:42, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > Ideally sessions like that should also be persisted, otherwise they'd get > lost during upgrades or other downtime of the server. > > On Tue, 21 May 2019 at 10:41, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> This would be very relevant both for mobile and IoT. It would be >> something we'd be interested in having a contribution around. >> >> A few points from me: >> >> * Add a new session type for the realms which is longer duration. It >> should still have some timeouts as otherwise it will never be cleared up. >> * Configurable session type per client? >> * Request longer duration session type with scope? >> >> >> On Mon, 20 May 2019 at 11:32, Federico Michele Facca < >> federico.facca(a)martel-innovate.com&gt; wrote: >> >>> Dear All, >>> to better support IoT devices, we are looking to support longer >>> expiration >>> for specific tokens >>> (when using a specific scope - in a similar way to offline_access >>> scope). >>> We have been looking into: >>> https://github.com/looorent/keycloak-configurable-token-api >>> >>> The issue is that, while using this plugin it is possible to extend the >>> life of a token, >>> the underlying session will anyhow expire based on the max duration of >>> token lifespan, >>> so if you validate the token after the session expiration, the >>> validation >>> will say that the token >>> is not active. >>> >>> What could be a non intrusive way to support extending the life of >>> specific >>> sessions associated >>> to such tokens? (i.e. without making changes to the core code). >>> >>> We thought about changing the started value in the session an put it in >>> the >>> future, but this is not actually possible. Only getStarted is available >>> on >>> UserSessions. An other alternative would be to set a very long token >>> lifespan for the client , but the all tokens will have such long life >>> (which is not what we aim for). >>> >>> Any feedback / idea is welcome :) >>> >>> Cheers, >>> Federico >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> -- *Dr. FEDERICO MICHELE FACCA* *CTO, Head of Martel Lab* +41 788075838 *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE MAKE IT HAPPEN Click *HERE* to download Martel reports and white papers! <https://www.martel-innovate.com/premium-content/> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>