To enable offline access the user must have the offline access role and the client must have that role in its scope... This just doesn't seem right to me. IMO, this shouldn't be something you assign permission to a user. Its solely a client permission and should not be something role-based. Instead the client should be marked as allowing to ask for offline access and whether or not the client must ask consent for this. -- Bill Burke Red Hat _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I was thinking that people may have usecase, when they don't want all users to allow automatically ask for offline tokens? Currently offline_access is realm default role, so all users are automatically allowed to "request" offline tokens. But was thinking that someone may want also the opposite use-case. For example allow just admin user to request offline tokens, but ensure that other users are not allowed to request it. If you think, we can remove this capability. We can see if people claims that they want to add it back :) Nobody specifically requested that capability as it's there since the beginning of the offline tokens support. In clientScope PR, there is "offline_access" client scope, but "offline_access" realm role is also still there and it's assigned as "role scope mapping" to the offline_access clientScope. So clientScope PR still requires users to be in "offline_access" role. If you want to change the behaviour, it will be nice to do that after clientScope PR is merged, however if it blocks you, it's likely fine to do it now. The clientScope PR will then need to be updated later as there would be some conflicts... Marek Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a): > +1 > > On 3 April 2018 at 00:16, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> To enable offline access the user must have the offline access role >> and the client must have that role in its scope... >> >> This just doesn't seem right to me. IMO, this shouldn't be something >> you assign permission to a user. Its solely a client permission and >> should not be something role-based. Instead the client should be >> marked as allowing to ask for offline access and whether or not the >> client must ask consent for this. >> >> -- >> Bill Burke >> Red Hat >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

