Re: [keycloak-dev] offline access permission incorrect?

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