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>:
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>
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> 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