On Tue, 21 May 2019, 14:54 Federico Michele Facca, <
ideally (as for offline refresh tokens) you should be able to invalidate
the session manually (e.g. in case the iot device is compromised).
That should be reasonable simple as it's just about allowing invalidating a
My understanding, is that basically you would be happy to have this
core code, right?
Yes, if done properly of course. This should probably start with a proposal
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 :)
Attaching to an offline session is not the right approach I think as it
detaches from the current session.
On Tue, 21 May 2019 at 10:42, Stian Thorgersen <sthorger(a)redhat.com>
> 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>
>> 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> wrote:
>>> Dear All,
>>> to better support IoT devices, we are looking to support longer
>>> for specific tokens
>>> (when using a specific scope - in a similar way to offline_access
>>> We have been looking into:
>>> 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
>>> will say that the token
>>> is not active.
>>> What could be a non intrusive way to support extending the life of
>>> 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
>>> future, but this is not actually possible. Only getStarted is available
>>> 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 :)
>>> keycloak-dev mailing list
*Dr. FEDERICO MICHELE FACCA*
*CTO, Head of Martel Lab*
*MARTEL INNOVATE* <https://www.martel-innovate.com/>
- INNOVATION, WE
MAKE IT HAPPEN
Click *HERE* to download Martel reports and white papers!
Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>