On 14/03/18 15:21, Bill Burke wrote:
On Wed, Mar 14, 2018 at 8:51 AM, Stian Thorgersen
<sthorger(a)redhat.com> wrote:
> An offline token would just be an access token with a long expiration time
> right?
>
> Isn't that a bit tricky from a security perspective and also from the fact
> that you can't really invalidate the token? So all services would need to
> check the token with the token introspection endpoint.
>
> Could we fill the same use-case with some sort of reference token instead? A
> short UUID that can be exchanged for a token using the token exchange
> service perhaps?
>
What you're saying is current offline access + new reference token
would be functionally equivalent? I don't think so. With
kub/openshift/social providers, you issue and revoke specific
persistent access tokens through an admin UI/CLI, user service UI/CLI,
or REST interface. Clients that obtain these tokens just use them to
invoke and don't have to refresh them. Services that receive these as
bearer tokens, though, are required to invoke on a validation endpoint
as they are usually opaque.
If we're fine with the limitation, that service always needs to call
validation/introspection endpoint with the persistent token, then we can
achieve it quite easily. We can have protocolMapper, which will change
the expiration of accessToken to 30 days or so (same time like current
Offline Idle Timeout). We can ensure that this protocolMapper is used
just when requested with some special value of scope parameter like for
example: "scope=offline_access persistent_access" .
User is able to revoke this token in account management, that's already
possible. The refresh won't be there, so user will need to
re-authenticate every 30 days, but hopefully that's ok? AFAIK Facebook
tokens are also not "infinite", but have some long lifespan like 1 month
or so.
Marek