Yes, but users can be theoretically aware of it and manually add "scope=offline_access" to the URL and have the offline token successfully issued. Our public clients are allowed to request offline tokens, so user will have offline token as well and use it anytime later without require other re-authentication. But I am not sure if it's real concern or not... I agree we can remove this. We can see if people claim that they want to add it back... Marek Dne 4.4.2018 v 14:00 Bill Burke napsal(a): > Users don't request offline access. Applications do. Users will not > even know about OIDC, Oauth, offline access etc... > > On Wed, Apr 4, 2018 at 7:48 AM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >> I was thinking that people may have usecase, when they don't want all users >> to allow automatically ask for offline tokens? Currently offline_access is >> realm default role, so all users are automatically allowed to "request" >> offline tokens. But was thinking that someone may want also the opposite >> use-case. For example allow just admin user to request offline tokens, but >> ensure that other users are not allowed to request it. >> >> If you think, we can remove this capability. We can see if people claims >> that they want to add it back :) Nobody specifically requested that >> capability as it's there since the beginning of the offline tokens support. >> >> In clientScope PR, there is "offline_access" client scope, but >> "offline_access" realm role is also still there and it's assigned as "role >> scope mapping" to the offline_access clientScope. So clientScope PR still >> requires users to be in "offline_access" role. If you want to change the >> behaviour, it will be nice to do that after clientScope PR is merged, >> however if it blocks you, it's likely fine to do it now. The clientScope PR >> will then need to be updated later as there would be some conflicts... >> >> Marek >> >> >> Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a): >> >>> +1 >>> >>> On 3 April 2018 at 00:16, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>>> To enable offline access the user must have the offline access role >>>> and the client must have that role in its scope... >>>> >>>> This just doesn't seem right to me. IMO, this shouldn't be something >>>> you assign permission to a user. Its solely a client permission and >>>> should not be something role-based. Instead the client should be >>>> marked as allowing to ask for offline access and whether or not the >>>> client must ask consent for this. >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Thomas, so you're agreeing with me? I think Marek's client scope work should be the basis of allowing offline access. Client is can ask for "offline-access" scope and its configured if consent is required or not. Since we have never had proper scope support (as Pedro kept telling me over and over), the role-based way was the only way to do this sort of thing. On Wed, Apr 4, 2018 at 11:42 AM, Thomas Darimont <thomas.darimont(a)googlemail.com&gt; wrote: > I think one scenario where a user needs to grant offline-access > to client-a for another client-b is integrating with third-party apps. > > A third-party app could be represented as a client in Keycloak in order > to define client specific roles and assign them to a user. > This third-party app might periodically request data from a > bearer-only backend-service client on behalf of the user, > without requiring the user to be logged in all the time. > Also the third-party may not necessarily be (fully) integrated with > Keycloak. > > A user grants offline-access to the third-party client via a initial > "connect step". > In the connect step the user is asked for consent to grant offline-access > (including other scopes) > to the third-party client whose roles include an access/reader/user role for > backend-service. > > The third-party client now receives a new refresh-token (offline-token) > which enables > the third-party client to retrieve new access-tokens for requesting data > from the backend-service. > > The user can now see the granted offline-access consent for the third-party > application > in the applications section of the account page. > If the user wants to deactivate access for the third-party app, he just > removes the > granted offline-access scope in the account page. Once the access-token > currently used by > the third-party client has timed-out it cannot request new access-tokens > anymore. > > Currently granting offline-access to a client is quite an extensive > permission > since it might enable a third-party service to access other clients as well > thus clients need apply some additional checks for tokens retrieved for > offline-access. > > With the support for more flexible custom scopes this can be mitigated a bit > by defining > custom scopes like "timesheet.read" that encompasses or are combined with > offline-access. > > I demonstrated such an integration scenario to Sébastien Blanc at the > JavaLand conference. > > Cheers, > Thomas > > 2018-04-04 14:12 GMT+02:00 Marek Posolda <mposolda(a)redhat.com&gt;: >> >> Yes, but users can be theoretically aware of it and manually add >> "scope=offline_access" to the URL and have the offline token >> successfully issued. Our public clients are allowed to request offline >> tokens, so user will have offline token as well and use it anytime later >> without require other re-authentication. But I am not sure if it's real >> concern or not... >> >> I agree we can remove this. We can see if people claim that they want to >> add it back... >> >> >> Marek >> >> Dne 4.4.2018 v 14:00 Bill Burke napsal(a): >> > Users don't request offline access. Applications do. Users will not >> > even know about OIDC, Oauth, offline access etc... >> > >> > On Wed, Apr 4, 2018 at 7:48 AM, Marek Posolda <mposolda(a)redhat.com&gt; >> > wrote: >> >> I was thinking that people may have usecase, when they don't want all >> >> users >> >> to allow automatically ask for offline tokens? Currently offline_access >> >> is >> >> realm default role, so all users are automatically allowed to "request" >> >> offline tokens. But was thinking that someone may want also the >> >> opposite >> >> use-case. For example allow just admin user to request offline tokens, >> >> but >> >> ensure that other users are not allowed to request it. >> >> >> >> If you think, we can remove this capability. We can see if people >> >> claims >> >> that they want to add it back :) Nobody specifically requested that >> >> capability as it's there since the beginning of the offline tokens >> >> support. >> >> >> >> In clientScope PR, there is "offline_access" client scope, but >> >> "offline_access" realm role is also still there and it's assigned as >> >> "role >> >> scope mapping" to the offline_access clientScope. So clientScope PR >> >> still >> >> requires users to be in "offline_access" role. If you want to change >> >> the >> >> behaviour, it will be nice to do that after clientScope PR is merged, >> >> however if it blocks you, it's likely fine to do it now. The >> >> clientScope PR >> >> will then need to be updated later as there would be some conflicts... >> >> >> >> Marek >> >> >> >> >> >> Dne 3.4.2018 v 11:21 Stian Thorgersen napsal(a): >> >> >> >>> +1 >> >>> >> >>> On 3 April 2018 at 00:16, Bill Burke <bburke(a)redhat.com&gt; wrote: >> >>> >> >>>> To enable offline access the user must have the offline access role >> >>>> and the client must have that role in its scope... >> >>>> >> >>>> This just doesn't seem right to me. IMO, this shouldn't be something >> >>>> you assign permission to a user. Its solely a client permission and >> >>>> should not be something role-based. Instead the client should be >> >>>> marked as allowing to ask for offline access and whether or not the >> >>>> client must ask consent for this. >> >>>> >> >>>> -- >> >>>> Bill Burke >> >>>> Red Hat >> >>>> _______________________________________________ >> >>>> keycloak-dev mailing list >> >>>> keycloak-dev(a)lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>> >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev(a)lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> > >> > >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- Bill Burke Red Hat