[keycloak-dev] Reset Password changes complete needs review

Stian Thorgersen stian at redhat.com
Thu Aug 20 10:05:19 EDT 2015


If it makes it easier I think sending a recover password link, but not loging-in the user afterwards is fine.

----- 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 4:00:13 PM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> Google sends link as well, see attached screenshot
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at 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 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
> > 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


More information about the keycloak-dev mailing list