5:53 a.m.
When working on login sessions, I wonder if we want to improve browser
back-button and browser refreshes.
In shortcut, I can see 3 basic options:
1) Keep same like now and rely on header "Cache-Control: no-store,
must-revalidate, max-age=0" . This works fine and users never saw
outdated form and never submit outdated form 2 times. However the
usability sucks a bit IMO. When you press back-button after POST
request, you can see the ugly browser page "Web page has expired" . And
if you press F5 on this, you will see the unfriendly Keycloak error page
"Error was occured. Please login again through your application" because
of invalid code.
2) Use the pattern with POST followed by the redirect to GET. Since we
will have loginSession with the ID in the cookie, the GET request can be
sent to the URL without any special query parameter. Something like
"http://localhost:8180/auth/realms/master/login-actions/authenticate" .
This will allow us that in every stage of authentication, user can press
back-button and will be always redirected to the first step of the flow.
When he refreshes the page, it will re-send just the GET request and
always brings him to the current execution.
This looks most user-friendly. But there is the issue with performance
though. As we will need to followup every POST request with one
additional GET request.
3) Don't do anything special regarding back-button or refresh. But in
case that page is refreshed AND the post with invalid (already used)
code will be re-submitted, we won't display the ugly page "Error was
occured.", but we will just redirect to current step of the flow.
Example:
a) User was redirected from the application to OIDC
AuthorizationEndpoint request. Login page is shown
b) User confirmed invalid username and password with POST request. Login
form with error page "Invalid password" is shown
c) User confirmed valid username and password with POST request. TOTP
page is shown.
d) User press back-button. Now he will see again the page with
username/password form.
e) User press F5. The POST request will be re-sent, but it will use
previous "code", which is outdated now. So in this case, we will
redirect to the current execution and TOTP form will be shown. No
re-submission of username/password form will happen.
In case 3, the username/password form will be shown again, but user
won't be able to resubmit it.
In shortcut: With 2 and 3, users will never see the browser page "Web
page is expired" or Keycloak "Error occured. Go back to the
application". With 2, there is additional GET request needed. With 3,
the back-button may show the authentication forms, which user already
successfully confirmed, but he won't be able to re-submit them. Is it
bad regarding usability? To me, it looks better than showing "Web page
is expired".
So my preference is 3,2,1. WDYT? Any other options?
Marek
7:50 a.m.
I've got an idea. What about
* keep the code in the URL
* Additionally add a "current-code" cookie
If code in the URL doesn't match the cookie, then redirect to the URL of
the current-code.
On 3/14/17 6:53 AM, Marek Posolda wrote:
When working on login sessions, I wonder if we want to improve
browser
back-button and browser refreshes.
In shortcut, I can see 3 basic options:
1) Keep same like now and rely on header "Cache-Control: no-store,
must-revalidate, max-age=0" . This works fine and users never saw
outdated form and never submit outdated form 2 times. However the
usability sucks a bit IMO. When you press back-button after POST
request, you can see the ugly browser page "Web page has expired" . And
if you press F5 on this, you will see the unfriendly Keycloak error page
"Error was occured. Please login again through your application" because
of invalid code.
2) Use the pattern with POST followed by the redirect to GET. Since we
will have loginSession with the ID in the cookie, the GET request can be
sent to the URL without any special query parameter. Something like
"http://localhost:8180/auth/realms/master/login-actions/authenticate" .
This will allow us that in every stage of authentication, user can press
back-button and will be always redirected to the first step of the flow.
When he refreshes the page, it will re-send just the GET request and
always brings him to the current execution.
This looks most user-friendly. But there is the issue with performance
though. As we will need to followup every POST request with one
additional GET request.
3) Don't do anything special regarding back-button or refresh. But in
case that page is refreshed AND the post with invalid (already used)
code will be re-submitted, we won't display the ugly page "Error was
occured.", but we will just redirect to current step of the flow.
Example:
a) User was redirected from the application to OIDC
AuthorizationEndpoint request. Login page is shown
b) User confirmed invalid username and password with POST request. Login
form with error page "Invalid password" is shown
c) User confirmed valid username and password with POST request. TOTP
page is shown.
d) User press back-button. Now he will see again the page with
username/password form.
e) User press F5. The POST request will be re-sent, but it will use
previous "code", which is outdated now. So in this case, we will
redirect to the current execution and TOTP form will be shown. No
re-submission of username/password form will happen.
In case 3, the username/password form will be shown again, but user
won't be able to resubmit it.
In shortcut: With 2 and 3, users will never see the browser page "Web
page is expired" or Keycloak "Error occured. Go back to the
application". With 2, there is additional GET request needed. With 3,
the back-button may show the authentication forms, which user already
successfully confirmed, but he won't be able to re-submit them. Is it
bad regarding usability? To me, it looks better than showing "Web page
is expired".
So my preference is 3,2,1. WDYT? Any other options?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:49 p.m.
Thanks, that looks similar to my (3) though.
Besides that I wonder if we should save just the ID of loginSession in
the cookie and the "current-code" keep inside the loginSession
(infinispan) similarly like it is now?
I am thinking about the case when potential attacker tricks Keycloak by
manually sending the request, which will just use same code in the
cookie and in the URL. Keycloak will then always treat this request as
valid due the code in the URL and in cookie will always match. Couldn't
that be an issue?
Marek
On 14/03/17 13:50, Bill Burke wrote:
I've got an idea. What about
* keep the code in the URL
* Additionally add a "current-code" cookie
If code in the URL doesn't match the cookie, then redirect to the URL of
the current-code.
On 3/14/17 6:53 AM, Marek Posolda wrote:
> When working on login sessions, I wonder if we want to improve browser
> back-button and browser refreshes.
>
> In shortcut, I can see 3 basic options:
>
> 1) Keep same like now and rely on header "Cache-Control: no-store,
> must-revalidate, max-age=0" . This works fine and users never saw
> outdated form and never submit outdated form 2 times. However the
> usability sucks a bit IMO. When you press back-button after POST
> request, you can see the ugly browser page "Web page has expired" . And
> if you press F5 on this, you will see the unfriendly Keycloak error page
> "Error was occured. Please login again through your application" because
> of invalid code.
>
> 2) Use the pattern with POST followed by the redirect to GET. Since we
> will have loginSession with the ID in the cookie, the GET request can be
> sent to the URL without any special query parameter. Something like
> "http://localhost:8180/auth/realms/master/login-actions/authenticate" .
> This will allow us that in every stage of authentication, user can press
> back-button and will be always redirected to the first step of the flow.
> When he refreshes the page, it will re-send just the GET request and
> always brings him to the current execution.
>
> This looks most user-friendly. But there is the issue with performance
> though. As we will need to followup every POST request with one
> additional GET request.
>
> 3) Don't do anything special regarding back-button or refresh. But in
> case that page is refreshed AND the post with invalid (already used)
> code will be re-submitted, we won't display the ugly page "Error was
> occured.", but we will just redirect to current step of the flow.
>
> Example:
> a) User was redirected from the application to OIDC
> AuthorizationEndpoint request. Login page is shown
> b) User confirmed invalid username and password with POST request. Login
> form with error page "Invalid password" is shown
> c) User confirmed valid username and password with POST request. TOTP
> page is shown.
> d) User press back-button. Now he will see again the page with
> username/password form.
> e) User press F5. The POST request will be re-sent, but it will use
> previous "code", which is outdated now. So in this case, we will
> redirect to the current execution and TOTP form will be shown. No
> re-submission of username/password form will happen.
>
> In case 3, the username/password form will be shown again, but user
> won't be able to resubmit it.
>
> In shortcut: With 2 and 3, users will never see the browser page "Web
> page is expired" or Keycloak "Error occured. Go back to the
> application". With 2, there is additional GET request needed. With 3,
> the back-button may show the authentication forms, which user already
> successfully confirmed, but he won't be able to re-submit them. Is it
> bad regarding usability? To me, it looks better than showing "Web page
> is expired".
>
> So my preference is 3,2,1. WDYT? Any other options?
>
> Marek
>
> _______________________________________________
> 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
5:47 p.m.
Ya, similar to #3, my thought is if you combine a cookie with
code-in-url, you have a solution for backbutton and refresh and there's
no special headers you have to specify. We used to do #2, but lot of
people, specifically jboss.org guys, complained about it.
On 3/14/17 4:49 PM, Marek Posolda wrote:
Thanks, that looks similar to my (3) though.
Besides that I wonder if we should save just the ID of loginSession in
the cookie and the "current-code" keep inside the loginSession
(infinispan) similarly like it is now?
I am thinking about the case when potential attacker tricks Keycloak
by manually sending the request, which will just use same code in the
cookie and in the URL. Keycloak will then always treat this request as
valid due the code in the URL and in cookie will always match.
Couldn't that be an issue?
Marek
On 14/03/17 13:50, Bill Burke wrote:
> I've got an idea. What about
>
> * keep the code in the URL
>
> * Additionally add a "current-code" cookie
>
> If code in the URL doesn't match the cookie, then redirect to the URL of
> the current-code.
>
>
> On 3/14/17 6:53 AM, Marek Posolda wrote:
>> When working on login sessions, I wonder if we want to improve browser
>> back-button and browser refreshes.
>>
>> In shortcut, I can see 3 basic options:
>>
>> 1) Keep same like now and rely on header "Cache-Control: no-store,
>> must-revalidate, max-age=0" . This works fine and users never saw
>> outdated form and never submit outdated form 2 times. However the
>> usability sucks a bit IMO. When you press back-button after POST
>> request, you can see the ugly browser page "Web page has expired" .
And
>> if you press F5 on this, you will see the unfriendly Keycloak error
>> page
>> "Error was occured. Please login again through your application"
>> because
>> of invalid code.
>>
>> 2) Use the pattern with POST followed by the redirect to GET. Since we
>> will have loginSession with the ID in the cookie, the GET request
>> can be
>> sent to the URL without any special query parameter. Something like
>> "http://localhost:8180/auth/realms/master/login-actions/authenticate"
.
>> This will allow us that in every stage of authentication, user can
>> press
>> back-button and will be always redirected to the first step of the
>> flow.
>> When he refreshes the page, it will re-send just the GET request and
>> always brings him to the current execution.
>>
>> This looks most user-friendly. But there is the issue with performance
>> though. As we will need to followup every POST request with one
>> additional GET request.
>>
>> 3) Don't do anything special regarding back-button or refresh. But in
>> case that page is refreshed AND the post with invalid (already used)
>> code will be re-submitted, we won't display the ugly page "Error was
>> occured.", but we will just redirect to current step of the flow.
>>
>> Example:
>> a) User was redirected from the application to OIDC
>> AuthorizationEndpoint request. Login page is shown
>> b) User confirmed invalid username and password with POST request.
>> Login
>> form with error page "Invalid password" is shown
>> c) User confirmed valid username and password with POST request. TOTP
>> page is shown.
>> d) User press back-button. Now he will see again the page with
>> username/password form.
>> e) User press F5. The POST request will be re-sent, but it will use
>> previous "code", which is outdated now. So in this case, we will
>> redirect to the current execution and TOTP form will be shown. No
>> re-submission of username/password form will happen.
>>
>> In case 3, the username/password form will be shown again, but user
>> won't be able to resubmit it.
>>
>> In shortcut: With 2 and 3, users will never see the browser page "Web
>> page is expired" or Keycloak "Error occured. Go back to the
>> application". With 2, there is additional GET request needed. With 3,
>> the back-button may show the authentication forms, which user already
>> successfully confirmed, but he won't be able to re-submit them. Is it
>> bad regarding usability? To me, it looks better than showing "Web page
>> is expired".
>>
>> So my preference is 3,2,1. WDYT? Any other options?
>>
>> Marek
>>
>> _______________________________________________
>> 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
5:44 a.m.
I like option #3, but what about adding a hidden field on the form that
contains the step in the flow. That way we can easily find out if the form
is a post for the current step or not. If it's not then we simply ignore
the post and return the current step again? That would work for
back/forward and refresh.
On 14 March 2017 at 23:47, Bill Burke <bburke(a)redhat.com> wrote:
Ya, similar to #3, my thought is if you combine a cookie with
code-in-url, you have a solution for backbutton and refresh and there's
no special headers you have to specify. We used to do #2, but lot of
people, specifically jboss.org guys, complained about it.
On 3/14/17 4:49 PM, Marek Posolda wrote:
> Thanks, that looks similar to my (3) though.
>
> Besides that I wonder if we should save just the ID of loginSession in
> the cookie and the "current-code" keep inside the loginSession
> (infinispan) similarly like it is now?
>
> I am thinking about the case when potential attacker tricks Keycloak
> by manually sending the request, which will just use same code in the
> cookie and in the URL. Keycloak will then always treat this request as
> valid due the code in the URL and in cookie will always match.
> Couldn't that be an issue?
>
> Marek
>
> On 14/03/17 13:50, Bill Burke wrote:
>> I've got an idea. What about
>>
>> * keep the code in the URL
>>
>> * Additionally add a "current-code" cookie
>>
>> If code in the URL doesn't match the cookie, then redirect to the URL of
>> the current-code.
>>
>>
>> On 3/14/17 6:53 AM, Marek Posolda wrote:
>>> When working on login sessions, I wonder if we want to improve browser
>>> back-button and browser refreshes.
>>>
>>> In shortcut, I can see 3 basic options:
>>>
>>> 1) Keep same like now and rely on header "Cache-Control: no-store,
>>> must-revalidate, max-age=0" . This works fine and users never saw
>>> outdated form and never submit outdated form 2 times. However the
>>> usability sucks a bit IMO. When you press back-button after POST
>>> request, you can see the ugly browser page "Web page has expired"
. And
>>> if you press F5 on this, you will see the unfriendly Keycloak error
>>> page
>>> "Error was occured. Please login again through your application"
>>> because
>>> of invalid code.
>>>
>>> 2) Use the pattern with POST followed by the redirect to GET. Since we
>>> will have loginSession with the ID in the cookie, the GET request
>>> can be
>>> sent to the URL without any special query parameter. Something like
>>>
"http://localhost:8180/auth/realms/master/login-actions/authenticate"
.
>>> This will allow us that in every stage of authentication, user can
>>> press
>>> back-button and will be always redirected to the first step of the
>>> flow.
>>> When he refreshes the page, it will re-send just the GET request and
>>> always brings him to the current execution.
>>>
>>> This looks most user-friendly. But there is the issue with performance
>>> though. As we will need to followup every POST request with one
>>> additional GET request.
>>>
>>> 3) Don't do anything special regarding back-button or refresh. But in
>>> case that page is refreshed AND the post with invalid (already used)
>>> code will be re-submitted, we won't display the ugly page "Error
was
>>> occured.", but we will just redirect to current step of the flow.
>>>
>>> Example:
>>> a) User was redirected from the application to OIDC
>>> AuthorizationEndpoint request. Login page is shown
>>> b) User confirmed invalid username and password with POST request.
>>> Login
>>> form with error page "Invalid password" is shown
>>> c) User confirmed valid username and password with POST request. TOTP
>>> page is shown.
>>> d) User press back-button. Now he will see again the page with
>>> username/password form.
>>> e) User press F5. The POST request will be re-sent, but it will use
>>> previous "code", which is outdated now. So in this case, we will
>>> redirect to the current execution and TOTP form will be shown. No
>>> re-submission of username/password form will happen.
>>>
>>> In case 3, the username/password form will be shown again, but user
>>> won't be able to resubmit it.
>>>
>>> In shortcut: With 2 and 3, users will never see the browser page "Web
>>> page is expired" or Keycloak "Error occured. Go back to the
>>> application". With 2, there is additional GET request needed. With 3,
>>> the back-button may show the authentication forms, which user already
>>> successfully confirmed, but he won't be able to re-submit them. Is it
>>> bad regarding usability? To me, it looks better than showing "Web page
>>> is expired".
>>>
>>> So my preference is 3,2,1. WDYT? Any other options?
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> 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
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:56 a.m.
We should be able to detect that with the code in the URL too. So the
question is, if hidden field has any advantage over keeping the code in URL?
Thing is, that browsers always treat every POST request as unique even
if it goes to the same URL. So for example, even if code is not in the
URL and then the user submits username/password form with incorrect
password 5 times, then he needs to press browser back-button 5 times to
return back to initial AuthorizationEndpoint request. Even if every POST
request had same URL without code like
"http://host/auth/realms/master/authenticate" .
Only real advantage I see is, that code in hidden field is maybe a bit
safer. Not sure if worth the effort, I will try to investigate how much
effort it is to put the code to the hidden field instead of URL.
Marek
On 16/03/17 11:44, Stian Thorgersen wrote:
I like option #3, but what about adding a hidden field on the form
that contains the step in the flow. That way we can easily find out if
the form is a post for the current step or not. If it's not then we
simply ignore the post and return the current step again? That would
work for back/forward and refresh.
On 14 March 2017 at 23:47, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Ya, similar to #3, my thought is if you combine a cookie with
code-in-url, you have a solution for backbutton and refresh and
there's
no special headers you have to specify. We used to do #2, but lot of
people, specifically jboss.org <http://jboss.org> guys, complained
about it.
On 3/14/17 4:49 PM, Marek Posolda wrote:
> Thanks, that looks similar to my (3) though.
>
> Besides that I wonder if we should save just the ID of
loginSession in
> the cookie and the "current-code" keep inside the loginSession
> (infinispan) similarly like it is now?
>
> I am thinking about the case when potential attacker tricks Keycloak
> by manually sending the request, which will just use same code
in the
> cookie and in the URL. Keycloak will then always treat this
request as
> valid due the code in the URL and in cookie will always match.
> Couldn't that be an issue?
>
> Marek
>
> On 14/03/17 13:50, Bill Burke wrote:
>> I've got an idea. What about
>>
>> * keep the code in the URL
>>
>> * Additionally add a "current-code" cookie
>>
>> If code in the URL doesn't match the cookie, then redirect to
the URL of
>> the current-code.
>>
>>
>> On 3/14/17 6:53 AM, Marek Posolda wrote:
>>> When working on login sessions, I wonder if we want to improve
browser
>>> back-button and browser refreshes.
>>>
>>> In shortcut, I can see 3 basic options:
>>>
>>> 1) Keep same like now and rely on header "Cache-Control: no-store,
>>> must-revalidate, max-age=0" . This works fine and users never saw
>>> outdated form and never submit outdated form 2 times. However the
>>> usability sucks a bit IMO. When you press back-button after POST
>>> request, you can see the ugly browser page "Web page has
expired" . And
>>> if you press F5 on this, you will see the unfriendly Keycloak
error
>>> page
>>> "Error was occured. Please login again through your
application"
>>> because
>>> of invalid code.
>>>
>>> 2) Use the pattern with POST followed by the redirect to GET.
Since we
>>> will have loginSession with the ID in the cookie, the GET request
>>> can be
>>> sent to the URL without any special query parameter. Something
like
>>>
"http://localhost:8180/auth/realms/master/login-actions/authenticate
<http://localhost:8180/auth/realms/master/login-actions/authenticate>&q...
.
>>> This will allow us that in every stage of authentication, user can
>>> press
>>> back-button and will be always redirected to the first step of the
>>> flow.
>>> When he refreshes the page, it will re-send just the GET
request and
>>> always brings him to the current execution.
>>>
>>> This looks most user-friendly. But there is the issue with
performance
>>> though. As we will need to followup every POST request with one
>>> additional GET request.
>>>
>>> 3) Don't do anything special regarding back-button or refresh.
But in
>>> case that page is refreshed AND the post with invalid (already
used)
>>> code will be re-submitted, we won't display the ugly page
"Error was
>>> occured.", but we will just redirect to current step of the flow.
>>>
>>> Example:
>>> a) User was redirected from the application to OIDC
>>> AuthorizationEndpoint request. Login page is shown
>>> b) User confirmed invalid username and password with POST request.
>>> Login
>>> form with error page "Invalid password" is shown
>>> c) User confirmed valid username and password with POST
request. TOTP
>>> page is shown.
>>> d) User press back-button. Now he will see again the page with
>>> username/password form.
>>> e) User press F5. The POST request will be re-sent, but it
will use
>>> previous "code", which is outdated now. So in this case, we
will
>>> redirect to the current execution and TOTP form will be shown. No
>>> re-submission of username/password form will happen.
>>>
>>> In case 3, the username/password form will be shown again, but
user
>>> won't be able to resubmit it.
>>>
>>> In shortcut: With 2 and 3, users will never see the browser
page "Web
>>> page is expired" or Keycloak "Error occured. Go back to the
>>> application". With 2, there is additional GET request needed.
With 3,
>>> the back-button may show the authentication forms, which user
already
>>> successfully confirmed, but he won't be able to re-submit
them. Is it
>>> bad regarding usability? To me, it looks better than showing
"Web page
>>> is expired".
>>>
>>> So my preference is 3,2,1. WDYT? Any other options?
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
8:43 a.m.
We should get rid of the code for sure. Maybe we can add the ID of the
current step in the flow instead though.
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
On 16 March 2017 at 12:56, Marek Posolda <mposolda(a)redhat.com> wrote:
We should be able to detect that with the code in the URL too. So
the
question is, if hidden field has any advantage over keeping the code in URL?
Thing is, that browsers always treat every POST request as unique
even if
it goes to the same URL. So for example, even if code is not in the URL and
then the user submits username/password form with incorrect password 5
times, then he needs to press browser back-button 5 times to return back to
initial AuthorizationEndpoint request. Even if every POST request had same
URL without code like "http://host/auth/realms/master/authenticate"
<http://host/auth/realms/master/authenticate> .
Only real advantage I see is, that code in hidden field is maybe a bit
safer. Not sure if worth the effort, I will try to investigate how much
effort it is to put the code to the hidden field instead of URL.
Marek
On 16/03/17 11:44, Stian Thorgersen wrote:
I like option #3, but what about adding a hidden field on the form that
contains the step in the flow. That way we can easily find out if the form
is a post for the current step or not. If it's not then we simply ignore
the post and return the current step again? That would work for
back/forward and refresh.
On 14 March 2017 at 23:47, Bill Burke <bburke(a)redhat.com> wrote:
> Ya, similar to #3, my thought is if you combine a cookie with
> code-in-url, you have a solution for backbutton and refresh and there's
> no special headers you have to specify. We used to do #2, but lot of
> people, specifically jboss.org guys, complained about it.
>
>
> On 3/14/17 4:49 PM, Marek Posolda wrote:
> > Thanks, that looks similar to my (3) though.
> >
> > Besides that I wonder if we should save just the ID of loginSession in
> > the cookie and the "current-code" keep inside the loginSession
> > (infinispan) similarly like it is now?
> >
> > I am thinking about the case when potential attacker tricks Keycloak
> > by manually sending the request, which will just use same code in the
> > cookie and in the URL. Keycloak will then always treat this request as
> > valid due the code in the URL and in cookie will always match.
> > Couldn't that be an issue?
> >
> > Marek
> >
> > On 14/03/17 13:50, Bill Burke wrote:
> >> I've got an idea. What about
> >>
> >> * keep the code in the URL
> >>
> >> * Additionally add a "current-code" cookie
> >>
> >> If code in the URL doesn't match the cookie, then redirect to the URL
> of
> >> the current-code.
> >>
> >>
> >> On 3/14/17 6:53 AM, Marek Posolda wrote:
> >>> When working on login sessions, I wonder if we want to improve browser
> >>> back-button and browser refreshes.
> >>>
> >>> In shortcut, I can see 3 basic options:
> >>>
> >>> 1) Keep same like now and rely on header "Cache-Control: no-store,
> >>> must-revalidate, max-age=0" . This works fine and users never saw
> >>> outdated form and never submit outdated form 2 times. However the
> >>> usability sucks a bit IMO. When you press back-button after POST
> >>> request, you can see the ugly browser page "Web page has
expired" .
> And
> >>> if you press F5 on this, you will see the unfriendly Keycloak error
> >>> page
> >>> "Error was occured. Please login again through your
application"
> >>> because
> >>> of invalid code.
> >>>
> >>> 2) Use the pattern with POST followed by the redirect to GET. Since we
> >>> will have loginSession with the ID in the cookie, the GET request
> >>> can be
> >>> sent to the URL without any special query parameter. Something like
> >>>
"http://localhost:8180/auth/realms/master/login-actions/authenticate"
> .
> >>> This will allow us that in every stage of authentication, user can
> >>> press
> >>> back-button and will be always redirected to the first step of the
> >>> flow.
> >>> When he refreshes the page, it will re-send just the GET request and
> >>> always brings him to the current execution.
> >>>
> >>> This looks most user-friendly. But there is the issue with performance
> >>> though. As we will need to followup every POST request with one
> >>> additional GET request.
> >>>
> >>> 3) Don't do anything special regarding back-button or refresh. But
in
> >>> case that page is refreshed AND the post with invalid (already used)
> >>> code will be re-submitted, we won't display the ugly page
"Error was
> >>> occured.", but we will just redirect to current step of the flow.
> >>>
> >>> Example:
> >>> a) User was redirected from the application to OIDC
> >>> AuthorizationEndpoint request. Login page is shown
> >>> b) User confirmed invalid username and password with POST request.
> >>> Login
> >>> form with error page "Invalid password" is shown
> >>> c) User confirmed valid username and password with POST request. TOTP
> >>> page is shown.
> >>> d) User press back-button. Now he will see again the page with
> >>> username/password form.
> >>> e) User press F5. The POST request will be re-sent, but it will use
> >>> previous "code", which is outdated now. So in this case, we
will
> >>> redirect to the current execution and TOTP form will be shown. No
> >>> re-submission of username/password form will happen.
> >>>
> >>> In case 3, the username/password form will be shown again, but user
> >>> won't be able to resubmit it.
> >>>
> >>> In shortcut: With 2 and 3, users will never see the browser page
"Web
> >>> page is expired" or Keycloak "Error occured. Go back to the
> >>> application". With 2, there is additional GET request needed. With
3,
> >>> the back-button may show the authentication forms, which user already
> >>> successfully confirmed, but he won't be able to re-submit them. Is
it
> >>> bad regarding usability? To me, it looks better than showing "Web
page
> >>> is expired".
> >>>
> >>> So my preference is 3,2,1. WDYT? Any other options?
> >>>
> >>> Marek
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
9:27 a.m.
* 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"
* 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.
* Hitting Refresh button also has similar issues when removing the code
from the URL. Hitting refresh on a form POST resends the POSTed data.
Without some kind of code in the URL, the runtime has no idea if this is
a Refresh Button re-POST, or if the browser is POSTing to the current
authenticator.
The way it works now is you have two types of requests which can be GET
or POST.
/authenticate?code={code}
and
/authenticate?code={code}&execution={execution}
The first request corresponds to the Authenticator.authenticate()
method. It basically means you want to display the currrent
authenticator in the flow. The 2nd request means that you processing a
challenge sent by the current Authenticator and corresponds to the
Authenticator.action() method. Without this type of distinction, it is
really hard (impossible) to figure out how to route and process the request.
On 3/16/17 9:43 AM, Stian Thorgersen wrote:
We should get rid of the code for sure. Maybe we can add the ID of
the
current step in the flow instead though.
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
On 16 March 2017 at 12:56, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
We should be able to detect that with the code in the URL too. So
the question is, if hidden field has any advantage over keeping
the code in URL?
Thing is, that browsers always treat every POST request as unique
even if it goes to the same URL. So for example, even if code is
not in the URL and then the user submits username/password form
with incorrect password 5 times, then he needs to press browser
back-button 5 times to return back to initial
AuthorizationEndpoint request. Even if every POST request had same
URL without code like
"http://host/auth/realms/master/authenticate"
<http://host/auth/realms/master/authenticate> .
Only real advantage I see is, that code in hidden field is maybe a
bit safer. Not sure if worth the effort, I will try to investigate
how much effort it is to put the code to the hidden field instead
of URL.
Marek
On 16/03/17 11:44, Stian Thorgersen wrote:
> I like option #3, but what about adding a hidden field on the
> form that contains the step in the flow. That way we can easily
> find out if the form is a post for the current step or not. If
> it's not then we simply ignore the post and return the current
> step again? That would work for back/forward and refresh.
>
> On 14 March 2017 at 23:47, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> Ya, similar to #3, my thought is if you combine a cookie with
> code-in-url, you have a solution for backbutton and refresh
> and there's
> no special headers you have to specify. We used to do #2, but
> lot of
> people, specifically jboss.org <http://jboss.org> guys,
> complained about it.
>
>
> On 3/14/17 4:49 PM, Marek Posolda wrote:
> > Thanks, that looks similar to my (3) though.
> >
> > Besides that I wonder if we should save just the ID of
> loginSession in
> > the cookie and the "current-code" keep inside the
loginSession
> > (infinispan) similarly like it is now?
> >
> > I am thinking about the case when potential attacker tricks
> Keycloak
> > by manually sending the request, which will just use same
> code in the
> > cookie and in the URL. Keycloak will then always treat this
> request as
> > valid due the code in the URL and in cookie will always match.
> > Couldn't that be an issue?
> >
> > Marek
> >
> > On 14/03/17 13:50, Bill Burke wrote:
> >> I've got an idea. What about
> >>
> >> * keep the code in the URL
> >>
> >> * Additionally add a "current-code" cookie
> >>
> >> If code in the URL doesn't match the cookie, then redirect
> to the URL of
> >> the current-code.
> >>
> >>
> >> On 3/14/17 6:53 AM, Marek Posolda wrote:
> >>> When working on login sessions, I wonder if we want to
> improve browser
> >>> back-button and browser refreshes.
> >>>
> >>> In shortcut, I can see 3 basic options:
> >>>
> >>> 1) Keep same like now and rely on header "Cache-Control:
> no-store,
> >>> must-revalidate, max-age=0" . This works fine and users
> never saw
> >>> outdated form and never submit outdated form 2 times.
> However the
> >>> usability sucks a bit IMO. When you press back-button
> after POST
> >>> request, you can see the ugly browser page "Web page has
> expired" . And
> >>> if you press F5 on this, you will see the unfriendly
> Keycloak error
> >>> page
> >>> "Error was occured. Please login again through your
> application"
> >>> because
> >>> of invalid code.
> >>>
> >>> 2) Use the pattern with POST followed by the redirect to
> GET. Since we
> >>> will have loginSession with the ID in the cookie, the GET
> request
> >>> can be
> >>> sent to the URL without any special query parameter.
> Something like
> >>>
> "http://localhost:8180/auth/realms/master/login-actions/authenticate
>
<http://localhost:8180/auth/realms/master/login-actions/authenticate>&q...
> .
> >>> This will allow us that in every stage of authentication,
> user can
> >>> press
> >>> back-button and will be always redirected to the first
> step of the
> >>> flow.
> >>> When he refreshes the page, it will re-send just the GET
> request and
> >>> always brings him to the current execution.
> >>>
> >>> This looks most user-friendly. But there is the issue
> with performance
> >>> though. As we will need to followup every POST request
> with one
> >>> additional GET request.
> >>>
> >>> 3) Don't do anything special regarding back-button or
> refresh. But in
> >>> case that page is refreshed AND the post with invalid
> (already used)
> >>> code will be re-submitted, we won't display the ugly page
> "Error was
> >>> occured.", but we will just redirect to current step of
> the flow.
> >>>
> >>> Example:
> >>> a) User was redirected from the application to OIDC
> >>> AuthorizationEndpoint request. Login page is shown
> >>> b) User confirmed invalid username and password with POST
> request.
> >>> Login
> >>> form with error page "Invalid password" is shown
> >>> c) User confirmed valid username and password with POST
> request. TOTP
> >>> page is shown.
> >>> d) User press back-button. Now he will see again the page
> with
> >>> username/password form.
> >>> e) User press F5. The POST request will be re-sent, but
> it will use
> >>> previous "code", which is outdated now. So in this
case,
> we will
> >>> redirect to the current execution and TOTP form will be
> shown. No
> >>> re-submission of username/password form will happen.
> >>>
> >>> In case 3, the username/password form will be shown
> again, but user
> >>> won't be able to resubmit it.
> >>>
> >>> In shortcut: With 2 and 3, users will never see the
> browser page "Web
> >>> page is expired" or Keycloak "Error occured. Go back
to the
> >>> application". With 2, there is additional GET request
> needed. With 3,
> >>> the back-button may show the authentication forms, which
> user already
> >>> successfully confirmed, but he won't be able to re-submit
> them. Is it
> >>> bad regarding usability? To me, it looks better than
> showing "Web page
> >>> is expired".
> >>>
> >>> So my preference is 3,2,1. WDYT? Any other options?
> >>>
> >>> Marek
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
9:50 a.m.
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-v...
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?
* 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.
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.
Marek
* Hitting Refresh button also has similar issues when removing the
code from the URL. Hitting refresh on a form POST resends the POSTed
data. Without some kind of code in the URL, the runtime has no idea
if this is a Refresh Button re-POST, or if the browser is POSTing to
the current authenticator.
The way it works now is you have two types of requests which can be
GET or POST.
/authenticate?code={code}
and
/authenticate?code={code}&execution={execution}
The first request corresponds to the Authenticator.authenticate()
method. It basically means you want to display the currrent
authenticator in the flow. The 2nd request means that you processing
a challenge sent by the current Authenticator and corresponds to the
Authenticator.action() method. Without this type of distinction, it
is really hard (impossible) to figure out how to route and process the
request.
On 3/16/17 9:43 AM, Stian Thorgersen wrote:
> We should get rid of the code for sure. Maybe we can add the ID of
> the current step in the flow instead though.
>
> 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
>
> On 16 March 2017 at 12:56, Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> We should be able to detect that with the code in the URL too. So
> the question is, if hidden field has any advantage over keeping
> the code in URL?
>
>
> Thing is, that browsers always treat every POST request as unique
> even if it goes to the same URL. So for example, even if code is
> not in the URL and then the user submits username/password form
> with incorrect password 5 times, then he needs to press browser
> back-button 5 times to return back to initial
> AuthorizationEndpoint request. Even if every POST request had
> same URL without code like
> "http://host/auth/realms/master/authenticate"
> <http://host/auth/realms/master/authenticate> .
>
> Only real advantage I see is, that code in hidden field is maybe
> a bit safer. Not sure if worth the effort, I will try to
> investigate how much effort it is to put the code to the hidden
> field instead of URL.
>
> Marek
>
>
>
> On 16/03/17 11:44, Stian Thorgersen wrote:
>> I like option #3, but what about adding a hidden field on the
>> form that contains the step in the flow. That way we can easily
>> find out if the form is a post for the current step or not. If
>> it's not then we simply ignore the post and return the current
>> step again? That would work for back/forward and refresh.
>>
>> On 14 March 2017 at 23:47, Bill Burke <bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>> Ya, similar to #3, my thought is if you combine a cookie with
>> code-in-url, you have a solution for backbutton and refresh
>> and there's
>> no special headers you have to specify. We used to do #2,
>> but lot of
>> people, specifically jboss.org <http://jboss.org> guys,
>> complained about it.
>>
>>
>> On 3/14/17 4:49 PM, Marek Posolda wrote:
>> > Thanks, that looks similar to my (3) though.
>> >
>> > Besides that I wonder if we should save just the ID of
>> loginSession in
>> > the cookie and the "current-code" keep inside the
loginSession
>> > (infinispan) similarly like it is now?
>> >
>> > I am thinking about the case when potential attacker
>> tricks Keycloak
>> > by manually sending the request, which will just use same
>> code in the
>> > cookie and in the URL. Keycloak will then always treat
>> this request as
>> > valid due the code in the URL and in cookie will always match.
>> > Couldn't that be an issue?
>> >
>> > Marek
>> >
>> > On 14/03/17 13:50, Bill Burke wrote:
>> >> I've got an idea. What about
>> >>
>> >> * keep the code in the URL
>> >>
>> >> * Additionally add a "current-code" cookie
>> >>
>> >> If code in the URL doesn't match the cookie, then
>> redirect to the URL of
>> >> the current-code.
>> >>
>> >>
>> >> On 3/14/17 6:53 AM, Marek Posolda wrote:
>> >>> When working on login sessions, I wonder if we want to
>> improve browser
>> >>> back-button and browser refreshes.
>> >>>
>> >>> In shortcut, I can see 3 basic options:
>> >>>
>> >>> 1) Keep same like now and rely on header
"Cache-Control:
>> no-store,
>> >>> must-revalidate, max-age=0" . This works fine and
users
>> never saw
>> >>> outdated form and never submit outdated form 2 times.
>> However the
>> >>> usability sucks a bit IMO. When you press back-button
>> after POST
>> >>> request, you can see the ugly browser page "Web page
has
>> expired" . And
>> >>> if you press F5 on this, you will see the unfriendly
>> Keycloak error
>> >>> page
>> >>> "Error was occured. Please login again through your
>> application"
>> >>> because
>> >>> of invalid code.
>> >>>
>> >>> 2) Use the pattern with POST followed by the redirect to
>> GET. Since we
>> >>> will have loginSession with the ID in the cookie, the
>> GET request
>> >>> can be
>> >>> sent to the URL without any special query parameter.
>> Something like
>> >>>
>>
"http://localhost:8180/auth/realms/master/login-actions/authenticate
>>
<http://localhost:8180/auth/realms/master/login-actions/authenticate>&q...
>> .
>> >>> This will allow us that in every stage of
>> authentication, user can
>> >>> press
>> >>> back-button and will be always redirected to the first
>> step of the
>> >>> flow.
>> >>> When he refreshes the page, it will re-send just the GET
>> request and
>> >>> always brings him to the current execution.
>> >>>
>> >>> This looks most user-friendly. But there is the issue
>> with performance
>> >>> though. As we will need to followup every POST request
>> with one
>> >>> additional GET request.
>> >>>
>> >>> 3) Don't do anything special regarding back-button or
>> refresh. But in
>> >>> case that page is refreshed AND the post with invalid
>> (already used)
>> >>> code will be re-submitted, we won't display the ugly
>> page "Error was
>> >>> occured.", but we will just redirect to current step
of
>> the flow.
>> >>>
>> >>> Example:
>> >>> a) User was redirected from the application to OIDC
>> >>> AuthorizationEndpoint request. Login page is shown
>> >>> b) User confirmed invalid username and password with
>> POST request.
>> >>> Login
>> >>> form with error page "Invalid password" is shown
>> >>> c) User confirmed valid username and password with POST
>> request. TOTP
>> >>> page is shown.
>> >>> d) User press back-button. Now he will see again the
>> page with
>> >>> username/password form.
>> >>> e) User press F5. The POST request will be re-sent, but
>> it will use
>> >>> previous "code", which is outdated now. So in this
case,
>> we will
>> >>> redirect to the current execution and TOTP form will be
>> shown. No
>> >>> re-submission of username/password form will happen.
>> >>>
>> >>> In case 3, the username/password form will be shown
>> again, but user
>> >>> won't be able to resubmit it.
>> >>>
>> >>> In shortcut: With 2 and 3, users will never see the
>> browser page "Web
>> >>> page is expired" or Keycloak "Error occured. Go
back to the
>> >>> application". With 2, there is additional GET request
>> needed. With 3,
>> >>> the back-button may show the authentication forms, which
>> user already
>> >>> successfully confirmed, but he won't be able to
>> re-submit them. Is it
>> >>> bad regarding usability? To me, it looks better than
>> showing "Web page
>> >>> is expired".
>> >>>
>> >>> So my preference is 3,2,1. WDYT? Any other options?
>> >>>
>> >>> Marek
>> >>>
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> >
>> >
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>
12:37 p.m.
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-v...
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
2:44 a.m.
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(a)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
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
2:45 a.m.
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(a)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(a)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
>
> 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
>
3:22 a.m.
Ok, for now just ignoring the browser limitations and fact that
back/forward doesn't refresh the page automatically for POST requests :)
On 17/03/17 08:45, 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.".
Yeah, that will be nice for UXP.
Or Back button could just go to the start of the flow always.
Regarding UXP, I personally like your previous proposal better. If user
is deep after confirm many authenticator forms and he accidentally
clicks back-button, he will need to re-authenticate in all
authenticators again. Not so great for usability though?
* Resubmitting forms will just display the page above
If we do
any of your previous proposal, user will never see the forms,
which he already submitted? For example if he submitted
username/password and now is on TOTP page, then after click "back" he will be
either on the "Page has expired" or start of the flow. The start of the flow
usually
will be username/password form, but flow started from scratch, so it
won't be resubmitting form, but new submit?
Anyway yes, if some of previous forms is re-submitted, we can display "page is
expired" page.
Marek
* 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(a)redhat.com
<mailto:sthorger@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(a)redhat.com
<mailto:bburke@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-v...
>
<http://stackoverflow.com/questions/9046184/reload-the-site-when-reached-v...
>
> 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
3:40 a.m.
On 17 March 2017 at 09:22, Marek Posolda <mposolda(a)redhat.com> wrote:
Ok, for now just ignoring the browser limitations and fact that
back/forward doesn't refresh the page automatically for POST requests :)
On 17/03/17 08:45, 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.".
Yeah, that will be nice for UXP.
Or Back button could just go to the start of the flow always.
Regarding UXP, I personally like your previous proposal better. If user
is deep after confirm many authenticator forms and he accidentally
clicks back-button, he will need to re-authenticate in all
authenticators again. Not so great for usability though?
True - giving the user the option to choose is probably best.
* Resubmitting forms will just display the page above
If we do any of your previous proposal, user will never see the forms,
which he already submitted? For example if he submitted
username/password and now is on TOTP page, then after click "back" he will be
either on the "Page has expired" or start of the flow. The start of the flow
usually
will be username/password form, but flow started from scratch, so it
won't be resubmitting form, but new submit?
Anyway yes, if some of previous forms is re-submitted, we can display "page is
expired" page.
I'm not quite following. Is it possible to prevent the back buttons from
"re-submitting" forms at all? If so that's ideal as you then don't
get the
ugly message from the browser that the form is expired.
Marek
* 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(a)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(a)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-w
>> hen-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
>>
>
>
5:12 a.m.
On 17/03/17 09:40, Stian Thorgersen wrote:
On 17 March 2017 at 09:22, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Ok, for now just ignoring the browser limitations and fact that
back/forward doesn't refresh the page automatically for POST
requests :)
On 17/03/17 08:45, 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.".
Yeah, that will be nice for UXP.
> Or Back button could just go to the start of the flow always.
Regarding UXP, I personally like your previous proposal better. If user
is deep after confirm many authenticator forms and he accidentally
clicks back-button, he will need to re-authenticate in all
authenticators again. Not so great for usability though?
True - giving the user the option to choose is probably best.
> * Resubmitting forms will just display the page above
If we do any of your previous proposal, user will never see the
forms,
which he already submitted? For example if he submitted
username/password and now is on TOTP page, then after click "back" he will
be
either on the "Page has expired" or start of the flow. The start of the
flow usually
will be username/password form, but flow started from scratch, so it
won't be resubmitting form, but new submit?
Anyway yes, if some of previous forms is re-submitted, we can display "page is
expired" page.
I'm not quite following. Is it possible to prevent the back buttons
from "re-submitting" forms at all? If so that's ideal as you then
don't get the ugly message from the browser that the form is expired.
Yes, as
long as we don't send any "Cache-control" header, then browser
back/forward buttons doesn't resubmit forms and doesn't re-send any
requests.
So follow-up on the example above
1) User successfully authenticated on username/password form and he is
on TOTP page.
2) User press browser "back" button. Now he will see again the
username/password form
3) User will try to re-submit the username/password form OR he press
browser "refresh" button. In both cases, we will show our nice "Page has
expired. To restart the login process click here. To continue the login
process click here."
Are we in agreement that this is ideal user experience?
If yes, we can achieve that quite easily without need of javascript
hacks or hidden form fields though.
Marek
Marek
> * 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(a)redhat.com
> <mailto:sthorger@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(a)redhat.com
> <mailto:bburke@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-v...
>>
<http://stackoverflow.com/questions/9046184/reload-the-site-when-reached-v...
>>
>> 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
>
>
>
9:08 a.m.
On 17 March 2017 at 11:12, Marek Posolda <mposolda(a)redhat.com> wrote:
On 17/03/17 09:40, Stian Thorgersen wrote:
On 17 March 2017 at 09:22, Marek Posolda <mposolda(a)redhat.com> wrote:
> Ok, for now just ignoring the browser limitations and fact that
> back/forward doesn't refresh the page automatically for POST requests :)
>
> On 17/03/17 08:45, 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.".
>
>
> Yeah, that will be nice for UXP.
>
> Or Back button could just go to the start of the flow always.
>
>
> Regarding UXP, I personally like your previous proposal better. If user
> is deep after confirm many authenticator forms and he accidentally
> clicks back-button, he will need to re-authenticate in all
> authenticators again. Not so great for usability though?
>
>
True - giving the user the option to choose is probably best.
> * Resubmitting forms will just display the page above
>
> If we do any of your previous proposal, user will never see the forms,
>
> which he already submitted? For example if he submitted
> username/password and now is on TOTP page, then after click "back" he will
be
> either on the "Page has expired" or start of the flow. The start of the
flow usually
> will be username/password form, but flow started from scratch, so it
> won't be resubmitting form, but new submit?
>
> Anyway yes, if some of previous forms is re-submitted, we can display "page is
expired" page.
>
> I'm not quite following. Is it possible to prevent the back buttons from
"re-submitting" forms at all? If so that's ideal as you then don't get
the
ugly message from the browser that the form is expired.
Yes, as long as we don't send any "Cache-control" header, then browser
back/forward buttons doesn't resubmit forms and doesn't re-send any
requests.
So follow-up on the example above
1) User successfully authenticated on username/password form and he is on
TOTP page.
2) User press browser "back" button. Now he will see again the
username/password form
3) User will try to re-submit the username/password form OR he press
browser "refresh" button. In both cases, we will show our nice "Page has
expired. To restart the login process click here. To continue the login
process click here."
Are we in agreement that this is ideal user experience?
Not quite. Clicking back shouldn't show the form again. It should rather
just show the page expired message and ask user if they want to restart or
continue.
By the way Google's login flows are really nice. Much better than ours.
If yes, we can achieve that quite easily without need of javascript hacks
or hidden form fields though.
Marek
> Marek
>
> * 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(a)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(a)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-w
>>> hen-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
>>>
>>
>>
>
>
9:18 a.m.
The ideal behavior IMO is:
1. Back button always just shows the Page expired message, with option to
continue or restart
2. Refresh always works
3. No redirect required on POSTs
If we can't have all 3 (and it sounds like we can't) I'd probably say #3 is
the lowest priority. I think the option to "restart" the flow is important
as the user in most cases would click back because they've done something
wrong.
So what Bill suggested would work I think:
* Have "Cache-Control: no-store, must-revalidate, max-age=0"
* I guess we need the redirect after a POST to get for the next step
* Have the execution ID in the flow as well as the current execution in the
authentication session. If requested execution ID is not equal to the one
in authentication session display the "Page expired page"
What I don't quite get though is why does the redirect after POST prevent
the "form is expired do you want to resubmit" or whatever the message is?
On 17 March 2017 at 15:08, Stian Thorgersen <sthorger(a)redhat.com> wrote:
On 17 March 2017 at 11:12, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 17/03/17 09:40, Stian Thorgersen wrote:
>
>
>
> On 17 March 2017 at 09:22, Marek Posolda <mposolda(a)redhat.com> wrote:
>
>> Ok, for now just ignoring the browser limitations and fact that
>> back/forward doesn't refresh the page automatically for POST requests :)
>>
>> On 17/03/17 08:45, 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.".
>>
>>
>> Yeah, that will be nice for UXP.
>>
>> Or Back button could just go to the start of the flow always.
>>
>>
>> Regarding UXP, I personally like your previous proposal better. If user
>> is deep after confirm many authenticator forms and he accidentally
>> clicks back-button, he will need to re-authenticate in all
>> authenticators again. Not so great for usability though?
>>
>>
> True - giving the user the option to choose is probably best.
>
>
>> * Resubmitting forms will just display the page above
>>
>> If we do any of your previous proposal, user will never see the forms,
>>
>> which he already submitted? For example if he submitted
>> username/password and now is on TOTP page, then after click "back" he
will be
>> either on the "Page has expired" or start of the flow. The start of the
flow usually
>> will be username/password form, but flow started from scratch, so it
>> won't be resubmitting form, but new submit?
>>
>> Anyway yes, if some of previous forms is re-submitted, we can display "page
is expired" page.
>>
>> I'm not quite following. Is it possible to prevent the back buttons from
> "re-submitting" forms at all? If so that's ideal as you then don't
get the
> ugly message from the browser that the form is expired.
>
> Yes, as long as we don't send any "Cache-control" header, then browser
> back/forward buttons doesn't resubmit forms and doesn't re-send any
> requests.
>
> So follow-up on the example above
> 1) User successfully authenticated on username/password form and he is on
> TOTP page.
> 2) User press browser "back" button. Now he will see again the
> username/password form
> 3) User will try to re-submit the username/password form OR he press
> browser "refresh" button. In both cases, we will show our nice "Page
has
> expired. To restart the login process click here. To continue the login
> process click here."
>
> Are we in agreement that this is ideal user experience?
>
Not quite. Clicking back shouldn't show the form again. It should rather
just show the page expired message and ask user if they want to restart or
continue.
By the way Google's login flows are really nice. Much better than ours.
>
> If yes, we can achieve that quite easily without need of javascript hacks
> or hidden form fields though.
>
> Marek
>
>
>
>> Marek
>>
>> * 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(a)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(a)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-w
>>>> hen-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
>>>>
>>>
>>>
>>
>>
>
>
4:21 a.m.
Hi,
On 17.3.2017 15:18, Stian Thorgersen wrote:
The ideal behavior IMO is:
1. Back button always just shows the Page expired message, with option to
continue or restart
2. Refresh always works
3. No redirect required on POSTs
My fear is how to explain "restart" action (on Expired page) to the
common user to understand it. Login flows are typically part of some
broader user flows started in the client app, users typically do not
perceive them as separate thing.
Also where exactly the user will be pointed after "restart"? Eg. what
"restart" mean when user went over registration form (initiated for
either /register OIDC endpoind or "Register" button of Login page)? Does
this mean that he lost everything he entered into registration form?
This may be really painful for more complicated reg. forms (eg. the one
we have for RHD) if user only used back button to correct something
entered into Reg form.
Other example of one flow one of our users really used:
1. User came to login page from some app
2. Used social login link (eg. Github)
3. Social account was not linked so he got a form to fill in other info
necessary to create new account
4. User used back button to get back to our login page, then used
"Register" button there. He got some error (I'm not sure in which
version of Keycloak, maybe it is resolved now, but we do not want
regression).
How will this work in the behavior you proposed? I believe this kind of
cases (switch between "login" and "register" types of flow) should
work
correctly and show usable Register form without any error page/message
in this case.
If we can't have all 3 (and it sounds like we can't) I'd
probably say #3 is
the lowest priority.
Agree, but there must be maximally one browser redirect after POST (we
complained when one historical implementation used more redirects after
one POST) due to user response time.
Vl.
I think the option to "restart" the flow is important
as the user in most cases would click back because they've done something
wrong.
So what Bill suggested would work I think:
* Have "Cache-Control: no-store, must-revalidate, max-age=0"
* I guess we need the redirect after a POST to get for the next step
* Have the execution ID in the flow as well as the current execution in the
authentication session. If requested execution ID is not equal to the one
in authentication session display the "Page expired page"
What I don't quite get though is why does the redirect after POST prevent
the "form is expired do you want to resubmit" or whatever the message is?
On 17 March 2017 at 15:08, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>
> On 17 March 2017 at 11:12, Marek Posolda <mposolda(a)redhat.com> wrote:
>
>> On 17/03/17 09:40, Stian Thorgersen wrote:
>>
>>
>>
>> On 17 March 2017 at 09:22, Marek Posolda <mposolda(a)redhat.com> wrote:
>>
>>> Ok, for now just ignoring the browser limitations and fact that
>>> back/forward doesn't refresh the page automatically for POST requests :)
>>>
>>> On 17/03/17 08:45, 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.".
>>>
>>>
>>> Yeah, that will be nice for UXP.
>>>
>>> Or Back button could just go to the start of the flow always.
>>>
>>>
>>> Regarding UXP, I personally like your previous proposal better. If user
>>> is deep after confirm many authenticator forms and he accidentally
>>> clicks back-button, he will need to re-authenticate in all
>>> authenticators again. Not so great for usability though?
>>>
>>>
>> True - giving the user the option to choose is probably best.
>>
>>
>>> * Resubmitting forms will just display the page above
>>>
>>> If we do any of your previous proposal, user will never see the forms,
>>>
>>> which he already submitted? For example if he submitted
>>> username/password and now is on TOTP page, then after click "back"
he will be
>>> either on the "Page has expired" or start of the flow. The start of
the flow usually
>>> will be username/password form, but flow started from scratch, so it
>>> won't be resubmitting form, but new submit?
>>>
>>> Anyway yes, if some of previous forms is re-submitted, we can display
"page is expired" page.
>>>
>>> I'm not quite following. Is it possible to prevent the back buttons from
>> "re-submitting" forms at all? If so that's ideal as you then
don't get the
>> ugly message from the browser that the form is expired.
>>
>> Yes, as long as we don't send any "Cache-control" header, then
browser
>> back/forward buttons doesn't resubmit forms and doesn't re-send any
>> requests.
>>
>> So follow-up on the example above
>> 1) User successfully authenticated on username/password form and he is on
>> TOTP page.
>> 2) User press browser "back" button. Now he will see again the
>> username/password form
>> 3) User will try to re-submit the username/password form OR he press
>> browser "refresh" button. In both cases, we will show our nice
"Page has
>> expired. To restart the login process click here. To continue the login
>> process click here."
>>
>> Are we in agreement that this is ideal user experience?
>>
> Not quite. Clicking back shouldn't show the form again. It should rather
> just show the page expired message and ask user if they want to restart or
> continue.
>
> By the way Google's login flows are really nice. Much better than ours.
>
>
>> If yes, we can achieve that quite easily without need of javascript hacks
>> or hidden form fields though.
>>
>> Marek
>>
>>
>>
>>> Marek
>>>
>>> * 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(a)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(a)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-w
>>>>> hen-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
>>>>>
>>>>
>>>
>>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Vlastimil Elias
Principal Software Engineer
Red Hat Developer | Engineering
10:21 a.m.
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(a)redhat.com
<mailto:sthorger@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(a)redhat.com
<mailto:bburke@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-v...
>
<http://stackoverflow.com/questions/9046184/reload-the-site-when-reached-v...
>
> 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
2:54 a.m.
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.
+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.
On 17 March 2017 at 16:21, Bill Burke <bburke(a)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(a)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(a)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-w
>> hen-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
>>
>
>
3:53 a.m.
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(a)redhat.com
<mailto:bburke@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(a)redhat.com
> <mailto:sthorger@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(a)redhat.com
> <mailto:bburke@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-v...
>>
<http://stackoverflow.com/questions/9046184/reload-the-site-when-reached-v...
>>
>> 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
>
>
>
8:35 a.m.
On 20 March 2017 at 09:53, Marek Posolda <mposolda(a)redhat.com> wrote:
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.
Yes, refresh should always just show the same again.
+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?
There could also be changes outside of the login session that we can't
track.
Marek
On 17 March 2017 at 16:21, Bill Burke <bburke(a)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(a)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(a)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-w
>>> hen-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
>>>
>>
>>
>
>
12:04 p.m.
On 3/20/17 3:54 AM, Stian Thorgersen wrote:
Let's go with the "page expired" page then,
The
current behavior is "sticky" in that any back button or page refresh
just renders the current Authenticator in the flow. What sucks with
that is that you have to have a cancel button on each page in order to
restart the flow.
but we wouldn't need it for the refresh page would we? That can
just
re-display the same thing again.
Depends on the implementation of flow processing. This was what I was
trying to explain before.
Remember that refresh re-executes the request to original URL. IF you
set cache control headers, back button will also re-execute the
request. With current impl, code is in the URL, so with a refresh or
back button re-execution the runtime knows the request is a bad one, so
it just finds your current place in the flow and re-renders it. Without
a any code in the URL, the runtime would not know whether your POST was
an old POST triggered by a browser button, or if you were posting to the
correct and current Authenticator.
+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.
You could have a stack and push and pop on it as you went
forwards and
backwards.
On 17 March 2017 at 16:21, Bill Burke <bburke(a)redhat.com
<mailto:bburke@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(a)redhat.com
> <mailto:sthorger@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(a)redhat.com
> <mailto:bburke@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-v...
>>
<http://stackoverflow.com/questions/9046184/reload-the-site-when-reached-v...
>>
>> 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
>
>
>
1:28 a.m.
On 20 March 2017 at 18:04, Bill Burke <bburke(a)redhat.com> wrote:
On 3/20/17 3:54 AM, Stian Thorgersen wrote:
Let's go with the "page expired" page then,
The current behavior is "sticky" in that any back button or page refresh
just renders the current Authenticator in the flow. What sucks with that
is that you have to have a cancel button on each page in order to restart
the flow.
but we wouldn't need it for the refresh page would we? That can just
re-display the same thing again.
Depends on the implementation of flow processing. This was what I was
trying to explain before.
Remember that refresh re-executes the request to original URL. IF you set
cache control headers, back button will also re-execute the request. With
current impl, code is in the URL, so with a refresh or back button
re-execution the runtime knows the request is a bad one, so it just finds
your current place in the flow and re-renders it. Without a any code in
the URL, the runtime would not know whether your POST was an old POST
triggered by a browser button, or if you were posting to the correct and
current Authenticator.
So we have to have something in the URL that's clear to me now. We should
just add a step number or something rather than the code we have now (the
codes are expensive to create).
+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.
You could have a stack and push and pop on it as you went forwards and
backwards.
That would only work if there are no changes outside authentication
session, but we already have things like required actions that change the
user directly. We would also need some option on authenticators and
required actions whether or not they can be replayed or something like
that. Sounds complicated...
On 17 March 2017 at 16:21, Bill Burke <bburke(a)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(a)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(a)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-w
>>> hen-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
>>>
>>
>>
>
>
8:13 a.m.
On 3/21/17 2:28 AM, Stian Thorgersen wrote:
On 20 March 2017 at 18:04, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 3/20/17 3:54 AM, Stian Thorgersen wrote:
> Let's go with the "page expired" page then,
The current behavior is "sticky" in that any back button or page
refresh just renders the current Authenticator in the flow. What
sucks with that is that you have to have a cancel button on each
page in order to restart the flow.
> but we wouldn't need it for the refresh page would we? That can
> just re-display the same thing again.
>
Depends on the implementation of flow processing. This was what I
was trying to explain before.
Remember that refresh re-executes the request to original URL. IF
you set cache control headers, back button will also re-execute
the request. With current impl, code is in the URL, so with a
refresh or back button re-execution the runtime knows the request
is a bad one, so it just finds your current place in the flow and
re-renders it. Without a any code in the URL, the runtime would
not know whether your POST was an old POST triggered by a browser
button, or if you were posting to the correct and current
Authenticator.
So we have to have something in the URL that's clear to me now. We
should just add a step number or something rather than the code we
have now (the codes are expensive to create).
To detect refresh button, you'd need to know the previous action too I
think.
We have two things right now:
* code - this corresponds to the client session code
* execution-code - this is the Authenticator's component id. This is
only in the URL if you are executing an action on the Authenticator,
i.e. posting username/password.
I think we should keep generating the code + hash, but only do it when
the login state transitions, i.e. from
authentication->required-actions->code to token->logged in ...AND...make
sure that code != code-to-token code :). We should also make sure that
you cannot go backwards in a flow. i.e., once Authentication is
successful, you can't go back to the Authentication state. Once
code-to-token happens, you can go back to required actions, etc.
Just to be safe, we could store the flow code both in a cookie and in
the url which would guard against CSRF attacks, although I don't know if
it would be possible to do a CSRF attack in an authentication flow or
what it would buy the attacker.
> +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.
You could have a stack and push and pop on it as you went forwards
and backwards.
That would only work if there are no changes outside authentication
session, but we already have things like required actions that change
the user directly. We would also need some option on authenticators
and required actions whether or not they can be replayed or something
like that. Sounds complicated...
Yeah, I don't want to implement it. I just worry we'd get something
wrong and create a security hole.
Bill
8:50 a.m.
On 21/03/17 14:13, Bill Burke wrote:
On 3/21/17 2:28 AM, Stian Thorgersen wrote:
>
>
> On 20 March 2017 at 18:04, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
>
>
> On 3/20/17 3:54 AM, Stian Thorgersen wrote:
>> Let's go with the "page expired" page then,
> The current behavior is "sticky" in that any back button or page
> refresh just renders the current Authenticator in the flow. What
> sucks with that is that you have to have a cancel button on each
> page in order to restart the flow.
>
>
>> but we wouldn't need it for the refresh page would we? That can
>> just re-display the same thing again.
>>
>
> Depends on the implementation of flow processing. This was what
> I was trying to explain before.
>
> Remember that refresh re-executes the request to original URL.
> IF you set cache control headers, back button will also
> re-execute the request. With current impl, code is in the URL,
> so with a refresh or back button re-execution the runtime knows
> the request is a bad one, so it just finds your current place in
> the flow and re-renders it. Without a any code in the URL, the
> runtime would not know whether your POST was an old POST
> triggered by a browser button, or if you were posting to the
> correct and current Authenticator.
>
>
> So we have to have something in the URL that's clear to me now. We
> should just add a step number or something rather than the code we
> have now (the codes are expensive to create).
To detect refresh button, you'd need to know the previous action too I
think.
We have two things right now:
* code - this corresponds to the client session code
* execution-code - this is the Authenticator's component id. This is
only in the URL if you are executing an action on the Authenticator,
i.e. posting username/password.
I think we should keep generating the code + hash, but only do it when
the login state transitions, i.e. from
authentication->required-actions->code to token->logged in
...AND...make sure that code != code-to-token code :). We should also
make sure that you cannot go backwards in a flow. i.e., once
Authentication is successful, you can't go back to the Authentication
state. Once code-to-token happens, you can go back to required
actions, etc.
Just to be safe, we could store the flow code both in a cookie and in
the url which would guard against CSRF attacks, although I don't know
if it would be possible to do a CSRF attack in an authentication flow
or what it would buy the attacker.
What I have right now in my cross-dc prototype
branch is, that "code" is
used just for the action requests. Code is still single use and it's
compared with the code from login session (same like we have in master).
So every action is also single use and cannot be replayed.
I have the "execution" parameter used in both action and non-action
requests. That's better as refreshing page doesn't need to change
execution in the URL and back-button will always turn you one
authenticator back and it shows the "page expired" page if execution
doesn't match the last used execution from login session.
Marek
>
>
>
>> +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.
> You could have a stack and push and pop on it as you went
> forwards and backwards.
>
>
> That would only work if there are no changes outside authentication
> session, but we already have things like required actions that change
> the user directly. We would also need some option on authenticators
> and required actions whether or not they can be replayed or something
> like that. Sounds complicated...
Yeah, I don't want to implement it. I just worry we'd get something
wrong and create a security hole.
Bill
8:56 a.m.
On 3/21/17 9:50 AM, Marek Posolda wrote:
On 21/03/17 14:13, Bill Burke wrote:
>
>
>
> On 3/21/17 2:28 AM, Stian Thorgersen wrote:
>>
>>
>> On 20 March 2017 at 18:04, Bill Burke <bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>>
>>
>> On 3/20/17 3:54 AM, Stian Thorgersen wrote:
>>> Let's go with the "page expired" page then,
>> The current behavior is "sticky" in that any back button or page
>> refresh just renders the current Authenticator in the flow.
>> What sucks with that is that you have to have a cancel button on
>> each page in order to restart the flow.
>>
>>
>>> but we wouldn't need it for the refresh page would we? That can
>>> just re-display the same thing again.
>>>
>>
>> Depends on the implementation of flow processing. This was what
>> I was trying to explain before.
>>
>> Remember that refresh re-executes the request to original URL.
>> IF you set cache control headers, back button will also
>> re-execute the request. With current impl, code is in the URL,
>> so with a refresh or back button re-execution the runtime knows
>> the request is a bad one, so it just finds your current place in
>> the flow and re-renders it. Without a any code in the URL, the
>> runtime would not know whether your POST was an old POST
>> triggered by a browser button, or if you were posting to the
>> correct and current Authenticator.
>>
>>
>> So we have to have something in the URL that's clear to me now. We
>> should just add a step number or something rather than the code we
>> have now (the codes are expensive to create).
>
> To detect refresh button, you'd need to know the previous action too
> I think.
>
> We have two things right now:
>
> * code - this corresponds to the client session code
> * execution-code - this is the Authenticator's component id. This is
> only in the URL if you are executing an action on the Authenticator,
> i.e. posting username/password.
>
> I think we should keep generating the code + hash, but only do it
> when the login state transitions, i.e. from
> authentication->required-actions->code to token->logged in
> ...AND...make sure that code != code-to-token code :). We should
> also make sure that you cannot go backwards in a flow. i.e., once
> Authentication is successful, you can't go back to the Authentication
> state. Once code-to-token happens, you can go back to required
> actions, etc.
>
> Just to be safe, we could store the flow code both in a cookie and in
> the url which would guard against CSRF attacks, although I don't know
> if it would be possible to do a CSRF attack in an authentication flow
> or what it would buy the attacker.
What I have right now in my cross-dc prototype branch is, that "code"
is used just for the action requests. Code is still single use and
it's compared with the code from login session (same like we have in
master). So every action is also single use and cannot be replayed.
I have the "execution" parameter used in both action and non-action
requests. That's better as refreshing page doesn't need to change
execution in the URL and back-button will always turn you one
authenticator back and it shows the "page expired" page if execution
doesn't match the last used execution from login session.
Ah, cool! I hate it
I didn't find that solution when implementing this
stuff.
Bill
9:33 a.m.
On 16/03/17 14:43, Stian Thorgersen wrote:
We should get rid of the code for sure. Maybe we can add the ID of
the
current step in the flow instead though.
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.".
Yeah, that will be nice for UXP.
Problem is, that back/forward button doesn't automatically refresh the
page. So we will need some javascript tricks though. Maybe something
like this:
http://stackoverflow.com/questions/9046184/reload-the-site-when-reached-v...
Or Back button could just go to the start of the flow always.
That's possible without javascript if you do POST with Redirect.
Basically what I meant with #2 .
Regarding UXP, I personally like your previous proposal better. If user
is deep after confirm many authenticator forms and he accidentally
clicks back-button, he will need to re-authenticate in all
authenticators again. Not so great for usability though?
* Resubmitting forms will just display the page above
If we do
any of your previous proposal, user will never see the forms,
which he already submitted? For example if he submitted
username/password and now is on TOTP page, then after click "back" he is
either on the "Page has expired" or start of the flow. Which usually
will be username/password form, but flow started from scratch, so it
won't be resubmitting form, but new submit.
Marek
* 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
On 16 March 2017 at 12:56, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
We should be able to detect that with the code in the URL too. So
the question is, if hidden field has any advantage over keeping
the code in URL?
Thing is, that browsers always treat every POST request as unique
even if it goes to the same URL. So for example, even if code is
not in the URL and then the user submits username/password form
with incorrect password 5 times, then he needs to press browser
back-button 5 times to return back to initial
AuthorizationEndpoint request. Even if every POST request had same
URL without code like
"http://host/auth/realms/master/authenticate"
<http://host/auth/realms/master/authenticate> .
Only real advantage I see is, that code in hidden field is maybe a
bit safer. Not sure if worth the effort, I will try to investigate
how much effort it is to put the code to the hidden field instead
of URL.
Marek
On 16/03/17 11:44, Stian Thorgersen wrote:
> I like option #3, but what about adding a hidden field on the
> form that contains the step in the flow. That way we can easily
> find out if the form is a post for the current step or not. If
> it's not then we simply ignore the post and return the current
> step again? That would work for back/forward and refresh.
>
> On 14 March 2017 at 23:47, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> Ya, similar to #3, my thought is if you combine a cookie with
> code-in-url, you have a solution for backbutton and refresh
> and there's
> no special headers you have to specify. We used to do #2, but
> lot of
> people, specifically jboss.org <http://jboss.org> guys,
> complained about it.
>
>
> On 3/14/17 4:49 PM, Marek Posolda wrote:
> > Thanks, that looks similar to my (3) though.
> >
> > Besides that I wonder if we should save just the ID of
> loginSession in
> > the cookie and the "current-code" keep inside the
loginSession
> > (infinispan) similarly like it is now?
> >
> > I am thinking about the case when potential attacker tricks
> Keycloak
> > by manually sending the request, which will just use same
> code in the
> > cookie and in the URL. Keycloak will then always treat this
> request as
> > valid due the code in the URL and in cookie will always match.
> > Couldn't that be an issue?
> >
> > Marek
> >
> > On 14/03/17 13:50, Bill Burke wrote:
> >> I've got an idea. What about
> >>
> >> * keep the code in the URL
> >>
> >> * Additionally add a "current-code" cookie
> >>
> >> If code in the URL doesn't match the cookie, then redirect
> to the URL of
> >> the current-code.
> >>
> >>
> >> On 3/14/17 6:53 AM, Marek Posolda wrote:
> >>> When working on login sessions, I wonder if we want to
> improve browser
> >>> back-button and browser refreshes.
> >>>
> >>> In shortcut, I can see 3 basic options:
> >>>
> >>> 1) Keep same like now and rely on header "Cache-Control:
> no-store,
> >>> must-revalidate, max-age=0" . This works fine and users
> never saw
> >>> outdated form and never submit outdated form 2 times.
> However the
> >>> usability sucks a bit IMO. When you press back-button
> after POST
> >>> request, you can see the ugly browser page "Web page has
> expired" . And
> >>> if you press F5 on this, you will see the unfriendly
> Keycloak error
> >>> page
> >>> "Error was occured. Please login again through your
> application"
> >>> because
> >>> of invalid code.
> >>>
> >>> 2) Use the pattern with POST followed by the redirect to
> GET. Since we
> >>> will have loginSession with the ID in the cookie, the GET
> request
> >>> can be
> >>> sent to the URL without any special query parameter.
> Something like
> >>>
> "http://localhost:8180/auth/realms/master/login-actions/authenticate
>
<http://localhost:8180/auth/realms/master/login-actions/authenticate>&q...
> .
> >>> This will allow us that in every stage of authentication,
> user can
> >>> press
> >>> back-button and will be always redirected to the first
> step of the
> >>> flow.
> >>> When he refreshes the page, it will re-send just the GET
> request and
> >>> always brings him to the current execution.
> >>>
> >>> This looks most user-friendly. But there is the issue
> with performance
> >>> though. As we will need to followup every POST request
> with one
> >>> additional GET request.
> >>>
> >>> 3) Don't do anything special regarding back-button or
> refresh. But in
> >>> case that page is refreshed AND the post with invalid
> (already used)
> >>> code will be re-submitted, we won't display the ugly page
> "Error was
> >>> occured.", but we will just redirect to current step of
> the flow.
> >>>
> >>> Example:
> >>> a) User was redirected from the application to OIDC
> >>> AuthorizationEndpoint request. Login page is shown
> >>> b) User confirmed invalid username and password with POST
> request.
> >>> Login
> >>> form with error page "Invalid password" is shown
> >>> c) User confirmed valid username and password with POST
> request. TOTP
> >>> page is shown.
> >>> d) User press back-button. Now he will see again the page
> with
> >>> username/password form.
> >>> e) User press F5. The POST request will be re-sent, but
> it will use
> >>> previous "code", which is outdated now. So in this
case,
> we will
> >>> redirect to the current execution and TOTP form will be
> shown. No
> >>> re-submission of username/password form will happen.
> >>>
> >>> In case 3, the username/password form will be shown
> again, but user
> >>> won't be able to resubmit it.
> >>>
> >>> In shortcut: With 2 and 3, users will never see the
> browser page "Web
> >>> page is expired" or Keycloak "Error occured. Go back
to the
> >>> application". With 2, there is additional GET request
> needed. With 3,
> >>> the back-button may show the authentication forms, which
> user already
> >>> successfully confirmed, but he won't be able to re-submit
> them. Is it
> >>> bad regarding usability? To me, it looks better than
> showing "Web page
> >>> is expired".
> >>>
> >>> So my preference is 3,2,1. WDYT? Any other options?
> >>>
> >>> Marek
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
2838
days inactive
2845
days old
27 comments
4 participants
participants (4)
-
Bill Burke -
Marek Posolda -
Stian Thorgersen -
Vlastimil Elias