[keycloak-dev] per-client authentication flows
sthorger at redhat.com
Mon Jan 22 02:48:04 EST 2018
I missed the part about code grant flow being used regardless. Of course
the spec doesn't even mandate the user-agent is a web browser, just says it
I think acr/display (or some other query parameter) vs a different flow
boils down to usability. Basically is it simpler to have one "dynamic" flow
or is it simpler to just have separate flows. I think in most cases you're
right and it will probably be cleaner and simpler to simply have different
Did you think about including this new flow OOTB? Is it OSIN specific or is
it a generic non-web version of the regular web based flow?
Another thing is the user-agent always controlled by the client? Or could a
single client have different user-agents.
On 18 January 2018 at 17:33, Bill Burke <bburke at redhat.com> 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>
> > Definitively makes sense for the 'Direct Grant Flow'.
> > Did you also think about it for the 'Browser Flow'? That doesn't make
> > to me as I don't think the client should have any control on the SSO
> > 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
> Bill Burke
> Red Hat
More information about the keycloak-dev