3:52 p.m.
My application is checking the access token timeout and refreshing it if expired. The
thing is, the tokens are being invalidated after the SSO session timeout. So if I have
the access token timeout set to 4 hours, and the SSO timeout set to 15 minutes, the access
token and refresh tokens are both invalidated after only 15 minutes.
Date: Thu, 21 Aug 2014 17:34:16 -0400
From: Bill Burke <bburke@redhat.com<mailto:bburke@redhat.com>>
Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
Grants
To: keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
Message-ID: <53F665D8.9000303@redhat.com<mailto:53F665D8.9000303@redhat.com>>
Content-Type: text/plain; charset=windows-1252; format=flowed
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.
2:34 p.m.
New subject: SSO Session Idle Timeout for Direct
----- Original Message -----
From: "John DODGE CONSULTING SERVICES Schneider, LLC"
<John.Schneider(a)carrier.utc.com>
To: keycloak-user(a)lists.jboss.org
Sent: Friday, 22 August, 2014 3:52:47 PM
Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
My application is checking the access token timeout and refreshing it if
expired. The thing is, the tokens are being invalidated after the SSO
session timeout. So if I have the access token timeout set to 4 hours, and
the SSO timeout set to 15 minutes, the access token and refresh tokens are
both invalidated after only 15 minutes.
It doesn't really make much sense to have idle timeout shorter than access token
timeout. For example in your case above the user session is logged out after 15 min, but
an application can still access services using the token for nearly another 4 hours.
Date: Thu, 21 Aug 2014 17:34:16 -0400
From: Bill Burke < bburke(a)redhat.com >
Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
Grants
To: keycloak-user(a)lists.jboss.org
Message-ID: < 53F665D8.9000303(a)redhat.com >
Content-Type: text/plain; charset=windows-1252; format=flowed
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.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3:27 p.m.
New subject: SSO Session Idle Timeout for Direct
Hi Stian,
It does make sense when you have two distinct sets of "users", one of which does
not include people. In our case, we have people at a keyboard that we want to timeout
after about 15 minutes of inactivity, and we also have external applications running in
the background that have no need for a user session per-se and execute many REST service
invocations for the same service over several hours. The applications are active the
whole time, but not interacting with the OAuth server.
If you want to keep things this way, I don't think it's a good idea, but please
at least put in a validation in the admin UI with a warning of "access token timeout
should not be less than SSO session idle timeout".
Thanks,
John
-----Original Message-----
From: Stian Thorgersen [mailto:stian@redhat.com]
Sent: Tuesday, August 26, 2014 8:35 AM
To: Schneider, John DODGE CONSULTING SERVICES, LLC
Cc: keycloak-user(a)lists.jboss.org
Subject: [External] Re: [keycloak-user] SSO Session Idle Timeout for Direct
----- Original Message -----
From: "John DODGE CONSULTING SERVICES Schneider, LLC"
<John.Schneider(a)carrier.utc.com>
To: keycloak-user(a)lists.jboss.org
Sent: Friday, 22 August, 2014 3:52:47 PM
Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
My application is checking the access token timeout and refreshing it
if expired. The thing is, the tokens are being invalidated after the
SSO session timeout. So if I have the access token timeout set to 4
hours, and the SSO timeout set to 15 minutes, the access token and
refresh tokens are both invalidated after only 15 minutes.
It doesn't really make much sense to have idle timeout shorter than access token
timeout. For example in your case above the user session is logged out after 15 min, but
an application can still access services using the token for nearly another 4 hours.
Date: Thu, 21 Aug 2014 17:34:16 -0400
From: Bill Burke < bburke(a)redhat.com >
Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
Grants
To: keycloak-user(a)lists.jboss.org
Message-ID: < 53F665D8.9000303(a)redhat.com >
Content-Type: text/plain; charset=windows-1252; format=flowed
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.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
4:14 p.m.
New subject: SSO Session Idle Timeout for Direct
It's recommended to keep access token timeout low (minutes rather than hours).
However, I agree in your case for the background apps there's no need for the SSO idle
timeout. Adding an option to disable SSO idle timeout for direct access makes sense, not
sure if that should be realm wide or app specific though.
----- Original Message -----
From: "John DODGE CONSULTING SERVICES Schneider, LLC"
<John.Schneider(a)carrier.utc.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-user(a)lists.jboss.org
Sent: Tuesday, 26 August, 2014 3:27:54 PM
Subject: RE: Re: [keycloak-user] SSO Session Idle Timeout for Direct
Hi Stian,
It does make sense when you have two distinct sets of "users", one of which
does not include people. In our case, we have people at a keyboard that we
want to timeout after about 15 minutes of inactivity, and we also have
external applications running in the background that have no need for a user
session per-se and execute many REST service invocations for the same
service over several hours. The applications are active the whole time, but
not interacting with the OAuth server.
If you want to keep things this way, I don't think it's a good idea, but
please at least put in a validation in the admin UI with a warning of
"access token timeout should not be less than SSO session idle timeout".
Thanks,
John
-----Original Message-----
From: Stian Thorgersen [mailto:stian@redhat.com]
Sent: Tuesday, August 26, 2014 8:35 AM
To: Schneider, John DODGE CONSULTING SERVICES, LLC
Cc: keycloak-user(a)lists.jboss.org
Subject: [External] Re: [keycloak-user] SSO Session Idle Timeout for Direct
----- Original Message -----
> From: "John DODGE CONSULTING SERVICES Schneider, LLC"
> <John.Schneider(a)carrier.utc.com>
> To: keycloak-user(a)lists.jboss.org
> Sent: Friday, 22 August, 2014 3:52:47 PM
> Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
>
>
>
> My application is checking the access token timeout and refreshing it
> if expired. The thing is, the tokens are being invalidated after the
> SSO session timeout. So if I have the access token timeout set to 4
> hours, and the SSO timeout set to 15 minutes, the access token and
> refresh tokens are both invalidated after only 15 minutes.
It doesn't really make much sense to have idle timeout shorter than access
token timeout. For example in your case above the user session is logged out
after 15 min, but an application can still access services using the token
for nearly another 4 hours.
>
>
>
>
>
> Date: Thu, 21 Aug 2014 17:34:16 -0400
>
> From: Bill Burke < bburke(a)redhat.com >
>
> Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
>
> Grants
>
> To: keycloak-user(a)lists.jboss.org
>
> Message-ID: < 53F665D8.9000303(a)redhat.com >
>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
>
> 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.
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
4:49 p.m.
New subject: SSO Session Idle Timeout for Direct
For my uses cases, a realm-wide setting would be great. A client-specific setting would
be OK too. But with respect to an application-specific setting, we're actually not
registering any applications in Keycloak as we're securing a mix of services on
platforms not supported by Keycloak. We're writing libraries on these platforms to
validate access tokens using the new "validate" Keycloak endpoint.
-----Original Message-----
From: Stian Thorgersen [mailto:stian@redhat.com]
Sent: Tuesday, August 26, 2014 10:14 AM
To: Schneider, John DODGE CONSULTING SERVICES, LLC
Cc: keycloak-user(a)lists.jboss.org
Subject: [External] Re: [keycloak-user] SSO Session Idle Timeout for Direct
It's recommended to keep access token timeout low (minutes rather than hours).
However, I agree in your case for the background apps there's no need for the SSO idle
timeout. Adding an option to disable SSO idle timeout for direct access makes sense, not
sure if that should be realm wide or app specific though.
----- Original Message -----
From: "John DODGE CONSULTING SERVICES Schneider, LLC"
<John.Schneider(a)carrier.utc.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-user(a)lists.jboss.org
Sent: Tuesday, 26 August, 2014 3:27:54 PM
Subject: RE: Re: [keycloak-user] SSO Session Idle Timeout for Direct
Hi Stian,
It does make sense when you have two distinct sets of "users", one of
which does not include people. In our case, we have people at a
keyboard that we want to timeout after about 15 minutes of inactivity,
and we also have external applications running in the background that
have no need for a user session per-se and execute many REST service
invocations for the same service over several hours. The applications
are active the whole time, but not interacting with the OAuth server.
If you want to keep things this way, I don't think it's a good idea,
but please at least put in a validation in the admin UI with a warning
of "access token timeout should not be less than SSO session idle timeout".
Thanks,
John
-----Original Message-----
From: Stian Thorgersen [mailto:stian@redhat.com]
Sent: Tuesday, August 26, 2014 8:35 AM
To: Schneider, John DODGE CONSULTING SERVICES, LLC
Cc: keycloak-user(a)lists.jboss.org
Subject: [External] Re: [keycloak-user] SSO Session Idle Timeout for
Direct
----- Original Message -----
> From: "John DODGE CONSULTING SERVICES Schneider, LLC"
> <John.Schneider(a)carrier.utc.com>
> To: keycloak-user(a)lists.jboss.org
> Sent: Friday, 22 August, 2014 3:52:47 PM
> Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
>
>
>
> My application is checking the access token timeout and refreshing
> it if expired. The thing is, the tokens are being invalidated after
> the SSO session timeout. So if I have the access token timeout set
> to 4 hours, and the SSO timeout set to 15 minutes, the access token
> and refresh tokens are both invalidated after only 15 minutes.
It doesn't really make much sense to have idle timeout shorter than
access token timeout. For example in your case above the user session
is logged out after 15 min, but an application can still access
services using the token for nearly another 4 hours.
>
>
>
>
>
> Date: Thu, 21 Aug 2014 17:34:16 -0400
>
> From: Bill Burke < bburke(a)redhat.com >
>
> Subject: Re: [keycloak-user] SSO Session Idle Timeout for Direct
>
> Grants
>
> To: keycloak-user(a)lists.jboss.org
>
> Message-ID: < 53F665D8.9000303(a)redhat.com >
>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
>
> 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.
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
3536
days inactive
3540
days old
4 comments
2 participants
participants (2)
-
Schneider, John DODGE CONSULTING SERVICES, LLC -
Stian Thorgersen