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
> * 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
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.
> * Change password is something initiated by an admin. This just
> an email to the user to reset their password and does not start an
> authentcation flow.
I don't understand why there's two different names/concepts here.
The messages would be different:
Reset password: Somebody reset your password, click the link or enter in
the code on the web page from the email
Change password: Your adminstrator has requested you change your
credentials. Please click the link to reset them.
Reset password could potentially log the user in. Change password would
not log the user in and just display a "Credentials Reset" message.
Yes, we should never make it possible to guess/check
That's what I assumed and that's what I implemented.
JBoss, a division of Red Hat