Re: [keycloak-dev] Override Refresh token lifespan per client

On Sep 24, 2019, at 23:55 , Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: I don't understand what's different with your use-case compared to what I listed. As I understand it they are both pretty much the same use-case. In either case different sessions and timeouts are not the correct solution. Configurable refresh token timeout is probably not a good solution either, at least not on its own without anything else. On Wed, 25 Sep 2019 at 03:05, 田畑義之 / TABATA，YOSHIYUKI < yoshiyuki.tabata.jy(a)hitachi.com&gt; wrote: >> So trying to understand your use-case and simplifying things a bit. You > basically have two (or more) different groups of APIs. Let's call these > low-risk APIs and high-risk APIs. When a user invokes the low-risk API they > don't need to authenticate regularly and a session can last for days (or > weeks). For high-risk APIs they need to authenticate more regularly. > > > > This example is a little bit unfitted for our use case. > > I give a concrete example. > > > > For example, there are 2 client applications. > > Client application A accesses high-risk APIs such as money transfer API. > > Client application B accesses low-risk APIs such as balance inquiry API. > > > > In client application A case, it's risky for an end-user to let the client > application to hold a valid refresh token long time because a risk > increases which an attacker sends money using the stolen mobile devices or > which an attacker steals the valid refresh token. Therefore end-user wants > to re-authenticate periodically and the client application guarantees to > end-user that it holds a valid refresh token only limited short time. > > > > In client application B case, it's not risky for an end-user to let the > client application to hold a valid refresh token long time because it is > not much impact for end-user that an attacker checks end user's balance. > Therefore end-user does not want to re-authenticate periodically and the > client application holds a valid refresh token long time prioritizing > usability. > > > > In the above use case, end-user does not trust client applications > completely, so it's meaningless that client application defines the > expiration of a refresh token. And it's meaningful that authorization > server (Keycloak) defines the expiration of a refresh token. > > > > Regards, > > Yoshiyuki Tabata > > Hitachi, Ltd. > > > > *From:* Stian Thorgersen <sthorger(a)redhat.com&gt; > *Sent:* Tuesday, September 24, 2019 4:45 PM > *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com&gt; > *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; > *Subject:* [!]Re: Re: [keycloak-dev] Override Refresh token lifespan per > client > > > > So trying to understand your use-case and simplifying things a bit. You > basically have two (or more) different groups of APIs. Let's call these > low-risk APIs and high-risk APIs. When a user invokes the low-risk API they > don't need to authenticate regularly and a session can last for days (or > weeks). For high-risk APIs they need to authenticate more regularly. > > > > Now this is solved with looking at when the user last authenticated as > well as how the user was authenticated, not by having different session > timeouts. As we don't have step-up autentication support right now, that > leaves us with requiring users to re-authenticate more regularly for the > high-risk API. > > > > Conceptually I can see at least two different ways to achieve the above: > > > > 1) Resource Server is responsible for verifying - the UI uses login=promt > and/or max_age to re-authenticate the user when needed. Further, the > resource server needs to check when user authenticate. > > 2) Keycloak is responsible for verifying - perhaps Keycloak issues refresh > tokens with shorter duration for specific apps/UIs > > > > Option 2 is problematic as the UI may just as well invoke both low-risk > and high-risk APIs. Further, in the future as we add step-up, high-risk may > be asking for step-up authentication, not re-authentication. > > > > On Tue, 24 Sep 2019 at 07:46, TABATA，YOSHIYUKI < > yoshiyuki.tabata.jy(a)hitachi.com&gt; wrote: > >> 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. > > > > Keycloak is a SSO solution and we have no plans on introducing per-client > sessions. > > > > > > > > Regards, > > Yoshiyuki Tabata > > Hitachi, Ltd. > > > > *From:* Stian Thorgersen <sthorger(a)redhat.com&gt; > *Sent:* Friday, September 20, 2019 6:00 PM > *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy(a)hitachi.com&gt; > *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; > *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(a)hitachi.com&gt; 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.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2F%2... > > PR is the following. > https://github.com/keycloak/keycloak/pull/6309 > <https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2F%2... > > Regards, > Yoshiyuki Tabata > Hitachi, Ltd. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2F%2... > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev