Re: [keycloak-dev] Reset Password changes complete needs review

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; 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&gt; > 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&gt; > >>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; > >>> 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&gt; > >>>>> 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 >