[keycloak-dev] Session duration for clients

[Stian Thorgersen]

Added a JIRA here https://issues.jboss.org/browse/KEYCLOAK-12103 trying to
capture the idea in more detail.

On Mon, 18 Nov 2019 at 13:27, Stian Thorgersen <sthorger at redhat.com> wrote:

> Client session max and idle would not affect how sessions are removed from
> memory. The session in the memory is the SSO session, not the session for
> individual clients.
>
> Client session max and idle in regards to OIDC only control the expiration
> time of the tokens. Refresh tokens and access tokens are only valid up to
> client session idle. Further, the refresh token can only be refreshed up to
> client session max. The latter just means we'd need to add an additional
> claim to the refresh tokens (which should be opaque to tokens anyways).
> Once the refresh token is expired the client would have to obtain new
> tokens, which as long as the SSO session is still valid it can do without
> user having to enter credentials.
>
> For SAML there is no refresh token as such the Client Session Idle would
> not be applicable. Instead the SAML assertion would be valid for Client
> Session Max, and the SAML client would fetch a new assertion which again it
> could do without user entering credentials as long as the SSO session is
> still valid.
>
> On Fri, 15 Nov 2019 at 15:43, Ricardo Martin Camarero <rmartinc at redhat.com>
> wrote:
>
>> Hi,
>>
>> Stian, note that changing the SSO max time and SSO idle time also
>> affects in how the sessions are removed from memory. If the max and/or
>> idle is changed per client, the current removeSessions [1] should be
>> modified to consider the timeouts per client (now only realm is taken
>> into account). Those timeouts do not only affect token generation.
>>
>> Regards!
>>
>>
>> [1]
>>
>> https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java#L489
>>
>>
>> On 11/12/19 4:24 AM, 田畑義之 / TABATA，YOSHIYUKI wrote:
>> > Hi,
>> >
>> > I agree with this idea.
>> > This idea will achieve our use case described in the thread [1].
>> > Do you have any plans to implement this?
>> >
>> > [1]
>> https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012530.html
>> >
>> > 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, November 08, 2019 6:09 PM
>> > To: keycloak-dev <keycloak-dev at lists.jboss.org>
>> > Subject: [!][keycloak-dev] Session duration for clients
>> >
>> > Today we have SSO session max and idle, but there is no way to control
>> > duration for individual clients.
>> >
>> > One side-effect of this is that if the SSO session max is very large all
>> > refresh tokens will have a long expiration time.
>> >
>> > It is also related to max_age parameter. As tokens have a long
>> expiration
>> > the only way to control it is the client has to manually check
>> auth_time in
>> > the tokens.
>> >
>> > One idea is that we could introduce a Client Session Max and Idle. The
>> > realm would allow setting a default value, but it would also be
>> possible to
>> > override on a per-client basis. If not set for realm or client it would
>> > fallback to SSO Session Max/Idle
>> >
>> > For Client Session Max implementation should be pretty straight forward.
>> > When issuing tokens we make sure the expiration is set according to the
>> > Clients Session Max.
>> >
>> > For Client Session Idle implementation should also be pretty straight
>> > forward. Tokens would only be valid if within Client Session Idle. As
>> long
>> > as clients refresh tokens they will get newly issued tokens that would
>> be
>> > within the Client Session Idle, up until they reach Client Session Max
>> when
>> > the refresh token would no longer be valid and the client would need to
>> do
>> > a new authentication request to obtain new tokens.
>> >
>> > We should also add default_max_age to clients, which would make it
>> possible
>> > to easily configure re-authentication for specific clients.
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> >
>> https://clicktime.symantec.com/35pw2iShL84hrZog1HQKXcD7Vc?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
>> >
>> --
>>
>> Ricardo Martín Camarero
>>
>> Software Engineer
>>
>> Red Hat <https://www.redhat.com>
>>
>> <https://www.redhat.com>
>>
>>