9:19 a.m.
* 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(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
> To: keycloak-dev(a)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