[keycloak-dev] per-client authentication flows
mposolda at redhat.com
Fri Jan 19 01:08:43 EST 2018
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.
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.
>>> 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.
>>> 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
More information about the keycloak-dev