<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 27/11/15 09:44, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAe_CkYPijiASanXfG9CadXSjqqjWdhrpS5KcMPk8v4MUQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 27 November 2015 at 09:28, Marek
Posolda <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I've
sent PR <a moz-do-not-send="true"
href="https://github.com/keycloak/keycloak/pull/1885"
rel="noreferrer" target="_blank">https://github.com/keycloak/keycloak/pull/1885</a>
with initial<br>
support for implicit flow and hybrid flow.<br>
<br>
Some summary:<br>
- Added switches on client in admin console to
enable/disable standard<br>
flow, implicit flow, direct grant flow and service
accounts. Removed<br>
"direct grants only" switch (Disable both standard and
implicit defacto<br>
means enabling of previous "direct grants only")<br>
</blockquote>
<div><br>
</div>
<div>Is direct grant and implicit disabled by default?</div>
</div>
</div>
</div>
</blockquote>
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?<br>
<br>
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.<br>
<blockquote
cite="mid:CAJgngAe_CkYPijiASanXfG9CadXSjqqjWdhrpS5KcMPk8v4MUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
- Added more proper support for "response_type" parameter.
This is about<br>
_what_ is sent in response from AuthorizationEndpoint to
client<br>
application. According to specs, possible values are
"code", "id_token",<br>
"token" and some combination of them. See [1] . Until now,
we supported<br>
just value "code" (standard AuthorizationCode flow).
According to specs,<br>
implicit flow is about "token" and "id_token". Hybrid flow
is about code<br>
+ some of the tokens.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CAJgngAe_CkYPijiASanXfG9CadXSjqqjWdhrpS5KcMPk8v4MUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In addition to specs, I've added also support for
"refresh_token" . So<br>
if you use
"response_type=token%20id_token%20refresh_token", the<br>
AuthorizationEndpoint will send all 3 tokens. The OIDC
specs doesn't<br>
support sending refreshToken in implicit flow. However in
Keycloak case,<br>
we are using access tokens with very short lifespan by
default (1<br>
minute). Having just accessToken and idToken would make
the implicit<br>
flow quite unusable, as application will need to re-login
each 1 minute.<br>
For example Google doesn't support sending refreshToken in
implicit<br>
flow, however it makes much more sense for them as their
access token is<br>
valid for 60 minutes. This is even longer than our refresh
token (30<br>
minutes by default). WDYT about support for refresh token?<br>
</blockquote>
<div><br>
</div>
<div>We shouldn't send refresh token in fragment aka support
it in implicit. Maybe we should have different timeouts
instead of sending refresh token?</div>
</div>
</div>
</div>
</blockquote>
Ok, working on it as we discussed privately.<br>
<blockquote
cite="mid:CAJgngAe_CkYPijiASanXfG9CadXSjqqjWdhrpS5KcMPk8v4MUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
- Added support for "response_mode" parameter. This
specifies _how_ are<br>
OIDC parameters (code, state, ... ) sent from
AuthorizationEndpoint to<br>
client. More details in specs [2]. Valid values are:<br>
-- query - Params sent in query string (<br>
<a moz-do-not-send="true"
href="http://localhost?code=foo&state=bar"
rel="noreferrer" target="_blank">http://localhost?code=foo&state=bar</a>
). We always supported this<br>
-- fragment - Params sent in fragment (<br>
<a moz-do-not-send="true"
href="http://localhost#code=foo&state=bar"
rel="noreferrer" target="_blank">http://localhost#code=foo&state=bar</a>
). This is needed for implicit and<br>
hybrid flow support. Specs doesn't allow to sent tokens in
query string.<br>
-- form_post - Params are sent in body of POST method.
There is separate<br>
specs for this [3] . I've added just server-side support
for this. It<br>
may be interesting to add support on our server adapters,
as IMO it's a<br>
bit safer alternative when code+state are sent in POST
body instead of<br>
in GET method query string. But I guess this is not big
priority?<br>
</blockquote>
<div><br>
</div>
<div>Maybe just JIRA it for 1.8</div>
</div>
</div>
</div>
</blockquote>
<a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/KEYCLOAK-2153">https://issues.jboss.org/browse/KEYCLOAK-2153</a><br>
<blockquote
cite="mid:CAJgngAe_CkYPijiASanXfG9CadXSjqqjWdhrpS5KcMPk8v4MUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
- keycloak.js changes - I've added 2 new init config
options. Option<br>
"response_mode" with possible values "query" and
"fragment" (see above<br>
what they mean). Second is option "flow" with possible
values:<br>
a) "standard" - will use response_type=code . This is what
we always<br>
supported<br>
b) "implicit" - will use
response_type=id_token%20token%20refresh_token<br>
(So sending all 3 tokens)<br>
c) "hybrid" - will use<br>
response_type=code%20id_token%20token%20refresh_token
(Sending code and<br>
all 3 tokens). Not sure if we really need to support
"hybrid" option.<br>
Specs provides hybrid flow for semi-confidential
application, which can<br>
decide if they need refreshToken (in that case app must
send request to<br>
exchange code) or if they don't need refresh token and
access+id tokens<br>
are sufficient. But in Keycloak, since we support sending
refresh_token<br>
directly in implicit flow (see above), this flow is not
very useful for us.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
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 .<br>
<blockquote
cite="mid:CAJgngAe_CkYPijiASanXfG9CadXSjqqjWdhrpS5KcMPk8v4MUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Default values for options are response_type=code and<br>
response_mode=fragment. So we still use "code" and
standard flow by<br>
default, however we sent code+state in fragment now. This
is better and<br>
safer than query string. In qery string, the code+state
were always sent<br>
in request to the client application. This is not needed,
keycloak.js<br>
needs them available just on browser side. With fragment,
code and state<br>
are not sent to client application, so it's one less
possibility how<br>
they can be compromised.<br>
<br>
- Added support for "nonce" check in keycloak.js. It's
useful for some<br>
kind of attacks and specs wants it for implicit flow.<br>
<br>
Possible pending work:<br>
- Fix integration-arquillian as PR is failing now<br>
<br>
- Possibly add server-side support for "at_hash" to
IDToken ? Not sure<br>
if at_hash support has any real advantages for us, however
specs<br>
requires that and even Google supports it.<br>
<br>
- Add docs and tests. Not sure about adding separate
example? Until now,<br>
I've tested with existing js-console example and added
support here for<br>
easily set init parameters to keycloak.init, so people can
use different<br>
flow or responseMode here.<br>
</blockquote>
<div><br>
</div>
<div>Docs is enough. I don't think there's any need for
examples.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
WDYT?<br>
<br>
Marek<br>
<br>
[1]<br>
<a moz-do-not-send="true"
href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations"
rel="noreferrer" target="_blank">http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations</a><br>
<br>
[2]<br>
<a moz-do-not-send="true"
href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes"
rel="noreferrer" target="_blank">http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes</a><br>
<br>
[3] <a moz-do-not-send="true"
href="http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html"
rel="noreferrer" target="_blank">http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html</a><br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>