Re: [keycloak-dev] Offline tokens - step 1

What you've listed there doesn't sound correct to me. Each client that requires consent (consentRequired=true) has to prompt the user for all roles including realm roles. So each client requiring consent would need to ask user for consent.

How I think it would work is: * Add a 'offline_access' realm role - in the future we can move this to a OpenID Connect specific namespace * If a client has 'full access' on the scope tab it can obtain an offline token - no need for a separate offline enable toggle for this * The user has a role mapping for this (should be added by default as you said) A client that doesn't require consent (consentRequired=false) will automatically be provided with an offline token as long as the client either has full access or a scope on the realm offline_access role. For a client that requires consent the consent screen will first be shown, including all requested roles/scopes which includes the realm level 'offline_access' role. One given the consent is saved for that specific client. When another client that requires consent asks for offline token the consent screen is yet again shown.

On 21 September 2015 at 14:06, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 21/09/15 12:33, Stian Thorgersen wrote: > > > On 21 September 2015 at 12:06, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> 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. > > - 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? > > > Wording is "MUST explicitly receive or have consent" - as the > client does not require consent (isConsentRequired=false) that > implies the client already has been given consent by the admin. > > > - 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. > > > Spec says scope should be "offline_access", so if we use a > different name for it won't comply with the spec. > > Shouldn't the offline_access role be a realm role rather than a > role per-client? The issue with realm role is, that user needs to confirm offline_access consent just once per all clients, which doesn't look correct to me. For example there would be 2 clients "foo" and "bar": - User john wants offline_access for client "foo" - Consent screen is displayed with "offline_access" role and he confirms it - Then user john wants offline_access for client "bar" - There is no "offline_access" anymore on consent screen because john already has consent for realm role "offline_access" . IMO it should be "offline_access" displayed again as it's different client. Also logically offline_access is granted per client, so the text on the grant screen is: "has Offline Access in foo" or "has Offline Access in bar" which will be with client roles. > > Another thing to consider is that we'll be moving to role > namespaces instead of realm/client roles soon. In that case we > might want a OpenID Connect namespace that can hold these scopes. > So role could be "openid/offline_access". Ok. Maybe for now I won't do anything tricky but just limit the scope param support to client roles of current client. So scope "offline_access" is "offline_access" role of current client. We can improve it later once we add role namespaces support. WDYT? Marek > > > WDYT? Any better idea? > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >