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

Stian: In reading this thread and the OPs concerns, I see three components that could exert or express control - the Keycloak server; the application server; and the user. From reading the OPs concerns, both in the original post and in the later articulation, it seems as though there is a desire to have the user express what is a high-risk API . . . "*Therefore end-user wants to re-authenticate periodically*”, versus your example of the Application server designating itself as a high-risk for all users. I agree with your assertion that solving this issue through HTTP session-timeouts would be problematic, not least of all for SSO type of authentications. Having the application server specify to the Keycloak server the max-length of a valid authorization based upon successful authentication, would permit the Keycloak server to set the “max-age” attribute, whereby refresh tokens would no longer be issued or honored after that time, leading to a requirement to reauthenticate. The tricky bit for the OPs scenario is creating a method within the application server for the user to express this to the application, which could then be conveyed to Keycloak, which could then be set on the user tokens. This does lead back to the application server, as you asserted, but I believe that there would need to be a mechanism, if one does not already exist, for the application server to communicate this to Keycloak on a per-user basis. It should also be possible for the Keycloak server to take a configuration element that permits designation of high-risk and low-risk APIs, in order to interfere with attempts to downgrade authentication strengths for sensitive applications. I hope this makes sense. Regards, Martin 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://clicktime.symantec.com/3T38NcSH1Vc12vciukE8Hxv7Vc?u=https%3A%2 F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907 < https://clicktime.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2 F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907 > PR is the following. https://clicktime.symantec.com/3NZ9Bwcut6QLNg5aMQgjbta7Vc?u=https%3A%2 F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309 < https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2 F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309 > Regards, Yoshiyuki Tabata Hitachi, Ltd. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2 F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev < https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2 F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2 F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev