[keycloak-dev] Offline tokens - step 1

[Stian Thorgersen]

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

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".


>
> WDYT? Any better idea?
>
> Marek
> _______________________________________________
> 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/20150921/af62f48d/attachment.html