I don't agree...
Your application should be checking for token timeouts and performing a
refresh. The response from direct-grant gives you a refresh token as
well as an access token as well as a timeout (which you could check from
the access token).
Since you have a refresh token, you can refresh the access token. You
still want the same setup: Short access token lifespan
(seconds/minutes) with a longer refresh timeout minutes/hours. This is
for revocation checks, permission changes, etc.
I could set up a different SSO timeout/access token timeout for grant
requests if you want, but that would have to be after 1.0.final.
On 8/21/2014 1:44 PM, Schneider, John DODGE CONSULTING SERVICES, LLC wrote:
Hi,
I’m finding that access tokens and refresh tokens are being invalidated
after the setting in the “SSO Session Idle Timeout” has elapsed for the
direct-grant API. Considering the direct-grant API enables browser-less
application-to-application security, I’m not convinced that this is the
right approach for many use cases. For reliable authorization and
access token validation, it basically requires setting the “SSO Session
Idle Timeout” to the value of the Access Token timeout, which for many
use cases will be measured in hours or even days.
Is there a good reason that “SSO Session Idle Timeout” should even be
considered for direct-grants?
Thanks,
John
_______________________________________________
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