On 27/11/15 09:44, Stian Thorgersen wrote:

On 27 November 2015 at 09:28, Marek Posolda <mposolda@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?

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.

 

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

 

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