[keycloak-dev] we do not support offline tokens
Bill Burke
bburke at redhat.com
Wed Mar 14 22:12:53 EDT 2018
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