Google sends link as well, see attached screenshot
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 20 August, 2015 3:54:40 PM
Subject: Re: [keycloak-dev] Reset Password changes complete needs review
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(a)redhat.com>
>> To: "Bill Burke" <bburke(a)redhat.com>
>> Cc: keycloak-dev(a)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(a)redhat.com>
>>> To: "Bill Burke" <bburke(a)redhat.com>
>>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>> To: keycloak-dev(a)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(a)redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>>>>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>>>>>>> To: keycloak-dev(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com