----- 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: 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
be bookmarked.
What about this [1], Section '3.2.2.5. 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
specified."
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.
[1]
http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth
* 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
client.
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
server, no?
I did not mean form_post would solve legs. But a combination of implicit + response_type +
response_mode.
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
id_token.
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:
https://tools.ietf.org/html/draft-ietf-oauth-spop-02
Nice, we probably need to consider something like that in KeyCloak when handling public
clients.
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
code_challenge in our Javascript adapter.
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
> reasons.
>
> 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.
>
> Regards.
> 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 [1], right ?
>>
>> [1]
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
>>
>> I had a good discussion on OAuth list about javascript and implicit flow
>> vs. auth-code flow. It was pointed out that auth-code flow has some
>> extra hops that can be avoided if you implement
"response_mode=fragment".
>>
>> See this:
>>
>>
https://issues.jboss.org/browse/KEYCLOAK-1033
>>
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com