<div dir="ltr">What similar protocols are you referring to? In either case we don't have any support for it and it has to be done through a redirect. As I said there's no re-authentication required since the user is already authenticated. To the user it would just look like they are opening the page to schedule background jobs and no additional UI pages are displayed to them.</div><div class="gmail_extra"><br><div class="gmail_quote">On 26 May 2016 at 02:25, 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">I did not look at the example but as you can see from the end of the<br>
last email we would very much like to not redirect the user back to<br>
the login screen. I assumed this was a possible way of getting an<br>
offline_token already as it would be comparable to other applications<br>
using similar protocols asking for elevated permissions. Usually those<br>
other applications would be using an external identity provider. This<br>
starts to reduce the native feel of the authentication system<br>
(keycloak) + the application. Our application is a 1st party app<br>
(meaning keycloak+app should appear to be a single app) and our UX<br>
team is very much against the experience provided by requiring<br>
reauthentication to schedule background jobs with ourselves.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, May 24, 2016 at 10:01 PM, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>> wrote:<br>
> Did you look at the offline-access-app from our examples? You could use<br>
> regular login with the adapters, but when the application needs an offline<br>
> token and doesn't already have one direct the user to the login and include<br>
> ?scope=offline_access. If the user is already authenticated and the client<br>
> doesn't require consent no login page will be displayed.<br>
><br>
> On 20 May 2016 at 19:42, Jesse Chahal <<a href="mailto:jessec@stytch.com">jessec@stytch.com</a>> wrote:<br>
>><br>
>> 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>
>><br>
>> On Thu, May 19, 2016 at 10:34 PM, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>><br>
>> wrote:<br>
>> > This is exactly what offline tokens where created to do. The offline<br>
>> > token<br>
>> > is not linked to user sessions so it doesn't matter if users login or<br>
>> > not.<br>
>> > Our adapters doesn't support it properly though so you'd need to create<br>
>> > 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>
><br>
><br>
</div></div></blockquote></div><br></div>