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

[Bill Burke]

On 2/10/2015 11:25 AM, Pedro Igor Silva wrote:
> ----- 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: 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."
>

Not sure what you are getting at.  Token is stored as a parameter in the 
fragment.  So the token is available in the URL (can be bookmarked) and 
is stored in browser history.  In auth-code-flow, only the code is 
stored in the URL.  Token is obtained by a background, out-of-band 
invocation.  Code can be bookmarked or stored in browser history, but it 
doesn't matter because the code is only usable once.

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

Not sure what you mean by validating the "audience".  You mean how can 
the IDP validate the client?  It is sort of validated as codes (for 
auth-code flow) and tokens (for implicit flow) can only be forwarded to 
registered client URL patterns.  SSL sort of handles the verification of 
the audience.

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

Only implicit flow passes tokens via URL parameters.  Which is one 
reason why we don't support implicit flow.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com