[keycloak-dev] Improve back-button and refreshes in authenticators?

[Marek Posolda]

On 20/03/17 08:54, Stian Thorgersen wrote:
> Let's go with the "page expired" page then, but we wouldn't need it 
> for the refresh page would we? That can just re-display the same thing 
> again.
IMO if you are on TOTP page and you click "refresh", you should just 
receive the TOTP page.

However for the case that you are on TOTP page and you clicked "back", 
you are on our "page expired" page. Now you click "Refresh" you should 
be still on "page expired" page IMO. If user wants to go to last step, 
he can click on the link, which we provide on our "page expired" page 
and then he will go to last step and TOTP page is shown. I think it will 
be challenging to do it other way as there is no easy way to track if 
request was triggered with back, forward or refresh button.

>
> +1 I kinda thought about writing authenticators, but you're right that 
> should be made as simple as possible and we should ideally handle all 
> of this outside the authenticators themselves. Something that would be 
> impossible if users could step backwards/forwards in the flow as you'd 
> have to have "roll back" events or something so authenticators could 
> undo stuff if needed.
Another posibility is to track the complete history of loginSession. 
Hence clicking back-button will revert also the loginSession to the step 
before last authenticator and all the changes to the state of 
loginSession (notes, attributes authenticatedUser etc) will be reverted 
to that stage. However this looks like quite challenging and not optimal 
for memory footprint... I guess not an option?

Marek
>
> On 17 March 2017 at 16:21, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     The best user experience would be that the user can click the
>     back/forward/refresh buttons as they wanted and things would work
>     as they would expect, i.e. if you're on the OTP page, you could
>     click the back button and go to the username/password page and
>     re-enter username password.  I didn't implement support for this
>     approach as its really freakin hard to get right.
>
>     The real question is, do we want to support going backwards or
>     forwards in a flow?  If we don't, then there are considerations
>     and limitations on what we can do for the user experience which I
>     was trying to get at before.  Specifically:
>
>     * Is it possible to determine the difference between the back,
>     forward, or refresh button event?
>
>     That is the question I struggled the most with when implementing
>     auth flow processing.
>
>     I'd say we set the bar low and minimally try to provide this
>     experience:
>
>     * If back, forward, or refresh button is pushed, show the "Page
>     expired" page you suggested before Stian.
>
>     Anything different than that will be dependent on the limitations
>     of the browser and our auth flow implementation.
>
>     There's also another type of user experience you aren't
>     considering that should be involved with the discussion. 
>     Specifically the user experience of writing an Authenticator.  You
>     want the Authenticator development to be simple...you also want to
>     make sure that its implemented in a way that developers can't make
>     mistakes and introduce security holes by accident.  All this stuff
>     is tied together which makes the problem really complex.
>
>
>     On 3/17/17 3:45 AM, Stian Thorgersen wrote:
>>     I repeat:
>>
>>     Before we discuss implementation though, let's figure out what
>>     the ideal user experience would be then figure out how to
>>     implement it. What about:
>>
>>     * Refresh just works
>>     * Back button will display a nicer page, something like "Page has
>>     expired. To restart the login process click here. To continue the
>>     login process click here.". Or Back button could just go to the
>>     start of the flow always.
>>     * Resubmitting forms will just display the page above
>>     * No need to do redirects. Redirects is bad for performance, but
>>     also has twice the response time which is not good from a
>>     usability perspective
>>
>>     Is this the optimal user experience? Or should we do something else?
>>
>>     On 17 March 2017 at 08:44, Stian Thorgersen <sthorger at redhat.com
>>     <mailto:sthorger at redhat.com>> wrote:
>>
>>         Can we please get back to discussing what the best user
>>         experience is first. Then we can discuss implementations?
>>
>>         On 16 March 2017 at 18:37, Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>             On 3/16/17 10:50 AM, Marek Posolda wrote:
>>>             On 16/03/17 15:27, Bill Burke wrote:
>>>>             * Hidden field in a form is not a good approach. Its
>>>>             very brittle and will not work in every situation.  So
>>>>             huge -1 there.
>>>>
>>>>             * browser back button is not required to resubmit the
>>>>             HTTP request as the page can be rendered from cache. 
>>>>             Therefore you couldn't have a "Page Expired" page
>>>>             displayed when the back button is pressed without
>>>>             setting the header "Cache-Control: no-store,
>>>>             must-revalidate, max-age=0"
>>>             Maybe we can do some javascript stuff like this:
>>>             http://stackoverflow.com/questions/9046184/reload-the-site-when-reached-via-browsers-back-button
>>>             <http://stackoverflow.com/questions/9046184/reload-the-site-when-reached-via-browsers-back-button>
>>>
>>>             But that would mean that we will need to inject some
>>>             common javascript stuff into every HTML form displayed
>>>             by authentication SPI. Could we rely on that?
>>             I don't think this is a good approach as Authenticator
>>             develoeprs would have to do the same thing.
>>
>>
>>>>
>>>>             * Furthermore, without some type of code/information
>>>>             within the URL, you also wouldn't know if somebody
>>>>             clicked the back button or not or whether this was a
>>>>             page refresh or some other GET request.
>>>             Once we have the cookie with loginSessionID, we can
>>>             lookup the loginSession. And loginSession will contain
>>>             last code (same like clientSession now) and last
>>>             authenticator. Then we just need to compare the code
>>>             from the loginSession with the code from request. If it
>>>             matches, we are good. If it doesn't match, it's likely
>>>             the refresh of some previous page and in that case, we
>>>             can just redirect to last authenticator.
>>>
>>             This is the current behavior, but instead of using a
>>             cookie, the "code" is stored in the URL.
>>
>>             With only a cookie though and no URL information, you
>>             won't know the different between a Back Button and a Page
>>             Refresh for GET requests.  For POST requests, you won't
>>             be able to tell the differencee between a Back Button,
>>             Page Refresh, or whether the POST is targeted to an
>>             actual Authenticator.
>>
>>             The more I think about it, things should probably stay
>>             the way it currently is, with improvements on user
>>             experience.  I think we can support what Stian suggested
>>             with the current implementation.
>>
>>
>>>             Not sure if we also need to track all codes, so we are
>>>             able to distinct between the "expired" code, and between
>>>             the "false" code, which was never valid and was possibly
>>>             used by some attacker for CSRF. Maybe we can sign codes
>>>             with HMAC, so we can verify if it is "expired" or
>>>             "false" code without need to track the list of last codes.
>>
>>             This has been done in the past.  Then it was switched to
>>             using the same code throughout the whole flow, then Stian
>>             switched it to changing the code throughout the flow.  I
>>             don't know if he uses a hash or not.
>>
>>             Bill
>>
>>
>>
>
>