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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >

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.

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.

On Fri, Jan 19, 2018 at 1:08 AM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > 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(a)redhat.com&gt; >> 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(a)redhat.com&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>

On Fri, Jan 19, 2018 at 9:25 AM, Marek Posolda <mposolda(a)redhat.com&gt; 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.

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 typically is. 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 flows. 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 22 January 2018 at 16:17, Bill Burke <bburke(a)redhat.com&gt; wrote: > On Mon, Jan 22, 2018 at 2:48 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: >> 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 >> typically is. >> >> 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 >> flows. >> >> 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? >> > I want to reorganize auth flows a bit so that we can catagorize them > and provide a plugin mechanism so the admin console can dynamically > show which flows can be configured (browser, direct grant, ecp, > etc..). There's a lot to be done here, but probably just putting in > enough at the moment to get the OSIN replacement going. > >> Another thing is the user-agent always controlled by the client? Or > could a >> single client have different user-agents. >> > They don't really have that concept. There's a client config variable > "respondWithChallenges". When set, server responds with 401 > challenges. > I was also wondering if other (non OSIN) clients would want to use more than one flow, but probably not. > > > > -- > Bill Burke > Red Hat > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I'll add a jira...but there's some things to think about for it. One of the things on my plate is Client Scope support ala oauth scopes. Was hoping to retire/replace client templates with client scopes and not sure if flow overrides fit there if a client is composed of multiple scopes. On Wed, Jan 24, 2018 at 6:07 AM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > Bill, I've added few minor comments to your PR. > > Does it makes sense to support authentication flows per clientTemplate too? > Or is it just unnecessary complication? I wonder if it's similar to newly > added themeSelector and thinking if we can have fallback chain like: client > -> clientTemplate -> realm . > > Marek > > > > On 22/01/18 19:21, Stian Thorgersen wrote: >> >> On 22 January 2018 at 16:17, Bill Burke <bburke(a)redhat.com&gt; wrote: >> >>> On Mon, Jan 22, 2018 at 2:48 AM, Stian Thorgersen <sthorger(a)redhat.com > >>> wrote: >>>> >>>> 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 >>>> typically is. >>>> >>>> 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 >>>> >>>> flows. >>>> >>>> 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? >>>> >>> I want to reorganize auth flows a bit so that we can catagorize them >>> and provide a plugin mechanism so the admin console can dynamically >>> show which flows can be configured (browser, direct grant, ecp, >>> etc..). There's a lot to be done here, but probably just putting in >>> enough at the moment to get the OSIN replacement going. >>> >>>> Another thing is the user-agent always controlled by the client? Or >>> >>> could a >>>> >>>> single client have different user-agents. >>>> >>> They don't really have that concept. There's a client config variable >>> "respondWithChallenges". When set, server responds with 401 >>> challenges. >>> >> I was also wondering if other (non OSIN) clients would want to use more >> than one flow, but probably not. >> >> >>> >>> >>> >>> -- >>> Bill Burke >>> Red Hat >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- Bill Burke Red Hat