[keycloak-dev] offline access tokens part 2

[Stian Thorgersen]

On 28 March 2018 at 16:24, Bill Burke <bburke at redhat.com> wrote:

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

It would definitively make sense to add an offline access token timeout. I
still think it would be useful to be able to override expirations for
specific clients.


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

Yes, this all makes sense to me. So to summary to make sure we are on the
same page:

1. Add offline access token timeout that allows setting different
expiration for tokens for an offline session
2. Add support for an option on realm with override on clients to issue
JWTs or opaque tokens JWE. The latter requiring calling the token
introspection endpoint rather than simply inspecting the token directly

A few extensions we could consider:

3. Add ability to override token expiration for specific clients
4. A support for a reference tokens where the token is a short UUID and not
a long JWE. I believe when folks refer to reference tokens this is what
they refer to. This would probably require storing the token details in the
session or something




>
> --
> Bill Burke
> Red Hat
>