I always thought an offline token is a long-living refresh token...
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 Bill Burke
Sent: Mittwoch, 14. März 2018 15:21
To: Stian Thorgersen <stian(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] we do not support offline tokens
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.
--
Bill Burke
Red Hat
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev