[keycloak-dev] we do not support offline tokens

[Schuster Sebastian (INST/ESY1)]

I think supporting opaque tokens would be really great. Our security guys have concerns with self-contained tokens for some cases that might demand doing token signing in an HSM. Using opaque tokens is an alternative to that…

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<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto: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



From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Dienstag, 20. März 2018 21:47
To: Bill Burke <bburke 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

Sounds like something we should add. Would it not just be a matter of allowing overriding the token expiration for specific clients? Perhaps also we should have the option for clients to obtain actually opaque tokens so they are forced to call the token introspection endpoint (or token review endpoint in OpenShift/Kube case).

On 15 March 2018 at 03:12, Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>> wrote:
On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen <sthorger at redhat.com<mailto: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.