[keycloak-dev] Override Refresh token lifespan per client

Wed Sep 25 02:55:20 EDT 2019

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 at hitachi.com> 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 at redhat.com>
> *Sent:* Tuesday, September 24, 2019 4:45 PM
> *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy at hitachi.com>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *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 at hitachi.com> 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 at redhat.com>
> *Sent:* Friday, September 20, 2019 6:00 PM
> *To:* TABATA，YOSHIYUKI <yoshiyuki.tabata.jy at hitachi.com>
> *Cc:* keycloak-dev <keycloak-dev at 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 at 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.symantec.com/3XksWm4odSS8VwXNrH1nE8Q7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-10907>
>
> PR is the following.
> https://github.com/keycloak/keycloak/pull/6309
> <https://clicktime.symantec.com/3KpbzQn7GfmuzEjrULq3CKg7Vc?u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F6309>
>
> Regards,
> Yoshiyuki Tabata
> Hitachi, Ltd.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://clicktime.symantec.com/36KFRJRZcwj1bDfny5pnUeA7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev>
>
>