[keycloak-dev] Implicit and hybrid flow

[Bill Burke]

On 11/27/2015 3:44 AM, Stian Thorgersen wrote:
>
>
> On 27 November 2015 at 09:28, Marek Posolda <mposolda at redhat.com
> <mailto: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?
>
>
>
>     - 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.
>
>
>     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?
>

Read this:

https://tools.ietf.org/html/rfc6819

And make sure you aren't opening yourself up to any additional attacks.


>
>
>     - 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?
>

POST probably works exactly like SAML POST Binding.  Its a nice trick.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com