[keycloak-dev] Offline tokens - step 1

Tue Sep 22 03:16:45 EDT 2015

On 22 September 2015 at 09:08, Marek Posolda <mposolda at redhat.com> wrote:

> On 21/09/15 15:15, pslegr wrote:
> >
> >
> > On 21.9.2015 14:27, Marek Posolda wrote:
> >> On 21/09/15 12:28, pslegr wrote:
> >>>
> >>>
> >>> On 21.9.2015 12:06, Marek Posolda wrote:
> >>>> I've sent the PR . Right now it works like this:
> >>>>
> >>>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
> >>>> retrieve offline tokens just if flag is enabled
> >>>>
> >>>> - Offline token is classic refresh token with 2 differences. It has
> >>>> type
> >>>> "OFFLINE" when normal refresh token has type "REFRESH" . And for
> >>>> offline
> >>>> token, the expiration value is 0, so it never expires.
> >>> Just an idea.
> >>> Have you ever thought, in terms of expiration, not only
> >>> about refresh vs. never expires
> >>> BUT also about defining the exact time of expiration ?
> >>> for example validity for 1 Month, 1 year, 3 years ... etc.
> >>> This would offer the possibility on the fly generate the so called;
> >>> "offline license tokens", which are
> >>> then used for different lifetime periods.
> >>> IMHO this might extend the usage for Keycloak into the license
> >>> providers field ;)
> >> We have already some support for required action "Terms & Condition"
> >> at the keycloak server level. AFAIK user needs to confirm "Terms &
> >> Conditions" page when he has that required action set on him. You
> >> have also possibility to customize the content of the page.
> >>
> >>  I wonder if this required action can be used for time based licences
> >> as well? Like for example you will have possibility to configure that
> >> validity of licence is 1 year, so after 1 year will be required
> >> action added to user automatically and he will need to confirm it
> >> again during login?
> > Well, I had more the offline licensing on my mind. In such situation
> > you would not ever communicate with the server from client.
> >>
> >> The possibility you mentioned is about handling licence agreement at
> >> the client level by the application itself if I understand correctly?
> >> So application will save offline token and the token is valid for 3
> >> years, so application will display the licence screen when it
> >> notifies that offline token is expired. Am I understand correctly?
> > Yes, I think you pretty much got it
> > The thing is, once you imagine the offline license generation, then
> > this is a once time action, at the beginning. The license provider who
> > owns private keys makes that once and provide to the clients.
> > The token is then verified for offline actions and once expired must
> > be replaced by license provide again.
> Interesting usecase. Looks there are more possibilities how to support
> this.
>
> 1) We can add timeout for offline tokens (will be NEVER by default, so
> it will never expire).
> 2) We can add the protocol mappers extension points for refresh tokens
> as well (currently we use protocol mappers just for generation of access
> tokens and ID tokens). This will allow even more flexibility in
> generating refresh/offline tokens and use different timeouts for
> different clients etc.
> 3) Don't do anything directly in Keycloak, but let application handle
> this. When you receive offline token from Keycloak, you will save the
> offline token to your DB together with the time when offline token was
> received (you will handle the time by yourself, not from expiration
> field of offline token). Then your DB contains the time, so you can
> handle it in your application that after 3 years is token not valid
> anymore and the licence needs to be confirmed again.
>

Not sure I fully understand what the use-case is around this, but it seems
like what's being proposed is a complete misuse of offline tokens.

I'm assuming by licensing you mean something along the lines of a software
license where a user has paid for a 1 year license for a particular
application? If so offline tokens are not the solution as something like
that should work with regular tokens as well. There's also a lot of other
things to consider with regards to a license. You need a mechanism to add
the license in the first place (a signed token perhaps associated with the
users account), a way to renew the license (pay mechanism), etc.. It's not
something we've had any demand for, nor do I really think it's something an
authentication server should do.

>
> >>
> >> IMO extend the current Terms & Conditions action for expiration after
> >> some time looks better to me, as you won't need to do any more coding
> >> in your application. Just set the timeout for Terms&Conditions (or
> >> licence ) action at keycloak admin console.
> >
> > Is the "Terms & Conditions action" something which works offline  ?
> No. It's displayed by Keycloak server, so it requires Keycloak server to
> be up and running.
>
> Marek
> >
> > Pavel
> >>
> >> Marek
> >>>>
> >>>> - Offline token is generated by auth-server when client sends
> >>>> "scope=offline_access" . It's supported for classic browser flow, but
> >>>> also for Direct Grant flow or Service account flow.
> >>>>
> >>>> - I've added OfflineClientSessionModel and OfflineUserSessionModel
> >>>> with
> >>>> CRUD methods on UserModel. So when new offline token is generated by
> >>>> Keycloak, some info about current UserSession and ClientSession is
> >>>> persisted on UserModel. This means that offline token can be used to
> >>>> create new access token even if "normal" UserSession and ClientSession
> >>>> are already invalid or logged out.
> >>>>
> >>>> - When refreshing access token with offline token, the auth-server
> >>>> won't
> >>>> send back another refresh token. It will send just accessToken +
> >>>> IDToken. This is to avoid writes to user database for each token
> >>>> refresh.
> >>>>
> >>>> - In account management applications tab, there is new table column
> >>>> "Additional grants" where is shown if client has offline token for
> >>>> user.
> >>>> The click on "Revoke" button will remove offline tokens and granted
> >>>> consents as well - no separate actions for revoke consents and offline
> >>>> tokens.
> >>>>
> >>>>
> >>>> Still TODO:
> >>>> - Properly handle consents (see "Questions" below)
> >>>>
> >>>> - More tests, example, export/import , docs
> >>>>
> >>>> - More things/refactoring based on your feedback
> >>>>
> >>>>
> >>>> Questions:
> >>>> - The specs mentions that consent should be displayed when offline
> >>>> token
> >>>> is requested. See
> >>>> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
> >>>> Right now, I am not doing that. So when Client has "isConsentRequired"
> >>>> as false, the consent screen is not displayed. Now we also don't have
> >>>> support for "prompt=consent" (not sure if we need this) . Is it ok to
> >>>> keep it like this?
> >>>>
> >>>> - I am thinking about adding new builtin client role "offline_access",
> >>>> which will be created for client when admin enables "offline tokens"
> >>>> switch. It will be used also as default role. This will allow that
> >>>> just
> >>>> some users are allowed to obtain offline-token (those which have this
> >>>> role). The role will be also displayed on consent screen for the
> >>>> clients, which needs consent.
> >>>> But that raises another question. IMO it will be good if role is
> >>>> requested and displayed on consent screen just if offline token is
> >>>> requested, but not when classic refresh token is requested.
> >>>>
> >>>> Hence I was thinking about adding the flag "scopeParamMode" to
> >>>> RoleModel. The value true means that role will be requested and
> >>>> used in
> >>>> accessToken/refreshToken just if scope parameter contains it's value.
> >>>> This will be the setup for "offline_access" role, so it's used just
> >>>> for
> >>>> the offline token requests. Another thing is format of scope parameter
> >>>> with respect to realm roles and application roles. We can use "//" as
> >>>> delimiter, so realm role will have just "my-role" but client role will
> >>>> have "my-client//my-role" . The disadvantage is that for requesting
> >>>> offline_access you will then need to use scope like:
> >>>> "scope=customer-portal//offline_access" as it's client role.
> >>>>
> >>>> WDYT? Any better idea?
> >>>>
> >>>> Marek
> >>>> _______________________________________________
> >>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150922/1054909c/attachment-0001.html 