[keycloak-dev] we do not support offline tokens

[Schuster Sebastian (INST/ESY1)]

Gives bearer (limited) access...does not expire...sounds like an API Key to me. It is simpler but you also lose some of the benefits: it needs to be resolved, the resource server might have to cache resolution information for efficiency reasons.
So this is just another tradeoff one can make... 

Btw. are there any plans to also support reference tokens (expiring or non-expiring)? They do have some advantages when it comes to security/privacy...

Best regards,
Sebastian

P.S.: Is handling token lifetimes or refresh tokens really such an issue? Any decent OAuth2 library should be able to handle this properly...  

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: Bill Burke [mailto:bburke at redhat.com] 
Sent: Donnerstag, 15. März 2018 03:13
To: Stian Thorgersen <stian at redhat.com>
Cc: Pedro Igor Silva <psilva at redhat.com>; Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] we do not support offline tokens

On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I think the short tokens issued by the likes of OpenShift is primarily 
> used for authentication, not access. As such it's more a short ID 
> token than an actual access token.
>

This is just not how it works.

Service Account tokens in Openshift/Kubernetes can be used as bearer tokens.  Services that receive these bearer tokens call a validation endpoint (token review).  The validation endpoint returns a JSON document with user info and group membership.  Kubernetes additionally has a Authorization endpoint that can be invoked, but you pass in username, not a token, and the resources you want to access.  BTW, this is how many OAuth implementations work.  Access tokens are just opaque strings that must be validated and the only way to get information about the user is by invoking on a user info service.

The keycloak/openshift integration requires keycloak to invoke on the OpenShift API server.  The provider is configured with an Openshift service account token.  The configured token is used as a bearer token.  THERE IS NO REFRESH...EVER.  Makes things really simple for the client.  There are a lot of Keycloak users that jack up access token timeouts because they want permanent tokens.  Managing token timeouts and refreshes is a pain in the ass.

FYI, I'm not just pulling this out of my ass... :) Simo seems to think that this is a blocker for GA for keycloak/openshift integration.


> I could see us doing something similar with allowing users to generate 
> these short tokens that can be used to authenticate and obtain 
> refresh/access tokens instead of using username/password.
>

This is just not the same thing, sorry.  Useful, but not the same thing.