[keycloak-dev] per-client authentication flows

[Bill Burke]

On Fri, Jan 19, 2018 at 9:25 AM, Marek Posolda <mposolda at redhat.com> wrote:
> On 19/01/18 14:21, Bill Burke wrote:
>>
>> That's "step-up" authentication right?  Or is acr something different.
>> Yeah, I think per-client flow could be an alternative way to implement
>> it.  Don't know if its a better way, but it is an alternative.
>
> Yes, it is about step-up authentication. I hope this can indirectly help
> with per-client flows, but not 100% sure.
>
> One possible issue with different "acr" values for different authentication
> flows is the fact, that with the step-up authentication you may not want to
> repeat some authenticators, which were already successful for this
> userSession.
>
> For example you have flow1 with password-only and flow2 with password+OTP.
> When application is already authenticated with level1 (username+pasword),
> but now wants level2, you don't want to type password again if you already
> authenticated through password before. So authentication flow should ask
> just for OTP in this case. But executionId of usernamePassword authenticator
> will be different in both authentication flows.
>
> However maybe this can be addressed with the "amr" claim, which can be saved
> in IDToken (This is per OIDC specs
> http://openid.net/specs/openid-connect-core-1_0.html#IDToken) and maybe also
> userSession. It contains the String representations of used authentication
> methods. Hopefully we can use this to track that username+password
> authenticator was already used in this userSession in different
> authentication flow and hence skip the usernamePassword authenticator when
> moving from level1 to level2.
>

There's a few different approaches we can take that Stian and I
discussed in a F2F last year.  But I think per-client flows is useful
irregardless if we use them to implement step-up auth.  Right?

>>
>> BTW, different topic, one thing I'm worried about though is, are auth
>> flows now dependent on cookies?  We may have to optionally allow query
>> params to specify the auth session rather than a cookie.  For
>> non-browser grants, we'll have logins spanning multiple requests
>> (think SPNEGO/Kerberos) and they may not support cookies.
>
> Yes, I see. Someone already asked on keycloak-user mailing list about the
> alternative of using query parameter instead of the cookie. I think it was
> similar usecase like Openshift. Authorization code OIDC flow was needed in
> some non-browser authentication scenario.

I think I remember another value of using a query param was that you
could continue an auth session in a completely different browser.

How do you think to implement?  If a cookie is set, use that value for
auth session, if not allow it to be specified as query parameter?
I'll look into this and discuss more later in separate thread.



-- 
Bill Burke
Red Hat