[keycloak-dev] we do not support offline tokens

Stian Thorgersen sthorger at redhat.com
Tue Mar 20 16:47:03 EDT 2018


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> wrote:

> 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.
>


More information about the keycloak-dev mailing list