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