[keycloak-dev] Keycloak.js is inefficient and can be improved

[Bill Burke]

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

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

* 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?

Finally, somebody posted a way to do pseudo-confidential public clients:

https://tools.ietf.org/html/draft-ietf-oauth-spop-02

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 at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
>> To: keycloak-dev at 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