<div dir="ltr">Did you look at the offline-access-app from our examples? You could use regular login with the adapters, but when the application needs an offline token and doesn't already have one direct the user to the login and include ?scope=offline_access. If the user is already authenticated and the client doesn't require consent no login page will be displayed.</div><div class="gmail_extra"><br><div class="gmail_quote">On 20 May 2016 at 19:42, Jesse Chahal <span dir="ltr"><<a href="mailto:jessec@stytch.com" target="_blank">jessec@stytch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the info, looks like I was on the right path. After reading<br>
through the OpenID spec I came across offline tokens and saw that it<br>
was supported by keycloak. I was trying to figure out how to use<br>
offline tokens with the adapter (since it didn't seem possible to set<br>
a flag to enable the scope for this) but based on the above it isn't<br>
possible. Is it possible for a client to request an offline token<br>
using a refresh or access token? The reason I ask is because we cannot<br>
request it using the adapter system that we are currently using. Even<br>
if we could with the adapter system that would mean that for every<br>
single login we would be requesting a offline token instead of a<br>
refresh token (seems like a bad idea). It also seems like a good idea<br>
to only request the offline_token if a user decides to schedule a<br>
offline job with us. We would prefer not having to have the user login<br>
again in order to schedule an offline job. I did some initial tests<br>
using a rest client and it did not seem possible.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, May 19, 2016 at 10:34 PM, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>> wrote:<br>
> This is exactly what offline tokens where created to do. The offline token<br>
> is not linked to user sessions so it doesn't matter if users login or not.<br>
> Our adapters doesn't support it properly though so you'd need to create a<br>
> filter or something that sets up the context and principle based on the<br>
> offline token.<br>
><br>
> On 19 May 2016 at 19:56, Jesse Chahal <<a href="mailto:jessec@stytch.com">jessec@stytch.com</a>> wrote:<br>
>><br>
>> So we've done a lot of work on our migration to keycloak but still<br>
>> have a few holes that are using another authentication system. We are<br>
>> using Wildfly10 along with the keycloak subsystem. The last real<br>
>> blocking issues is trying to schedule background tasks on behalf of a<br>
>> user using quartz. We've tried using impersonation role and mocking<br>
>> out the impersonation workflow that a browser does, it was fairly<br>
>> complicated and did not work very well. Service accounts don't seem to<br>
>> fit this scenario either as service accounts seem to be for performing<br>
>> client specific actions. We considered storing offline token's on<br>
>> behalf of users but the thing is users might not log in for years<br>
>> after scheduling their job. We need to set the Context and Principle<br>
>> to be the user who we are performing background tasks on behalf of. Is<br>
>> there a recommended way of doing this that has been tested by others?<br>
>> I'm sure we aren't the only company who schedule tasks on behalf of<br>
>> users.<br>
>> _______________________________________________<br>
>> keycloak-user mailing list<br>
>> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>