5:15 p.m.
Correct me if I'm wrong, but we don't support the concept of an
offline token right? Just an offline refresh token?
Probably something we will have to support as Kubernetes, Openshift,
and many of the social providers have a similar concept of a permanent
persisted access token.
--
Bill Burke
Red Hat
8:51 a.m.
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?
On 13 March 2018 at 22:15, Bill Burke <bburke(a)redhat.com> wrote:
Correct me if I'm wrong, but we don't support the concept of
an
offline token right? Just an offline refresh token?
Probably something we will have to support as Kubernetes, Openshift,
and many of the social providers have a similar concept of a permanent
persisted access token.
--
Bill Burke
Red Hat
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:21 a.m.
On Wed, Mar 14, 2018 at 8:51 AM, Stian Thorgersen <sthorger(a)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
10:55 a.m.
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(a)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(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Bill Burke
Sent: Mittwoch, 14. März 2018 15:21
To: Stian Thorgersen <stian(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:02 p.m.
On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com> wrote:
I always thought an offline token is a long-living refresh token...
Best regards,
Sebastian
Yes, that's how OIDC thinks of offline tokens and how we've
implemented it. But facebook, kubernetes, openshift have the concept
of a persistent token that can be used in bearer requests.
Bill
12:22 p.m.
But that only really makes sense for reference tokens where you need some kind of
reference resolution/introspection anyways because otherwise you miss a mechanism to
revoke access, right?
Having to introspect a JWT every time it is used for access kind of defeats the purpose of
having a self-contained token in the first place...
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(a)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@redhat.com]
Sent: Mittwoch, 14. März 2018 17:02
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
Cc: Stian Thorgersen <stian(a)redhat.com>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] we do not support offline tokens
On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com> wrote:
I always thought an offline token is a long-living refresh token...
Best regards,
Sebastian
Yes, that's how OIDC thinks of offline tokens and how we've implemented it. But
facebook, kubernetes, openshift have the concept of a persistent token that can be used in
bearer requests.
Bill
12:46 p.m.
I think facebook, kube and openshift have different requirements. They can
use persistent tokens because they have complete control over their
lifetime and they are targeted to be used within their environments.
Facebook in particular acts as both AS and resource server.
On Wed, Mar 14, 2018 at 1:02 PM, Bill Burke <bburke(a)redhat.com> wrote:
On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com> wrote:
> I always thought an offline token is a long-living refresh token...
>
> Best regards,
> Sebastian
>
Yes, that's how OIDC thinks of offline tokens and how we've
implemented it. But facebook, kubernetes, openshift have the concept
of a persistent token that can be used in bearer requests.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:07 p.m.
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.
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.
On 14 March 2018 at 17:46, Pedro Igor Silva <psilva(a)redhat.com> wrote:
I think facebook, kube and openshift have different requirements.
They can
use persistent tokens because they have complete control over their
lifetime and they are targeted to be used within their environments.
Facebook in particular acts as both AS and resource server.
On Wed, Mar 14, 2018 at 1:02 PM, Bill Burke <bburke(a)redhat.com> wrote:
> On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1)
> <Sebastian.Schuster(a)bosch-si.com> wrote:
> > I always thought an offline token is a long-living refresh token...
> >
> > Best regards,
> > Sebastian
> >
>
> Yes, that's how OIDC thinks of offline tokens and how we've
> implemented it. But facebook, kubernetes, openshift have the concept
> of a persistent token that can be used in bearer requests.
>
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
10:12 p.m.
On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen <sthorger(a)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.
4:51 a.m.
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(a)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@redhat.com]
Sent: Donnerstag, 15. März 2018 03:13
To: Stian Thorgersen <stian(a)redhat.com>
Cc: Pedro Igor Silva <psilva(a)redhat.com>; Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com>; keycloak-dev
<keycloak-dev(a)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(a)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.
7:03 a.m.
On Fri, Mar 16, 2018 at 4:51 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com> wrote:
P.S.: Is handling token lifetimes or refresh tokens really such an
issue? Any decent OAuth2 library should be able to handle this properly...
IMO, depends on the HTTP client framework too, not just the oauth one.
I like things ridiculously simple though.
--
Bill Burke
Red Hat
4:47 p.m.
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(a)redhat.com> wrote:
On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen
<sthorger(a)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.
3:28 a.m.
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@bosch-si.com<mailto:Sebastian.Schuster@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@redhat.com]
Sent: Dienstag, 20. März 2018 21:47
To: Bill Burke <bburke(a)redhat.com>
Cc: Pedro Igor Silva <psilva(a)redhat.com>; Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com>; keycloak-dev
<keycloak-dev(a)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@redhat.com<mailto:bburke@redhat.com>> wrote:
On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen
<sthorger@redhat.com<mailto:sthorger@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.
3:48 p.m.
On 14/03/18 15:21, Bill Burke wrote:
On Wed, Mar 14, 2018 at 8:51 AM, Stian Thorgersen
<sthorger(a)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.
If we're fine with the limitation, that service always needs to call
validation/introspection endpoint with the persistent token, then we can
achieve it quite easily. We can have protocolMapper, which will change
the expiration of accessToken to 30 days or so (same time like current
Offline Idle Timeout). We can ensure that this protocolMapper is used
just when requested with some special value of scope parameter like for
example: "scope=offline_access persistent_access" .
User is able to revoke this token in account management, that's already
possible. The refresh won't be there, so user will need to
re-authenticate every 30 days, but hopefully that's ok? AFAIK Facebook
tokens are also not "infinite", but have some long lifespan like 1 month
or so.
Marek
2226
days inactive
2234
days old
13 comments
5 participants
participants (5)
-
Bill Burke -
Marek Posolda -
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1) -
Stian Thorgersen