[keycloak-dev] Override Refresh token lifespan per client

Tue Oct 1 10:11:27 EDT 2019

I'm not sure if the scope is suitable to address the use case you
are referring to. Instead, I think we could consider using resource
indicators [1] so that policies that rule the token response (or even the
authorization response) are based on the resource you are trying to access.
Scopes will continue providing coarse-grained access control, only.

By "high|low-risk-api", it seems you are actually indicating the API you
want to access and not really the scope of access.

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-08

On Mon, Sep 30, 2019 at 5:46 AM 田畑義之 / TABATA，YOSHIYUKI <
yoshiyuki.tabata.jy at hitachi.com> wrote:

> Instead of "Override Refresh token lifespan per client", I think that the
> proposed idea tells
>
>  * Determine Refresh token lifespan per API (type).
>  * Which API (type) the RP can access can be conveyed as client scope
> value.
>
>
> The simulated use case is as follows.
>
> 1. The refresh token's timeout value can be configurable by client scope
> value.
>  e.g.
>   scope = "high-risk-api" -> timeout =  1 day
>   scope = "low-risk-api"  -> timeout = 30 day
>
> 2. When the refresh token expires due to its timeout value, its refresh
> token is no longer effective.
>  e.g.
>   The RP had two refresh tokens, one got by scope = "high-risk-api", the
> other got by scope = "low-risk-api". Both of them have different timeout
> value each other.
>   After the "high-risk-api" refresh token is expired, if the RP sends
> "high-risk-api" refresh token to keycloak in order to its token refresh,
> keycloak rejects this token refresh request. The RP can prompt the user to
> re-authenticate and re-consent on keycloak.
>   If the RP sends "low-risk-api" refresh token to keycloak in order to its
> token refresh, keycloak returns the refreshed tokens.
>
> Is my understanding correct?
>
>
> Regards,
> Yoshiyuki Tabata
> Hitachi, Ltd.
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> Sent: Friday, September 27, 2019 7:47 PM
> To: Martin Maher <gentoo at penguindreams.us>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: [!]Re: [keycloak-dev] Override Refresh token lifespan per client
>
> Thanks for your comments and yes they make sense. I think we mostly have
> the same opinion here.
>
> What is achievable with Keycloak today puts a fair bit of the effort on
> the application and the RP. Firstly the RP/API would need to be able to
> find out how long since the user authenticated, which it can as that can be
> added as a claim to the token. The RP can then reject request if it's to
> long since the user authenticated. Further, the application (web/UI) would
> need to use max_age and/or prompt=login to force the user to
> re-authenticate.
>
> Taking this one step further to step-up authentication which we plan to
> introduce in the not to distant future. In this case the application can
> use acr_values to request step-up. This also needs to most likely be
> validated by the RP, which somehow needs to communicate this to the
> applications.
>
> Ideally Keycloak would have some support to make this easier and not have
> to put all the burden on the app and the RP, but AFAIK there's no real
> standard way of doing that. One idea is that we could somehow drive it
> through client scopes. Let's say you have a client scope named
> "high-risk-scope". Setting a max_age and also an acr value on the client
> scope itself within Keycloak means that everytime an application requests a
> token with that scope the refresh token timeout would be set accordingly
> and the user would be required to authenticate at the appropriate level.
>
> In summary though - this is something that needs to be thought through
> properly. Right now I have too many things on my plate to start working on
> any sort of design proposal around this, but if anyone from the community
> would like to start working on something that would be great.
>
>
> On Wed, 25 Sep 2019 at 23:17, Martin Maher <gentoo at penguindreams.us>
> wrote:
>
> > 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 at redhat.com>
> 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 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://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 at 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 at lists.jboss.org
> > https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2
> > F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
> >
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/3PBjaUjoxa2TFK4xePvfAJe7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev