On 21 September 2015 at 12:06, Marek Posolda <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?