[keycloak-dev] Remove seconds for token timeouts

Marek Posolda mposolda at redhat.com
Mon Jan 25 06:18:36 EST 2016


On 25/01/16 12:01, Stian Thorgersen wrote:
>
>
> On 25 January 2016 at 11:01, Marek Posolda <mposolda at redhat.com 
> <mailto: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
>>     <mailto: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 list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/21588d71/attachment-0001.html 


More information about the keycloak-dev mailing list