[keycloak-dev] offline access tokens part 2

[Bill Burke]

On Wed, Mar 28, 2018 at 12:58 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> Since my reply was ignored I'm going to repeat myself.
>
> I would rather have the option to override the expiration of access tokens
> expiration on a per-client basis. We could allow clients to use the global
> expiration, a client specific expiration or no expiration at all. When a JWT
> has no expiration set the client should always use the token introspection
> endpoint to validate the tokens.
>
> Perhaps also combine that with client scopes to make it possible for a
> client to request one token with longer expiration for a specific use-case.
> For instance if a client needs to invoke some background process that takes
> longer than the regular access token.
>
> I think that approach will be simpler to implement and also cover more
> use-cases.
>
> I don't see the need to have a different scope than what we have today. This
> should be a config option on the client for the current offline scope.
> There's no need to introduce a new non-common scope for this stuff.
>

FYI, didn't ignore you.  I replied to Marek's email first, got
distracted before I could read and reply to yours.

I think this is a reference token vs. non-reference token debate.
Let's first talk about offline access tokens.  In thinking further on
your suggestion, what about instead of per client expiration,
shouldn't we instead have an "offline access token timeout"?  Access
tokens created for  offline access should have this timeout, maybe
default to "offline idle" timeout?  One thing we have to be sure of is
that these offline access tokens are valid across server restarts.

In retrospect, I mixed up offline access and the idea of a reference
token.  I think whether an access token is a reference token or not is
orthogonal to whether it is offline or not.  Reference tokens must
always be validated.  Non-reference tokens can be used as bearer
tokens without validation.  I think we should have a global switch on
what the access token type should be by default, then allow clients to
override.   You should also be able to separately configure whether a
reference token should be used or not for offline and non-offline
access.  In the future we might even want to offer one-time reference
tokens that can only be validated once.  FYI:  all tokens in
Kubernetes and Openshift are reference tokens (and offline).

Reference tokens require validation and shouldn't be excepted ever for
bearer token requests unless validated.  Using expiration time to
determine the token type is not a good solution. Other than just being
a hack, you remove the ability to have any expiration on the token.  I
really prefer that reference tokens be completely opaque to the
client.  A JWE IMO.

-- 
Bill Burke
Red Hat