This is exactly what offline tokens where created to do. The offline token is not linked to user sessions so it doesn't matter if users login or not. Our adapters doesn't support it properly though so you'd need to create a filter or something that sets up the context and principle based on the offline token.

On 19 May 2016 at 19:56, Jesse Chahal <jessec@stytch.com> wrote:

So we've done a lot of work on our migration to keycloak but still
have a few holes that are using another authentication system. We are
using Wildfly10 along with the keycloak subsystem. The last real
blocking issues is trying to schedule background tasks on behalf of a
user using quartz. We've tried using impersonation role and mocking
out the impersonation workflow that a browser does, it was fairly
complicated and did not work very well. Service accounts don't seem to
fit this scenario either as service accounts seem to be for performing
client specific actions. We considered storing offline token's on
behalf of users but the thing is users might not log in for years
after scheduling their job. We need to set the Context and Principle
to be the user who we are performing background tasks on behalf of. Is
there a recommended way of doing this that has been tested by others?
I'm sure we aren't the only company who schedule tasks on behalf of
users.
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user