----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Sent: Tuesday, February 10, 2015 1:19:03 PM
Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
* implicit flow requires the token to be sent in the URL via a fragment,
there's no way around it. This URL is stored in browser history and can
What about this , Section '126.96.36.199. Successful Authentication Response'. There
is a statement saying "When using the Implicit Flow, all response parameters are
added to the fragment component of the Redirection URI, as specified in OAuth 2.0 Multiple
Response Type Encoding Practices [OAuth.Responses], unless a different Response Mode was
I think a more important issue to worry about when doing oAuth2 implicit flow is how to
validate the audience for a specific access token.
* passing fragment I believe reduces round trips because page caches
ignore fragments when indexing pages. On the other hand, a URL with a
code query param is always unique, thus can't be cached. So if you can
send the code via a fragment parameter, then, you can use the browser cache.
* Auth code grant does not require credentials. This is called a public
Yeah, sorry. That is only a requirement for confidential clients.
* Explain how form_post solves anything or removes any legs? The HTML
page returned by the server still has to be posted to the application's
I did not mean form_post would solve legs. But a combination of implicit + response_type +
My point is that today KeyCloak always performs authorization code even when you are in a
web application, which is a confidential client. Ok, you may have credentials in this case
and use authz code to perform the authentication and obtain both access_token and
However, why not just use an implicit flow where you just need to pass the client_id and
right after receive a response with the tokens. In this case, you eliminate the
code-to-token flow. That is what I meant.
Actually, you are pretty much doing this if you set an application as public in KeyCloak,
right ? The difference here is that you still need to do the code-to-token dance.
IMO, this can be used for pure SSO-based use cases where the app is relying on the
KeyCloak Adapters. Eg.: web applications/confidential clients.
Form_post would be just a better way to return tokens back to SPs instead of passing them
via query parameters.
Finally, somebody posted a way to do pseudo-confidential public clients:
Nice, we probably need to consider something like that in KeyCloak when handling public
And also funny, because oAuth 1 is all based on these "verifiers" :). Plus
signatures all over the places.
So, we should probably combine response_mode=fragment with the
On 2/9/2015 9:34 PM, Pedro Igor Silva wrote:
> It's a trade-off. Implicit removes some legs and should be avoided by
> server-side apps, so you don't have the code visible to the server when
> using fragments.
> You are right about bookmarking, however it seems you can avoid that by
> specifying the response_mode to override the default behavior for a
> specific response_type. IMO, response_type query still have issues and
> that spec about form_post looks promising.
> What they are trying to achieve with form_post is pretty much what SAML
> does with HTTP-POST binding. In SAML, the recommendation is to always use
> POST to send assertions back to SPs. And that is valid for several
> I don't think response_mode itself will reduce round trips as you stated in
> KEYCLOAK-1033. But a combination of implicit flow + response_type (eg.:
> token id_token, etc) + response_mode (to avoid exposure). Problem with
> OAuth 2 is that people end using it to provide delegated-authentication
> where it is just about authorization. And here is where OIDC plays an
> important role.
> For instance, KeyCloak uses an authorization code grant to authenticate
> users from public clients. And when not a public client you still use
> authorization code grant without provide any credential. AFAIK,
> authorization code grant defines that client *must* authenticate when
> using this grant type.
> IMO, for SSO, we can just use implicit to log in users with the appropriate
> response_type (eg.: token id_token or even make this configurable) and use
> an appropriate response_mode like query or form_post. That would remove
> legs without security penalties.
> Pedro Igor
> ----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Monday, February 9, 2015 10:10:25 PM
> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> No, Instagram is describing implicit flow. Implicit flow has a problem
> in that access tokens can possibly be bookmarked and stored in browser
> history. That isn't a problem with codes because codes are only active
> for a very short window (milliseconds).
> On 2/9/2015 7:03 PM, Pedro Igor Silva wrote:
>> I think Instagram does that , right ?
>>  http://instagram.com/developer/authentication/
>> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Monday, February 9, 2015 8:51:04 PM
>> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
>> vs. auth-code flow. It was pointed out that auth-code flow has some
>> extra hops that can be avoided if you implement
>> See this:
JBoss, a division of Red Hat