[keycloak-dev] offline access

Thu Apr 9 08:01:09 EDT 2015

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 3 April, 2015 4:02:04 PM
> Subject: Re: [keycloak-dev] offline access
> 
> Maybe we should use name "offline tokens" to not confuse them with
> classic "refresh tokens" ? Refresh tokens are used to refresh access
> token and they are always tight to user session, when "offline tokens"
> are not tight to user session.

I don't think there's anything in OpenID Connect that ties a refresh token to a user session, that's just what we've done.

See http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess

> 
> Also IMO it should be possible that user grants access to client for
> store offline tokens in account management, not just on consent screen
> after login.
> 
> I think one of the important usecases for offline tokens would be long
> running non-web services (For example daemon service, which is running
> in background and doing periodic task on behalf of user once per day).
> Hence we should have possibility to grant offline tokens also to non-web
> applications (in other words, via Direct Access Grant). In this case,
> user might need to grant the access to the application in advance via
> Account mgmt.

Interesting idea. If offline access is just a role/scope we can do the same for any grants. That would let a user go into account management and grant a specific client access to any roles, which would make it possible to have an option for a client to require consent when using direct access as well.

But, thinking about it some more requiring consent for direct access is a bit pointless. For direct grant the user provides the client with the username/password so it would be very easy for a malicious client to circumvent requiring consent. For example by storing username/password in plain-text and use that to obtain tokens on behalf of other clients and/or login to account management or other apps directly. 

It's implied that a user has to trust the client (and consents to giving the client full access) when providing the client with the username/password directly. That is unless we add an option where a user can create client specific passwords, in which case a user could limit what roles are permitted for a specific password.

> 
> Marek
> 
> On 2.4.2015 13:52, Stian Thorgersen wrote:
> > Had an idea about offline tokens.
> >
> > When a user grants a client access we need to start persisting that so we
> > don't ask the user again and again for the same permissions to be given to
> > the application. This has to be stored permanently and not in user
> > session. That's the mechanism we should use for offline tokens.
> >
> > When a user grants an application offline access that grant is persisted.
> > This should be a special role. The grant should have an id and consist of:
> > grant_id, user_id, client_id, role_id. If a refresh token has the offline
> > scope it doesn't have to refer to a user session (or client session).
> > Instead all the required information should be kept in the refresh token.
> > The refresh token has a reference to the grant_id. If the grant with the
> > specific grant_id exists we know the user hasn't revoked the access for
> > the application. If it doesn't exist we know the user has revoked the
> > access and the "offline" refresh token is invalid.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 1 April, 2015 7:26:06 PM
> >> Subject: Re: [keycloak-dev] offline access
> >>
> >> I'm not to keen on that idea.
> >>
> >> offline is a standard scope in OIDC and an application requests this when
> >> first retrieving the token. When an application retrieves a refresh token
> >> with the offline scope set it should not be linked with the user session.
> >> Instead it should be stored permanently as the application now should have
> >> permanent offline access to the users account. If a user decides to revoke
> >> the applications access that should be done by going to the account
> >> management console and viewing client that have access to their account.
> >> This page should list all available clients, what clients have persisted
> >> grants, as well as what clients have offline access to their account. From
> >> the same page they should be able to revoke access from any client.
> >>
> >> As user sessions are not persisted they are not suitable to store offline
> >> tokens. Offline tokens will often have a very long expiration time, a year
> >> or even no expiration time at all (only manual revoking).
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 1 April, 2015 4:53:45 PM
> >>> Subject: [keycloak-dev] offline access
> >>>
> >>> Wanted to discuss again how offline access might be implemented.  IMO,
> >>> offline access should be a REST api.  Clients would request offline
> >>> access and the UserSession would be cloned and the ClientSession would
> >>> be cloned for that particular client.  ID, Access token and refresh
> >>> token would also be regenerated and sent back with the response.
> >>>
> >>> With this approach, the admin console and user account session
> >>> management pages will just work.  These pages will just work they way
> >>> they already work with no extra changes.
> >>>
> >>> Additionally, we would want to allow different session timeouts for
> >>> offline access.
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> 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
> 
> 