[keycloak-dev] Implicit and hybrid flow

Fri Nov 27 05:52:43 EST 2015

On 27 November 2015 at 10:53, Marek Posolda <mposolda at redhat.com> wrote:

> On 27/11/15 09:44, Stian Thorgersen wrote:
>
>
>
> On 27 November 2015 at 09:28, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I've sent PR https://github.com/keycloak/keycloak/pull/1885 with initial
>> support for implicit flow and hybrid flow.
>>
>> Some summary:
>> - Added switches on client in admin console to enable/disable standard
>> flow, implicit flow, direct grant flow and service accounts. Removed
>> "direct grants only" switch (Disable both standard and implicit defacto
>> means enabling of previous "direct grants only")
>>
>
> Is direct grant and implicit disabled by default?
>
> Implicit is disabled, but direct grant is enabled by default. This is just
> for backwards compatibility, as in 1.6, we have direct grant defacto
> enabled for all clients. If we want to have it disabled by default, we
> should add big note to migration docs. Or we can have it enabled for all
> clients migrated from previous version, but keep the switch "off" in admin
> console for new clients?
>

On for old, off for new works for me.

>
> At least, we have people, who wants to login into admin REST API by
> default (without need to go to admin-console UI first and enable direct
> grant for some client), so I guess this possibility should be still kept.
>

In reality they should not be using the admin console client to do so. They
should create a separate client for it I think. We need to sort out some
sort of bootstrapping for it though. Or maybe we have a admin-cli client?

>
>
>
>>
>>
>> - Added more proper support for "response_type" parameter. This is about
>> _what_ is sent in response from AuthorizationEndpoint to client
>> application. According to specs, possible values are "code", "id_token",
>> "token" and some combination of them. See [1] . Until now, we supported
>> just value "code" (standard AuthorizationCode flow). According to specs,
>> implicit flow is about "token" and "id_token". Hybrid flow is about code
>> + some of the tokens.
>>
>
> What do we do about backwards compatibility? It's seems we're breaking the
> spec currently by including both id_token and refresh_token even though
> response_type is just code.
>
> No, we include just what is requested in response_type parameter. If it's
> just "code", we will send just "code" (as it always was), so the behaviour
> for response_type=code is unchanged and completely backwards compatible. If
> it's for example "code id_token" we send code + id_token . Nothing more.
> Using of any of tokens parameters also requires implicit flow enabled for
> the client. Hybrid flow is allowed just if both "standard" and "implicit"
> are enabled for the client.
>

I was thinking the access token request had a parameter to request refresh
token, but it doesn't. So you're right.

>
>
>
>>
>> In addition to specs, I've added also support for "refresh_token" . So
>> if you use "response_type=token%20id_token%20refresh_token", the
>> AuthorizationEndpoint will send all 3 tokens. The OIDC specs doesn't
>> support sending refreshToken in implicit flow. However in Keycloak case,
>> we are using access tokens with very short lifespan by default (1
>> minute). Having just accessToken and idToken would make the implicit
>> flow quite unusable, as application will need to re-login each 1 minute.
>> For example Google doesn't support sending refreshToken in implicit
>> flow, however it makes much more sense for them as their access token is
>> valid for 60 minutes. This is even longer than our refresh token (30
>> minutes by default). WDYT about support for refresh token?
>>
>
> We shouldn't send refresh token in fragment aka support it in implicit.
> Maybe we should have different timeouts instead of sending refresh token?
>
> Ok, working on it as we discussed privately.
>
>
>
>>
>>
>> - Added support for "response_mode" parameter. This specifies _how_ are
>> OIDC parameters (code, state, ... ) sent from AuthorizationEndpoint to
>> client. More details in specs [2]. Valid values are:
>> -- query - Params sent in query string (
>> http://localhost?code=foo&state=bar ). We always supported this
>> -- fragment - Params sent in fragment (
>> http://localhost#code=foo&state=bar ). This is needed for implicit and
>> hybrid flow support. Specs doesn't allow to sent tokens in query string.
>> -- form_post - Params are sent in body of POST method. There is separate
>> specs for this [3] . I've added just server-side support for this. It
>> may be interesting to add support on our server adapters, as IMO it's a
>> bit safer alternative when code+state are sent in POST body instead of
>> in GET method query string. But I guess this is not big priority?
>>
>
> Maybe just JIRA it for 1.8
>
> https://issues.jboss.org/browse/KEYCLOAK-2153
>
>
>
>>
>>
>> - keycloak.js changes - I've added 2 new init config options. Option
>> "response_mode" with possible values "query" and "fragment" (see above
>> what they mean). Second is option "flow" with possible values:
>> a) "standard" - will use response_type=code . This is what we always
>> supported
>> b) "implicit" - will use response_type=id_token%20token%20refresh_token
>> (So sending all 3 tokens)
>> c) "hybrid" - will use
>> response_type=code%20id_token%20token%20refresh_token (Sending code and
>> all 3 tokens). Not sure if we really need to support "hybrid" option.
>> Specs provides hybrid flow for semi-confidential application, which can
>> decide if they need refreshToken (in that case app must send request to
>> exchange code) or if they don't need refresh token and access+id tokens
>> are sufficient. But in Keycloak, since we support sending refresh_token
>> directly in implicit flow (see above), this flow is not very useful for
>> us.
>>
>
> Actually sounds like hybrid is better if we want to have refresh token in
> keycloak.js. With hybrid you don't need the first request to get access
> token, but at the same time refresh token isn't sent in the fragment.
>
> Yes, as long as we want implicit flow exactly according to specs (so no
> refresh_token in fragment) then hybrid is useful as the code needs to be
> used to exchange for refresh_token .
>
>
>
>>
>> Default values for options are response_type=code and
>> response_mode=fragment. So we still use "code" and standard flow by
>> default, however we sent code+state in fragment now. This is better and
>> safer than query string. In qery string, the code+state were always sent
>> in request to the client application. This is not needed, keycloak.js
>> needs them available just on browser side. With fragment, code and state
>> are not sent to client application, so it's one less possibility how
>> they can be compromised.
>>
>> - Added support for "nonce" check in keycloak.js. It's useful for some
>> kind of attacks and specs wants it for implicit flow.
>>
>> Possible pending work:
>> - Fix integration-arquillian as PR is failing now
>>
>> - Possibly add server-side support for "at_hash" to IDToken ? Not sure
>> if at_hash support has any real advantages for us, however specs
>> requires that and even Google supports it.
>>
>> - Add docs and tests. Not sure about adding separate example? Until now,
>> I've tested with existing js-console example and added support here for
>> easily set init parameters to keycloak.init, so people can use different
>> flow or responseMode here.
>>
>
> Docs is enough. I don't think there's any need for examples.
>
>
>>
>> WDYT?
>>
>> Marek
>>
>> [1]
>>
>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations
>>
>> [2]
>>
>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes
>>
>> [3] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151127/d5593e04/attachment-0001.html 