[keycloak-dev] per-client authentication flows

[Marek Posolda]

I wonder if it's related to support for OIDC "acr" parameter 
(authentication levels)? I can imagine that we map different values of 
"acr" parameter to different authentication flows.

Then in adapter configuration keycloak.json, you can use something like 
"default_acr" . If it's set, client adapter will send initial OIDC 
request with this "acr" value and hence will use specific authentication 
flow corresponding to that "acr" .

This has an advantage, that single client can possibly use different 
authentication flows. As client will have possibility to override 
default_acr based on the usecase. For example bank application can 
require just simple username+password login to see the account details, 
but may require stronger authentication level (OTP) for further actions 
like sending payment to different account.

Marek

On 18/01/18 17:33, Bill Burke wrote:
> Makes sense for both direct grant and browser flow.  Please reread the
> OP.   I'll try to summarize differently.  In Keycoak, using OAuth
> authorization code grant protocol means that the 'Browser Flow" will
> be invoked.  *All* OSIN clients use the code grant and clients are
> configured individually whether a challenge based protocol should be
> used or not.  It is a Keycloak requirement to remain backward
> compatible so Keycloak can just be turned on with no changes.  What it
> boils down to is cmd-line clients vs. browser clients.   I would hate
> to add an architectural feature just to implement something OSIN
> specific, but I think this would be useful beyond OSIN.  I'm thinking
> of a purely text-based authenticaiton flow for cmd line clients.
> Something I've been thinking about since this summer. Originally I was
> thinking that we'd have to trigger a flow based on the OIDC 'display'
> parameter, but now I'm thinking that per-client-flows is a more
> elegant solution.
>
> On Thu, Jan 18, 2018 at 10:44 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
>> Definitively makes sense for the 'Direct Grant Flow'.
>>
>> Did you also think about it for the 'Browser Flow'? That doesn't make sense
>> to me as I don't think the client should have any control on the SSO flow.
>>
>>
>> On 17 January 2018 at 20:37, Bill Burke <bburke at redhat.com> wrote:
>>> TLDR;  Per client authentication flows?  Client can be configured to
>>> override realm authentication flows.
>>>
>>> Background:
>>>
>>> I'm specing out how we will replace OSIN (openshift oauth server) with
>>> Keycloak.  One issue is that each oauth client in OSIN can specify the
>>> authentication flow they want.  Non-browser clients like the 'oc' cmd
>>> line tool want a 401, challenge-based protocol...Web console,
>>> obviously wants HTML.  They All OSIN clients use the OAuth
>>> auth-code-grant irregardless if they are non-brwoser or browser
>>> clients.  Keycloak assumes this oauth grant type is browser based and
>>> expects non-browser clients to use Resource Credentials grant or
>>> client credential grant.  OSIN does not support this and we (keycloak)
>>> have to be backward compatible.
>>>
>>> Solution:
>>>
>>> I think it would be pretty simple to add the ability to override
>>> authentication flows per client.  I don't think this would be a
>>> one-off for OSIN as we could use it to implement other non-browser
>>> input protocols.  For example, I wanted to be able to have a
>>> text-based auth flow for command line logins.  I think this could be a
>>> way to implement that.
>>> --
>>> Bill Burke
>>> Red Hat
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>