[keycloak-dev] Implicit and hybrid flow

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") - 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. 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? - 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? - 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. 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. WDYT? Marek [1] http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combina... [2] http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Respons... [3] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html