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

[Pedro Igor Silva]

----- 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 8:55:05 PM
> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> 
> 
> 
> 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.

What I'm saying is that you can set a response_mode when doing implicit with OIDC in order to avoid token in fragment. That is it.

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

There are some known attacks where the attacker uses a token to log into an application by modifying the URI fragment to insert a stolen token into the response. This may happen when supporting social login and using implicit. Here the application should validate the audience because it is supposed to allow access only from a specific 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
>