----- Original Message -----
From: "Michael Gerber" <gerbermichi@me.com>
To: "Bill Burke" <bburke@redhat.com>
Cc: "Stian Thorgersen" <stian@redhat.com>, keycloak-dev@lists.jboss.org
Sent: Tuesday, January 27, 2015 10:33:09 AM
Subject: Re: [keycloak-dev] Rest password can cause cookie not found
Am 26. Januar 2015 um 20:49 schrieb Bill Burke <bburke@redhat.com>:
>
>
> On 1/26/2015 1:31 PM, Michael Gerber wrote:
>>> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke@redhat.com
>>>
>>> <mailto:bburke@redhat.com>>:
>>> On 1/26/2015 12:12 PM, Michael Gerber wrote:
>>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke@redhat.com
>>>>>
>>>>> <mailto:bburke@redhat.com>>:
>>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke@redhat.com <mailto:bburke@redhat.com>>
>>>>>>> To: keycloak-dev@lists.jboss.org
>>>>>>> <mailto:keycloak-dev@lists.jboss.org>
>>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
>>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>>>>>> Wouldn't this work?
>>>>>>> 1) store "state" of state cookie in user session.
>>>>>>> 2) embed user session and state of state cookie in URL
>>>>>>> Of course this screws up your "shorter URL" crusade.
>>>>>> I'm not following - the problem isn't remembering the state
>>>>>> variable in Keycloak, that's already sorted as we already store all
>>>>>> the query params passed by the client in the client session (state,
>>>>>> redirect_uri, etc). The problem is storing it on the adapter side.
>>>>> I think I get it...
>>>>> 1. Send email
>>>>> 2. Close browser
>>>>> 3. Open browser
>>>>> 4. Click email link
>>>>> 5. Reset password
>>>>> 6. Redirect back to app
>>>>> 7. App barfs because of state cookie
>>>>> Persistent state cookie sounds like cleanest and simplest solution. I
>>>>> just worry we'll introduce different bugs, or if we're opening up some
>>>>> kind of security hole. Maybe I'm just paranoid.
>>>> That doesn't work if the user uses two different browsers. This is
>>>> the case in a lot of companies (at least in Switzerland :)) where the
>>>> users are forced to use ie (default) but rather work with firefox.
>>> Unless we extend the protocol, or don’t redirect from the email, I
>>> don’t see a fix.
>> If the password reset process would redirect without the code and state
>> param, than the adapter would redirect back to the keycloak, and
>> keycloak can authenticate the user with its identity cookie…
>> But I don’t know if that is ok with the protocol.
>
> So maybe have a session cookie that is set by the auth server. If that
> cookie is set when clicking the email url, redirect with code, if not,
> redirect without it.
>
That sounds good, what do the other think about this fallback option?
I can update the JIRA issue if anybody is happy with that solution.

I'm happy with the idea of setting a session cookie so we can detect if a user is using the same browser to complete the flow. However, I don't think we should redirect back to the application.

In this case the user most likely wants to use a different browser for the application. For example a user uses Firefox to open the application, click on recover password, but then due to company policies IE is registered as the default OS browser so links in emails are opened in IE instead. In this case the user wants to close IE after resetting the password and go back to Firefox to use the application.

In the case the user is completing the password reset flow in a different browser it would be better to update the password, make sure no identity cookie or user session is created in the new browser, then just display a message "Your password has been updated".