12:46 a.m.
For authorization code flow it makes no sense at all to have
different session timeouts as it is by definition a shared SSO session. Different security
levels should be controlled things like step-up and authentication timeout, not by having
different session timeouts. Further, I'm not sure if refresh token timeout should be
configurable per-client here as end of the day a new refresh token can easily be obtained
as long as the session is still active.
Clients guarantee to end-users that clients access to end-users' resources only within
the expiration using the tokens. So end-users need to re-login after the expiration and
clients must not refresh tokens after the expiration.
The expiration depends on each client by security reason, or usability reason, or so on.
Therefore regardless of which authorization flows we use, we need to make a difference
between session timeouts.
I'm not particularly found of introducing so many settings on a
client. It's difficult to setup and error prone. So this use-case needs to be
described properly and we need to find a decent solution to it. Simply adding all these
settings on a client may work for you, but I doubt others would understand how and when to
use them, and I think it can easily end up resulting in a lot of error cases.
How about providing a checkbox which enables a one-to-one relationship between
UserSessionModel and ClientSessionModel?
Currently, UserSessionModel and ClientSessionModel are a one-to-many relationship, and
this makes it difficult to set session timeout per client.
If the checkbox enabled, not link a new ClientSessionModel to the existing
UserSessionModel when a new client which uses the existing authentication result appeared
but make a new UserSessionModel.
If this possible, we don't need to change the way to manage sessions.
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
From: Stian Thorgersen <sthorger(a)redhat.com>
Sent: Friday, September 20, 2019 6:00 PM
To: TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Override Refresh token lifespan per client
I'm still not quite following what you are trying to achieve.
For authorization code flow it makes no sense at all to have different session timeouts as
it is by definition a shared SSO session. Different security levels should be controlled
things like step-up and authentication timeout, not by having different session timeouts.
Further, I'm not sure if refresh token timeout should be configurable per-client here
as end of the day a new refresh token can easily be obtained as long as the session is
still active.
For client credentials grant where the server obtains tokens this may make sense.
I'm not particularly found of introducing so many settings on a client. It's
difficult to setup and error prone. So this use-case needs to be described properly and we
need to find a decent solution to it. Simply adding all these settings on a client may
work for you, but I doubt others would understand how and when to use them, and I think it
can easily end up resulting in a lot of error cases.
On Fri, 20 Sep 2019 at 08:40, TABATA，YOSHIYUKI
<yoshiyuki.tabata.jy@hitachi.com<mailto:yoshiyuki.tabata.jy@hitachi.com>>
wrote:
Hello,
In cloud-native application systems, there are various client applications and those
applications are not the same level (i.e. security level, alliance level, development
level). And generally, a realm manager or a resource server manager wants to set a
different timeout to tokens (access token/refresh token) per client. For example, for a
client which wants to minimize authentication considering usability, we set the timeout of
a refresh token longer enough. For a client which wants to refresh tokens periodically to
mitigate the token interception attack, we set the timeout of a refresh token according to
the client requirement.
Currently, the timeout of an access token can be overridden per client. However, the
timeout of a refresh token (including offline token) cannot be overridden per client.
We'd like to be able to override the timeout of a refresh token (including offline
token) per client.
We'd already tried to implement this just like access token lifespan overriding, and
create JIRA ticket and PR, but Stian recommended that we should discuss this use case and
how to implement in ML, so I opened this thread.
For single sign-on purpose, it is useful to share sessions among clients in a realm.
However, when we implement this, sessions are no longer shared among clients depending on
the settings. And this is useful for API management purpose because, for API management
purpose, tokens (= sessions) are associated with each client, and should be managed per
client.
What do you think about this feature? I would be very happy if you community gives any
kind of comment on that.
JIRA ticket is the following.
https://issues.jboss.org/browse/KEYCLOAK-10907<https://clicktime.syman...
PR is the following.
https://github.com/keycloak/keycloak/pull/6309<https://clicktime.syman...
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev<https://clicktim...