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