[keycloak-dev] Reset Password changes complete needs review

[Stian Thorgersen]

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
> > 
>