[keycloak-dev] Alternative flows on Browser refresh

Marek Posolda mposolda at redhat.com
Fri Nov 24 09:03:39 EST 2017


I am not sure when exactly we want to retry the alternative 
authenticators like kerberos or X509? The possibilities are:

1) When user opens the secured application URL (which will redirect him 
to Keycloak initial OIDC/SAML Authorization endpoint)
2) When user press browser "refresh" on username/password screen
3) When user press browser "refresh" on TOTP (or any possible additional 
authenticator screen after username/password was already SUCCESS)

I wouldn't do 3. It would be likely complicated to implement when 
thinking various corner cases (browser back/refresh/forward buttons, 
authenticator state etc). And usability also won't help much IMO...

1 will be easier to implement. Is it sufficient or do we want also 2? 
The 2 is possible but maybe harder to do, we will need to track whether 
there was some successful action OR whether some authenticator is 
already in state SUCCESS.

Marek


Dne 23.11.2017 v 12:15 Bruno Oliveira napsal(a):
> Good morning,
>
> For alternative flows like X509 browser, if something goes wrong
> it will fall back to username/password form, as we already know.
> But the flow is not executed again until the browser is closed.
>
> Based on what Stian commented[1], seems like the same applies to
> Kerberos. To fix this, we need to change the way how it works today,
> by going through the list of all alternative flows on refresh,
> executing them again.
>
> Does it make sense? Should we have Jira as "enhancement" for this?
>
> [1] - https://issues.jboss.org/browse/KEYCLOAK-5466
>



More information about the keycloak-dev mailing list