8:21 p.m.
First of all, Keycloak looks great - the alpha release is a very nice start!
I have a question about bearer token expiration. Take the included
product portal example. It is configured to use Keycloak for SSO, which
allows the user to access the product listing page. That listing page
uses the current SkeletonKeySession's token as the Bearer token when
invoking the database/products REST endpoint. This makes sense to me,
but one interesting thing happens - that token eventually times out.
Once that happens all calls to the REST endpoint fail.
Note that this occurs even if the user refreshes that product listing
page. The timeout is from login, not from the last activity (like an
http session timeout would be).
So in this scenario, how is the product page supposed to get a new token
when the old one expires?
This becomes even more relevant if the UI is not a JSP but is instead a
JavaScript app (e.g. angular, GWT, etc). I was thinking that I would
need to pass the token to the client layer, which would then allow me to
make authenticated REST calls directly from the Client/JavaScript layer
to a REST API. That would be a great separation, but obviously the user
should not get logged out after N minutes despite actively using the app
during that time.
I'm probably missing something obvious... :)
-Eric
9:11 p.m.
You're not missing something obvious. We need to add refresh tokens
that can be held by the HTTP session or the Javascript client so a new
access token can be obtained. There's also some work still to be done
to smooth out Javascript only clients that are servered up via static pages.
On 1/28/2014 2:21 PM, Eric Wittmann wrote:
First of all, Keycloak looks great - the alpha release is a very nice
start!
I have a question about bearer token expiration. Take the included
product portal example. It is configured to use Keycloak for SSO, which
allows the user to access the product listing page. That listing page
uses the current SkeletonKeySession's token as the Bearer token when
invoking the database/products REST endpoint. This makes sense to me,
but one interesting thing happens - that token eventually times out.
Once that happens all calls to the REST endpoint fail.
Note that this occurs even if the user refreshes that product listing
page. The timeout is from login, not from the last activity (like an
http session timeout would be).
So in this scenario, how is the product page supposed to get a new token
when the old one expires?
This becomes even more relevant if the UI is not a JSP but is instead a
JavaScript app (e.g. angular, GWT, etc). I was thinking that I would
need to pass the token to the client layer, which would then allow me to
make authenticated REST calls directly from the Client/JavaScript layer
to a REST API. That would be a great separation, but obviously the user
should not get logged out after N minutes despite actively using the app
during that time.
I'm probably missing something obvious... :)
-Eric
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:31 p.m.
Thanks for the response Bill. This is great news (both that it's on the
roadmap and that I'm not[1] an idiot).
Let me know if I can help with testing. There's a new project starting
up in JBoss Overlord that I'm in the process of bootstrapping now. I'm
going to design it with this approach in mind (Javascript client making
REST calls directly to an API that is separate from the webapp that
served up the JS). So I'm happy to be an early adopter/tester.
-Eric
[1] necessarily
On 1/28/2014 3:11 PM, Bill Burke wrote:
You're not missing something obvious. We need to add refresh
tokens
that can be held by the HTTP session or the Javascript client so a new
access token can be obtained. There's also some work still to be done
to smooth out Javascript only clients that are servered up via static pages.
On 1/28/2014 2:21 PM, Eric Wittmann wrote:
> First of all, Keycloak looks great - the alpha release is a very nice start!
>
> I have a question about bearer token expiration. Take the included
> product portal example. It is configured to use Keycloak for SSO, which
> allows the user to access the product listing page. That listing page
> uses the current SkeletonKeySession's token as the Bearer token when
> invoking the database/products REST endpoint. This makes sense to me,
> but one interesting thing happens - that token eventually times out.
> Once that happens all calls to the REST endpoint fail.
>
> Note that this occurs even if the user refreshes that product listing
> page. The timeout is from login, not from the last activity (like an
> http session timeout would be).
>
> So in this scenario, how is the product page supposed to get a new token
> when the old one expires?
>
> This becomes even more relevant if the UI is not a JSP but is instead a
> JavaScript app (e.g. angular, GWT, etc). I was thinking that I would
> need to pass the token to the client layer, which would then allow me to
> make authenticated REST calls directly from the Client/JavaScript layer
> to a REST API. That would be a great separation, but obviously the user
> should not get logged out after N minutes despite actively using the app
> during that time.
>
> I'm probably missing something obvious... :)
>
> -Eric
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
4015
days inactive
4015
days old
2 comments
2 participants
participants (2)
-
Bill Burke -
Eric Wittmann