But that only really makes sense for reference tokens where you need some kind of
reference resolution/introspection anyways because otherwise you miss a mechanism to
revoke access, right?
Having to introspect a JWT every time it is used for access kind of defeats the purpose of
having a self-contained token in the first place...
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: Bill Burke [mailto:bburke@redhat.com]
Sent: Mittwoch, 14. März 2018 17:02
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
Cc: Stian Thorgersen <stian(a)redhat.com>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] we do not support offline tokens
On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com> wrote:
I always thought an offline token is a long-living refresh token...
Best regards,
Sebastian
Yes, that's how OIDC thinks of offline tokens and how we've implemented it. But
facebook, kubernetes, openshift have the concept of a persistent token that can be used in
bearer requests.
Bill