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