[keycloak-dev] we do not support offline tokens

Schuster Sebastian (INST/ESY1) Sebastian.Schuster at bosch-si.com
Wed Mar 14 10:55:36 EDT 2018


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 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 Bill Burke
Sent: Mittwoch, 14. März 2018 15:21
To: Stian Thorgersen <stian at redhat.com>
Cc: keycloak-dev <keycloak-dev at 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 at 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 at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev



More information about the keycloak-dev mailing list