[keycloak-dev] Reset Password changes complete needs review

Thu Aug 20 09:54:40 EDT 2015

And yet with Google, you enter in a temporary code to reset credentials.

You talk about this "single argument", but it is more than that...With 
us, a brand new tab is opened when you click the link leaving the old 
one open. Leaving that old window in a stale state where a user may or 
may not get an error message if they try to use that window.  (This 
problem existed prior to the Auth SPI).

And, if you read my email, its more than just being incompatible, its 
something we'll have to explain in detail in the documentation as well 
as provide "hack" APIs just to support when users want to write 
extensions.  It also forces required actions to be aware of the context 
they are called in.  Its a mess...It as all fine and dandy to hard code 
this stuff before, but now that we have a public API we can't have all 
these special cases as writing extensions becomes a real pain in the ass 
for users and for us as we'll be answering the same questions over and 
over..."Why doesn't this work?"  "Well, did you read section 9.2.1.1 of 
the manual, paragraph 2 where it says you have to call this special API 
call and manage a cookie?"

On 8/20/2015 3:09 AM, Stian Thorgersen wrote:
> Attached screenshots of reset password from Facebook, Redhat, Twitter and Microsoft. All, but Microsoft, send a reset password link. Other websites where I've recently changed my password also all send links.
>
> It's clearly easier for users to click a link than copy/pasting, which would include finding the original window/tab. If the email is delayed with a few minutes the user may quite likely have moved on to something else and might have closed the original window.
>
> This all boils down to a single argument and that is that it's not compatible with the current authentication SPI. That's a problem with the SPI that needs resolving.
>
> What would work fine is that we store the required context in an encrypted cookie. Only if the cookie is available would we proceed with loging-in the user. Otherwise the user would only be allowed to reset the password and would then have to go back to the application to re-login with the new password. In that case resetting the password is not an authentication flow, but an action that a user is permitted to do with a special temporary key.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 20 August, 2015 8:46:15 AM
>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>
>> By the way try reset your password on any website, they will all send you a
>> link you need to click
>>
>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian at redhat.com>
>>> To: "Bill Burke" <bburke at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 20 August, 2015 8:44:12 AM
>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>>
>>> -1000 Clicking a link is a lot simpler for most users - especially
>>> mobile/tablet users. Have you ever tried to copy/paste on a mobile!
>>>
>>> Do not change this to requiring copy/pasting a code!
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 20 August, 2015 4:04:31 AM
>>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>>>
>>>>
>>>>
>>>> On 8/19/2015 9:10 PM, Bill Burke wrote:
>>>>>
>>>>>
>>>>> On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
>>>>>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs
>>>>>>> review
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
>>>>>>>> Can you elaborate on what the benefits are of these changes? It
>>>>>>>> seems
>>>>>>>> to
>>>>>>>> me
>>>>>>>> that we had something that was working just fine..
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
>>>>>>>>> Subject: [keycloak-dev] Reset Password changes complete needs
>>>>>>>>> review
>>>>>>>>>
>>>>>>>>> Here's what I did, I can change things based on questions I asked
>>>>>>>>> in
>>>>>>>>> other emails, but here's how it works.
>>>>>>>>>
>>>>>>>>> There's now the concept of "reset password" and a different one
>>>>>>>>> "change
>>>>>>>>> password".
>>>>>>>>>
>>>>>>>>> * Reset password is something the user initiates.  This will start
>>>>>>>>> an
>>>>>>>>> Authentication Flow and success will login the user and bring them
>>>>>>>>> to
>>>>>>>>> their application
>>>>>>>>
>>>>>>>> I assume this is still through email - if so it's important that
>>>>>>>> users
>>>>>>>> are
>>>>>>>> only logged-in if the reset password link is opened in the same user
>>>>>>>> session as they initiated the reset password flow
>>>>>>>>
>>>>>>>
>>>>>>> With the previous impl, if somebody as able to hack your email
>>>>>>> account,
>>>>>>> then they could bypass OTP entirely.  Also previous implementation
>>>>>>> wasn't really compatible with auth SPI.  There may be additional
>>>>>>> steps
>>>>>>> to reseting credentials beyond an email, i.e. entering in a code from
>>>>>>> an
>>>>>>> SMS message.  We may also be reseting both OTP and Password.
>>>>>>> Finally,
>>>>>>> the update password required action had reset-password specific logic
>>>>>>> within it.
>>>>>>>
>>>>>>> Honestly, I'd prefer to switch exclusively to a temporary code as it
>>>>>>> makes everything much simpler to support:  for us and for users
>>>>>>> wanting
>>>>>>> to write extensiosn.  I don't think this is a big usability issue as
>>>>>>> Google requires entering a temporary code from an SMS message.  Also,
>>>>>>> with the way it worked in 1.4, out-of-band email password reset would
>>>>>>> require relogging in which is actually more steps.  Finally, links
>>>>>>> can
>>>>>>> be messed up by email readers sometimes if they are long enough,
>>>>>>> making
>>>>>>> them error prone.
>>>>>>
>>>>>> -100 We should stick with link in email (and only link, not confuse
>>>>>> users
>>>>>> by having multiple options), but why can't the link just include the
>>>>>> same
>>>>>> code?
>>>>>>
>>>>>
>>>>> I also don't want multiple options.  I want to get rid of the link
>>>>> entirely.
>>>>>
>>>>> I'm repeating myself, but, This is about your requirement of
>>>>> out-of-band
>>>>> link-clicks not logging in the user.  That kind of flow is not
>>>>> compatible with the current Auth SPI and it requires hacks to required
>>>>> actions like Update Password to even work (which already exist).  We're
>>>>> also going to have to make users aware of it and explain how to code
>>>>> for
>>>>> it if they are writing their own extension.  It just makes things a lot
>>>>> more complicated if you are extending things.
>>>>>
>>>>> Finally, I don't like the link because at least for me, it opens a
>>>>> brand
>>>>> new tab and leaves the original still active.  I also don't think the
>>>>> link is more user-friendly when the link is clicked in another browser.
>>>>>     It is also possible the user is obtaining the link on a phone and
>>>>>     that
>>>>> our update password screen will be a bit cramped there.  Also, typing
>>>>> in
>>>>> a password from a phone is quite awkward and time consuming.
>>>>>
>>>>
>>>> Furthermore, I don't like Verify Email either.  It also should be
>>>> changed from link clicking to code entry.  Like Reset Email, a new tab
>>>> is opened if you click the link.  Like Reset Email, Verify email
>>>> requires you to completely relogin if the link is clicked in a different
>>>> browser.
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com