[keycloak-dev] Offline tokens - step 1
pslegr
pslegr at redhat.com
Tue Sep 22 08:59:39 EDT 2015
On 22.9.2015 09:16, Stian Thorgersen wrote:
>
>
> On 22 September 2015 at 09:08, Marek Posolda <mposolda at redhat.com
> <mailto: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.
Yes you are correct, this is a SW license related thing.
I must admit that AAA servers normally don't have such things and the
questions is if they really should.
I can't remember seeing out there something offering complex solutions
for online & offline licensing. (I mean unpaid, being opensource)
Once providing an offline "permanent" tokens, this smells more the SW
license way and that was the reasoning behind my questions ;)
I don't say this is a use-case for Keycloak directly, but you do have
already lot's of code there, which can be reused or bent to work for SW
licenses as well :)
cheers
Pavel
>
> >>
> >> 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
> <mailto:keycloak-dev at lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto: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/e8e91259/attachment-0001.html
More information about the keycloak-dev
mailing list