[keycloak-dev] offline access permission incorrect?

[Bill Burke]

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 at googlemail.com> 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 at redhat.com>:
>>
>> 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 at redhat.com>
>> > 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 at redhat.com> 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 at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >>
>> >
>> >
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat