3:59 a.m.
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(a)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
PR is the following.
https://github.com/keycloak/keycloak/pull/6309
Regards,
Yoshiyuki Tabata
Hitachi, Ltd.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev