[keycloak-dev] offline access tokens part 2

Tue Apr 3 10:20:58 EDT 2018

I really like 3) because this might be a way of getting around having to do token signing externally in an HSM, depending on company regulations.

Btw. how about allowing to override token lifetimes also based on the involved roles/scopes? Lifetimes are essentially a security/efficiency tradeoff and for critical roles, I would really like to tune that tradeoff towards security.
That would probably be something in the line of creating a token with the minimum lifetime configured by realm/client/role....

Best regards,
Sebastian

Mit freundlichen Grüßen / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn 

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Dienstag, 3. April 2018 11:20
To: Bill Burke <bburke at redhat.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] offline access tokens part 2

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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev