[keycloak-dev] offline access permission incorrect?

Wed Apr 4 12:23:32 EDT 2018

I'd say I agree with you but I haven't fully digested Marek's client scope
proposal yet, need to give it a spin first.

To summarize what we currently have:
A client X (with consent required enabled) may require offline-access to
request data from another backend-service.
When a user accesses an application part of X that requires data from a
backend-service then X may redirect the user
to a consent page asking the user to give consent to enable X to use
offline-access.
If the user grants this consent X will retrieve the offline-token (special
refresh-token) which enables X to retrieve
access-tokens for accessing the backend-service on the users behalf but
without requiring user interaction.

That's how it currently works.

It works great, but as said the client X can access the backend-service as
long as it's current access-token is valid
even though the user might have just removed the offline-access capability
for client X.
It would be great if removal of consent would trigger a request to the
configured admin-url to inform
a client that consent was removed which could then instruct the client X to
destroy the current access-token.

Further more it might also be handy to be able to have hierarchical scopes
like we currently have for roles
(don't know whether this is already in Marek's proposal). So one could say
offline-support for client X
includes/requires consent for scope S1 and S2 or event better: scope
"thirdparty-access" includes/requires consent
for offline_access and scope S1 and S2.
This would enable to configure different access scenarios without requiring
clients to know all scopes in detail.

Regarding the limited scope support:
Yes, I also think that the scope support is currently a bit inflexible due
to the tight coupling to roles.
Other systems like the UAA OAuth Server of Cloud Foundry use a more
flexible scope model:
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Security.md#token-scope-rules
which is also a bit too generic IMHO since they even treat roles /
authorities as scope.

2018-04-04 17:46 GMT+02:00 Bill Burke <bburke at redhat.com>:

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