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(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)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(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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev