We'd probably also need to either use async servlet requests or websockets
as well. Otherwise we could run out of available connections.
On 14 January 2016 at 15:17, Bill Burke <bburke(a)redhat.com> wrote:
To make this work, we would need a way to plug in a REST service
that
could receive input from the mobile device. It would search through client
sessions of the user to see which one was waiting for a mobile
authentication. Then change the state of the client session. The browser
session could poll the client session until a flag was set.
On 1/14/2016 2:53 AM, Stian Thorgersen wrote:
Do we support async authenticators? I'm thinking about something like:
* User logs in on desktop with username/password
* As two factor auth we send a notification to a mobile phone app
* When user clicks ok on the mobile phone app the login on the desktop
continues
This type of authentication is used by banks in Norway, which is very nice
as you don't need to manually write a code.
On 13 January 2016 at 22:34, Bill Burke <bburke(a)redhat.com> wrote:
> I'm changing browse refresh behavior again.
>
> I've removed all the extra redirects, so now, you can end up being on
> the OTP page, but the URL is the one posted to by password page. Refresh
> page will repost the password, keycloak will see that the current action
> is not the same, and just ask the flow to put the browser in the right
> state. Similarly with required actions.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red
Hathttp://bill.burkecentral.com