Thanks for the info, looks like I was on the right path. After reading
through the OpenID spec I came across offline tokens and saw that it
was supported by keycloak. I was trying to figure out how to use
offline tokens with the adapter (since it didn't seem possible to set
a flag to enable the scope for this) but based on the above it isn't
possible. Is it possible for a client to request an offline token
using a refresh or access token? The reason I ask is because we cannot
request it using the adapter system that we are currently using. Even
if we could with the adapter system that would mean that for every
single login we would be requesting a offline token instead of a
refresh token (seems like a bad idea). It also seems like a good idea
to only request the offline_token if a user decides to schedule a
offline job with us. We would prefer not having to have the user login
again in order to schedule an offline job. I did some initial tests
using a rest client and it did not seem possible.

On Thu, May 19, 2016 at 10:34 PM, Stian Thorgersen <sthorger@redhat.com> wrote:
> 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
>
>