actually we likely won't support the cookie on the adapter side in the
end. However you can achieve the same/similar effect by enable "remember
me" for your realm in Keycloak admin console and increase the realm
timeouts accordingly ("max session timeout" and "idle timeout" ). In
this case, the keycloak server cookies are persistent and you will be
logged automatically when you open your application next time from your
On 21/08/15 14:17, Mike Cirioli wrote:
I think this sounds like an excellent idea - my team has been getting
requests to saml enable mobile applications, and particularly in the
case of internal applications that we require OTP auth for, this
sounds like it would enable us to secure those apps with relatively
little pain for the user (OTP auth on your mobile device is a bit of a
PITA). Requiring the user to only go through that process once and
then having the app save the offline token to be used for subsequent
access would be perfect.
Is this use case something that makes sense in this context?
On 8/21/15 8:09 AM, Marek Posolda wrote:
> On 21/08/15 13:30, Marek Posolda wrote:
>> Some thoughts around offline tokens impl:
>> - Client has switch "Allow offline tokens" . Offline token can be
>> requested just if the switch is enabled
>> - Offline token can be requested if parameter "scope=offline" is sent.
>> Offline token is sent alone, no IDToken or refreshToken is sent
>> with it.
>> Question: Should be offline tokens available just for
>> ResourceOwnerPasswordCredentials and ServiceAccounts or also for
>> web based authorization code flow?
>> - There are methods on UserModel to track which offline tokens were
>> issued for particular user. Like:
>> List<String> getOfflineTokens();
>> void addOfflineToken(String offlineToken);
>> void removeOfflineToken(String offlineToken);
>> - Offline token will never expire. Or should we eventually add another
>> timeout for offline token (With some big default value like 1 month
>> or so)?
>> - Offline token is not refreshable.
>> - Offline token can be validated by current OIDC endpoint for token
>> validation. Offline token is not valid if UserModel doesn't have token
>> anymore on it. But offline token is still valid even if corresponding
>> UserSession doesn't exist. So we can still have offline tokens valid
>> 1 year even if SsoSessionMaxLifespan is just 10 hours.
>> - Offline token can be logged out. Logout will remove offline token
>> corresponding UserModel.
>> - In Account management applications page can user see list of offline
>> tokens issued for individual clients and he can revoke them. Not
>> sure if
>> put another "Revoke offline token" or use current "Revoke
>> which will revoke both consents and offline tokens?
>> - Admin can see the offline tokens for user in admin console and can
>> revoke them too . Current button "Logout All" in sessions tab will
>> revoke offline tokens from all users . For performance reasons, we may
>> need method on UserProvider, so it's possible to clean whole DB table
>> "OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all
>> - For adapters, we should likely have an option, so the REST endpoint
>> adapter has possibility to validate offline token by always sending
>> validation request to KC server. We didn't need it for access tokens,
>> which are valid just for 1 minute or so, but offline tokens are long
>> lived so adapter should have this possibility IMO.
> - Actually, for the frontend adapters (both server and keycloak.js ) I
> am thinking about adding the persistent cookie, which will be put on the
> application after successful login and is valid for the same time like
> the offline token (so couple of months). When browser is opened next
> time, the adapter will find the cookie and send the validation request
> to KC to check if offline token is still valid. This will allow the
> browser application to be logged with the same offline token for couple
> of months.
> I also wonder if we should put the IP address checking when validating
> offline token (Offline token is valid just if validation request come
> from same address like the original request) ?
>> keycloak-dev mailing list
> keycloak-dev mailing list