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(a)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(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Stian Thorgersen
Sent: Dienstag, 3. April 2018 11:20
To: Bill Burke <bburke(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] offline access tokens part 2
On 28 March 2018 at 16:24, Bill Burke <bburke(a)redhat.com> wrote:
On Wed, Mar 28, 2018 at 12:58 AM, Stian Thorgersen
<sthorger(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev