[keycloak-dev] Remove seconds for token timeouts

[Stian Thorgersen]

I'll buy you a beer in Brno if anyone has a valid reason to require seconds
for token timeouts. I won't take "I can't be bothered waiting for a whole
minute for token to timeout during manual testing" as a valid argument
though.

On 25 January 2016 at 12:18, Marek Posolda <mposolda at redhat.com> wrote:

> On 25/01/16 12:01, Stian Thorgersen wrote:
>
>
>
> On 25 January 2016 at 11:01, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 25/01/16 10:05, Stian Thorgersen wrote:
>>
>>
>>
>> On 25 January 2016 at 09:54, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> Not sure about that. IMO seconds are good to have more fine grained
>>> timeout values. For example in some deployment the "Access token timeout"
>>> value 1 minute might be too short, but 2 minutes are too long, so they
>>> prefer to use 90 seconds as compromise.
>>>
>>
>> I disagree, I really don't see anyone needing to set timeouts in second
>> granularity,
>>
>> Hmm... Don't you think the 90 seconds example is not realistic for any
>> deployment?
>>
>
> To much options and flexibility is usually what makes people hate
> something. I'm pretty sure the choice between 1 or 2 min is more than
> sufficient.
>
>
>>
>> Another thing is "Client login timeout" . This is limited just by network
>> performance and doesn't require any action from user. Usually it will take
>> around 1-2 seconds to complete. So shouldn't we decrease the current
>> default value 1 minute to something lower (10 seconds?). Having bigger
>> value theoretically decreases login security as attacker have more time to
>> exchange stolen code for token.
>>
>
> Client login timeout could potentially be smaller than one minute.
> However, 10 seconds is to short as there will be requests that take more
> than 10 seconds. So it could be reduced to 30 seconds. However, the
> difference between 30 seconds and 1 minute has no effect on security. If
> someone can intercept the code and use within a minute they can do it
> within 30 seconds as well (even 10 seconds). So 1 minute is as good from a
> security perspective IMO, but more user friendly than 10 seconds.
>
>
>>
>>
>>
>>>
>>> Also seconds are good for development. For example, I am sometimes using
>>> seconds for testing (IE. setting timeout to 10 seconds to quickly enforce
>>> refresh etc)
>>>
>>> Skip seconds to address KEYCLOAK-1341 looks to me like workaround rather
>>> than real solution. The question is if we should address KEYCLOAK-1341 at
>>> all? There are probably many possibilities how can admin breaks the login
>>> to admin console itself or break the keycloak entirely. Few examples, which
>>> come to my mind (there are likely much more):
>>> - Delete or disable security-admin-console client
>>>
>>
>> We're going to prevent users from deleting internal clients and roles, so
>> that won't be a problem anymore
>>
>>
>>> - delete or disable himself
>>>
>>
>> Can be recovered by adding new user using add-user script
>>
>>
>>> - remove roles from himself
>>>
>>
>> Same as above
>>
>>
>>> - remove scopes from security-admin-console client
>>>
>>
>> We haven't covered that one
>>
>>
>>> - configure authentication flow in some way that it's not possible login
>>> anymore
>>>
>>
>> Not covered either
>>
>>
>>> - Timeouts
>>>
>>> I don't think that we should try to prevent all of these situations. I
>>> didn't see any real support questions related to this. And for example in
>>> linux if you do "rm -rf /home" the system is broken as well. Isn't this
>>> kind of similar? IMO admins should do backup of database, so they can
>>> revert if they accidentally mis-configure things.
>>>
>>
>> What you are saying makes no sense whatsoever. It's like saying
>> validation in user interfaces is a waste of time.
>>
>> I am not saying validation is lack of time. Agree we should have them.
>> But IMO validations are not always sufficient and I don't think that we can
>> handle every "bad" situation. So would recommend people to do backup of
>> database to prevent mis-configure things.
>>
>
>> Also not sure if it's always good approach to restrict functionality from
>> admin console just to prevent people from break things. Likely yes in some
>> cases (builtin objects), however in some other it may be better to use
>> cofirmation warnings (Do you really want to set timeout just to 10 seconds?
>> Do you really want to re-configure browser authentication flow of master
>> realm? etc). I suppose admins are technical people and they know what
>> they're doing.
>>
>>
>> Validation in user interfaces are there to help people, and to prevent
>> people doing things that will screw things up. This is an really good
>> example of where lack of validation on inputs allows users to set stupid
>> values. 1 second timeouts never makes any sense, so why should we let users
>> set it. It could also be a mistake as someone wanted to set 1 minute, but
>> selected second by mistake.
>>
>> How about use the confirmation dialog if any timeout is set to smaller
>> value than 10 seconds as I mentioned above?
>>
>
> -1 There's just no need for less than 10 seconds so why even have the
> option. Removing seconds is a really simple fix. Adding validation and
> additional notifications boxes is more complex.
>
>
>>
>> There are likely much more things, which we should handle regarding
>> timeouts. And likely disallow some of them. For example:
>> - If someone sets "Session Idle timeout" smaller than "Access token
>> timeout", the refreshes will be broken. This config should be probably
>> restricted
>> - Same for "Session max lifespan" . Maybe we should prevent people from
>> set "Session max lifespan" to be shorter than any other timeout at all
>> (despite "Offline session idle" )
>>
>
> Yes, but we can't do everything now. We'll need to introduce proper
> validation on admin console/endpoints at some stage, but that's for later.
>
> This was a simple proposal to remove one pretty disastrous mistake.
>
> Ok, I am fine with that if you thing seconds are redundant. We'll see if
> community has feedback and want to return seconds ;-)
>
> Marek
>
>
>
>>
>>
>> Marek
>>
>>
>> Arguing against preventing people from screwing things up for themselves
>> by coming with another example where they can screw things up is just not
>> good argumentation. We should do as much as we can, and in this case it's a
>> very simple fix that could prevent a rather annoying issue.
>>
>>
>>>
>>> Marek
>>>
>>> On 21/01/16 20:45, Stian Thorgersen wrote:
>>>
>>> Do we need to have seconds at all for token timeouts? Removing seconds
>>> from token would make it simpler, but also make sure no one sets timeouts
>>> that are to short (see https://issues.jboss.org/browse/KEYCLOAK-1341)
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/cca11c6f/attachment.html