On 08/21/2015 01:30 PM, Marek Posolda wrote:
- Offline token can be requested if parameter
"scope=offline" is sent.
Offline token is sent alone, no IDToken or refreshToken is sent together
Question: Should be offline tokens available just for
ResourceOwnerPasswordCredentials and ServiceAccounts or also for classic
web based authorization code flow?
Not quite sure what ResourceOwnerPasswordCredentials is (is it something
new?), but I think that having the possibility of requesting an offline
token based on a bearer token is desirable. In my case, I intend to have
a "token exchange proxy", where the end user would create API keys for
the agent. This API key is an UUID, that relates to a token that I'd
store in Hawkular's backend. Whenever I get this token, I retrieve the
offline token and use it for backend operations, as if the user were online.
This means: I don't intend to have access to the user's password at any
point when creating or sending offline tokens.
- Offline token will never expire. Or should we eventually add
timeout for offline token (With some big default value like 1 month or so)?
It should never expire. Or at most, there should be a setting for the
realm/client that would allow the offline token to never expire. It can,
however, be revoked.
- 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 for
1 year even if SsoSessionMaxLifespan is just 10 hours.
- Offline token can be logged out. Logout will remove offline token
I guess this is the revoked part I mentioned above, right?
- In Account management applications page can user see list of
tokens issued for individual clients and he can revoke them. Not sure if
put another "Revoke offline token" or use current "Revoke grant"
which will revoke both consents and offline tokens?
Not sure what would be the difference there. The consent is linked to
the client, while the offline token would be a session, right? If so,
I'd revoke only the token itself.
- 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
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.